Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for five days.

« Archives, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Implementation of book namespace deletion

Yesterday, Wikipedia:Village_pump_(proposals)/Archive_181#Delete_all_books_within_the_book_namespace closed with consensus for deletion while retaining WP:REFUND possibilities. The only way to achieve this is to move the pages to another namespace (presumably the Wikipedia: one) before deletion. Early on in the discussion I was under the impression this was not required (and thus the proposal itself was formulated under this assumption) but it definitely is as can be seen from the education program discussions.

My concrete proposal is to move all pages to subpages of Wikipedia:Books/archive with a bot and host a list of (deleted) books at Wikipedia:Books/archive. This will remove the possibility of refunding previously deleted books though. According to the WP:REFUND archives this has never happened though even though WP:BPROD explicitly allows for this. After this I will file a phabricator ticket for removal of the namespace. I also plan on dealing with related Book namespace cleanup which may have to occur before or after the massmove and namespace deletion. --Trialpears (talk) 07:49, 19 June 2021 (UTC)

@Trialpears: wait - do you want to undelete every page in Book:, move it, and redelete it? We are under no obligation to host deleted version indefinitely. — xaosflux ^Talk 07:57, 19 June 2021 (UTC)

Xaosflux No I was just noting that it won't be possible to undelete previously deleted books after this but considered that no big deal since we literally never had a refund request for a book as far as I can tell. Perhaps I formulated that poorly. --Trialpears (talk) 08:00, 19 June 2021 (UTC)

@Trialpears: OK thanks, I agree - and don't think we should do anything to try to maintain those currently-deleted-versions. — xaosflux ^Talk 08:06, 19 June 2021 (UTC)

There's only ever been 24 restorations in those namespaces, almost half for history merges or splits, and so there's little chances of this being an issue. On the other hand, there aren't all that many deleted pages there to start with - some 1319 in Book: and 952 in Book talk:, compared to 7691/7357 currently existing - so briefly restoring them for the move seems like it would be low-effort. —Cryptic 13:28, 19 June 2021 (UTC)

I mean it wouldn't be too annoying with twinkle d-batch and und-batch, but I'm inclined to just not bother given the tiny amount of restorations historically as well as how unlikely it is for there to be worth while content among them. If someone thinks it should be done I'm happy to do it though. --Trialpears (talk) 14:14, 19 June 2021 (UTC)

Trialpears, FWIW I also agree that undeleting previously-deleted Books isn't worth the time and effort given there has been negligible interest in REFUNDing them up to now. firefly ( t · c ) 16:45, 19 June 2021 (UTC)

Like I've put at in the closing note of the RFC, I disagree with moving to userspace. It would be very problematic, because Book-namespace books were community endeavors, and had multiple editors and no 'owner'. Before the book namespace existed, community books were hosted at Wikipedia:Books/Foobar. This is where their resting place should be as well. Headbomb {t · c · p · b} 16:07, 19 June 2021 (UTC)

Headbomb A few books were indeed proper community endeavors with more than one significant editor, but the vast majority was not with only one editor making significant edits. For the former category I have no problems if they get refunded to Wikipedia:Books/Foobar. --Trialpears (talk) 17:18, 22 June 2021 (UTC)

Put them all there, there's no reason to treat pages in the namespace differently. Headbomb {t · c · p · b} 17:58, 22 June 2021 (UTC)

Headbomb I'm unsure exactly what you're suggesting: That all books be moved to Wikipedia:Books/Foobar without deletion, with deletion but with refunds or moved to Wikipedia:Books/archive/Foobar with refunds to Wikipedia:Books/Foobar.

In my opinion just refunding to either userspace or Wikipedia:Books/Foobar depending on what the requesting user requests makes the most sense. As for the reason I suggest Wikipedia:Books/archive/Foobar is that would make Wikipedia:Books/archive an obvious place to list all books moved in this process, give instructions on how refunds should be handled and a short explanation of how come books were deleted.

If it is that you don't think they should be deleted but just moved I don't necessarily disagree (I !voted neutral in the RfC and remain so) but I really don't want to prolong discussion more which would be necessary in case there are objections to the deletions per the close. --Trialpears (talk) 19:45, 22 June 2021 (UTC)

That they should all be moved to Wikipedia:Books/Foobar, and not User:Foobar/Barfoo. Headbomb {t · c · p · b} 20:24, 22 June 2021 (UTC)

This is all an irrelevant tangent. The only reason pages are being moved at all is that if they are deleted in-place, their deleted revisions will become permanently unavailable (even to admins) once the namespace is removed. The correct location for a book (whether it should be in userspace, Wikipedia namespace, or somewhere else) can be discussed if and when a specific book is restored. * Pppery * _{it has begun...} 20:27, 22 June 2021 (UTC)

The should all be preserved at Wikipedia:Books/Foobar, not deleted to begin with. Headbomb {t · c · p · b} 21:49, 22 June 2021 (UTC)

No point in debating the outcome here, this isn't how you'll get it stalled or changed. Gonnym (talk) 08:43, 23 June 2021 (UTC)

The consensus was to get rid of the book namespace, not delete all books therein. RFC closed with "Editors felt that it should still be possible to access books currently in this namespace." Headbomb {t · c · p · b} 13:56, 23 June 2021 (UTC)

I think we can start by disabling all editing in book namespace (except for admin editing), title blacklist or otherwise. Currently, the title blacklist disables the creation and the saving of new books to book namespace. After, we can contact all book creators about the book namespace being deleted and help them move it to userspace, giving them six months to a year to have their book moved. If an editor does not claim their book, then it will be gone, presumably permanently. Books with multiple authors can be moved to Project: space. Anyway, this is how I would approach it. Aasim (talk) 21:29, 22 June 2021 (UTC)

Awesome Aasim I think your proposal would make a lot of sense if this was the one time where something would be essentially non reversable and the books wouldn't be undeletable, but since the books will first be moved to Wikipedia space and then deleted refunds will work just as usual. Anyone visiting a book should notice the big red banner on top of the page explaining that books will be deleted. We can also clearly communicate what happend using Mediawiki:Titleblacklist-forbidden-book and {{no article text}} and give instructions on how to request refunds. Also worth noting that most edits in the book namespace currently are dab fixes, red link removal and userfication, so I don't see any reason to stop editing there. --Trialpears (talk) 11:26, 23 June 2021 (UTC)

So I've been away a few days and am just catching up on this, so forgive me if I get something wrong. It seems like there is consensus to delete pages in the Book: namespace, but in a such a way that deleted revisions are retrievable. It doesn't seem like pages have been deleted yet, so we're still in the planning phase, yes? If so I want to summarize what I think the plan going forward is and how to do it efficiently.

1. Move all pages matching r/ Book:(.*) / to r/ Wikipedia:Books/archive/\1 / without leaving a redirect
2. Delete all subpages of Wikipedia:Books/archive
3. Create a documentation page at Wikipedia:Books/archive explaining the historical context, where titles hosting deleted book revisions can be found, and how to request undeletion if one wishes
4. Disable the book namespace in the site configuration

The first two seem relatively simple to do by script, and given the consensus to have the revisions accessible in some future way, I believe we should not skip straight to disabling the namespace. The minutia of where to restore can be handled by the relevant admin when requests come in, and I don't think we need to figure that out right now. For books that are currently deleted, I agree that undeleting them would not be wise; we would open ourselves up to restoring BLP violations or other inappropriate content, and without much interest in them I don't believe we need to retain stably deleted content just for the sake of retaining revisions editors are unlikely to request. That said, it would be nice to establish a timeline for namespace deactivation and advertise it so that interested editors have time to request any pages they might wish to keep.

Is there anything I'm missing? Have we coordinated volunteers for any of these tasks? — Wug·a·po·des​ 20:42, 24 June 2021 (UTC)

Wugapodes, Trialpears currently has a BRFA open that’ll handle (1), and I believe they will then do (2) as a batch deletion. If nobody else has yet claimed (3) I’m happy to draft it. firefly ( t · c ) 20:57, 24 June 2021 (UTC)

Seems that the BRFA has been closed as approved though it has only run on the Education Program namespace so far. @Trialpears: do you have an estimate on when you plan to expand to Books? — Wug·a·po·des​ 21:04, 24 June 2021 (UTC)

Wugapodes you've essentially said everything I was thinking but clearer, I don't believe you're missing anything major either. The one bot currently interacting with books has been disabled, but we should ensure nothing using the {{ns:}} parser function breaks and MediaWiki:Coll-community book prefix should be deleted along with the namespace. There are also a couple of categories and other things that should be cleaned up afterwards, all of which should be included at User:Trialpears/book related things but again nothing that actually influences the plan you outlined more than adding a point 5: Miscellaneous clean up.

I plan on doing everything necessary if noone wants to help out. Firefly just volunteered for 3 which I think sounds great, and I got the impression 54nd60x was perhaps interested in helping looking over documentation, backlinks and other miscellaneous parts as they did for the Education program namespace. For when I would say no earlier then a week from this discussion opened so probably Sunday if nothing here indicates that would be inappropriate. My opinion is that a big red banner on all books for a month is sufficient notification, I also plan on personally making sure Book refunds are handled quickly and smoothly. Ultimately though I'm not in a hurry and can wait if people think there's a benefit to doing so. --Trialpears (talk) 21:25, 24 June 2021 (UTC)

As nothing have come up I plan on proceeding tonight. --Trialpears (talk) 10:13, 27 June 2021 (UTC)

Excellent, thanks. We will then proceed with tagging for speedy deletion the thence empty Bookspace-related categories under criterion G6, housekeeping. Best, UnitedStatesian (talk) 19:24, 27 June 2021 (UTC)

I am quite upset that as an active creator and user of multiple Wikipedia books I was not notified of this proposal until it became a fait accompli and the moves started appearing on my watchlist. I can re-host them under my user space, of course, but I have been using these as curated collections of readings for my university courses and this move will break (has already broken?) all of the links from all of my old course syllabi, as well as the links to them from my Wikipedia user page, and any off-site links that may well exist beyond my control. —David Eppstein (talk) 21:23, 27 June 2021 (UTC)

David Eppstein I'm sorry you didn't get notified, but I think a reasonable attempt was made to reach all interested parties. The discussion was listed at WP:CENT for over a month, the discussion occured at our most active page for major proposals, Help talk:Books was notified as well as Wikipedia talk:WikiProject Wikipedia-Books including a ping to all project members and there's been a big red deletion banner on {{saved book}} which is used on literally over 99% of books, yours being in the tiny minority that don't. I'm quite happy though that the mystery of why Book:Fundamental Data Structures got significantly more views than any other page in the namespace with about 15 a day is now solved.

Your comment brings up quite a good point though: We haven't used watchlists to notify about this discussion and given that we now are moving all these pages generating watchlist entries it would be a good idea to give people time to see these and move their books if they so want. I'm thinking waiting another week between moves end and deletion starts would be a good idea. --Trialpears (talk) 21:47, 27 June 2021 (UTC)

There is a reason why my saved books stopped using the {{saved book}} template, and therefore why I never saw any notifications that way: because, long before this proposal, it stopped being a useful thing to include on Wikipedia-books and instead turned into a big banner explaining why some external service for printing things that I never cared about in the first place wasn't working any more. Since that banner was not useful information for my books, I removed it. And I am still mystified why the fact that this external service going away was used as a justification to delete our internal space for keeping curated collections of articles. Why do they have to be printable to be useful? Also, I don't watch any of the VP pages; they are for the most part a firehose of uselessness. I expect that the same is true for other editors more interested in content than bureaucracy. —David Eppstein (talk) 21:55, 27 June 2021 (UTC)

David Eppstein Your frustration is understandable and it's very unfortunate. I'm wondering though what concrete thing you want there to be done about it. I've stopped the bot while we have this discussion, but I don't feel much can be done. I guess you could ask for a review of the close at AN possibly reopening the discussion, but I don't believe there was anything wrong with the close nor the notifications given or any other procedural point. --Trialpears (talk) 22:06, 27 June 2021 (UTC)

I believe that a process that did not make any attempt to notify the content creators, even of a book that you already knew was the most frequently accessed on the whole namespace, and bring in their point of view before the formulation of the RFC, is fundamentally broken. The whole RFC was pre-judged by people who don't use these books, without any input on who uses these books, what they use them for, and whether the existence of a third-party service has any relevance to their existence. The only reasonable outcome would be to throw out the entire RFC and start fresh, with proper notifications. But I don't expect the people invested in process and bureaucracy to do this and I don't think escalating to AN is likely to be anything but a waste of time and effort. As for stopping the bot moves until this discussion subsides: Why? So that others who might have seen the moves through their watchlist remain ignorant of it and don't bring their point of view to the discussion? —David Eppstein (talk) 22:10, 27 June 2021 (UTC)

Just because I've seen other cases where people (quite reasonably) think it's inappropriate to run a bot while its activity is under discussion. Since you don't intend to take it to AN and are fine with the bot running I've restarted it again (and I was in fact contemplating how to deal with it when I saw your message). --Trialpears (talk) 22:28, 27 June 2021 (UTC)

I too am surprised that you did not seek to directly inform either the creators or the main editors of the books. It's not like we're inactive. We're just not always looking at a book we created for others to use, perhaps initially created a decade ago for a set group of topics. As only existing templates were changed, not the books they were on, the impending change would presumably not show up on watchlists. As Book:Furry fandom was created by members of WP:FURRY (probably not an uncommon situation), I have moved it to Wikipedia:WikiProject Furry/Book. I suggest that informing related WikiProjects might be beneficial due to the risk of creators who may be absent for more than a week. Perhaps a bot could do this based on project templates or categories on talk? In our case we had {{WP Furry}} on it resulting in Category:Book-Class furry articles being added; a subcategory of Category:Book-Class articles. GreenReaper (talk) 22:36, 27 June 2021 (UTC)

In fact the whole process appears to be counter to Wikipedia policy (specifically, Wikipedia:Deletion policy, which outlines methods for coming to consensus on the deletion of content, none of which were followed here). —David Eppstein (talk) 22:44, 27 June 2021 (UTC)

GreenReaper I mean I could certainly notify the around 580 WikiProjects that have a Category:Book-Class articles (great category name) and the about 5000 accounts from a purely technical perspective. I do feel it is a bit excessive though. I'm not even sure if this could be called appropriate notification under the canvassing guideline with it likely being deemed spamming and possibly partisan.

For the deletion policy objection that feel like wikilawyering to me. The important part is that there's consensus for deletion. I could just as easily see objections to taking this via MfD since that is a less watched forum that would only require a week of discussion as well as MfD being illequipped to handle complex outcomes since almost all decisions there are just a binary delete or don't delete without significant prep work. --Trialpears (talk) 09:30, 28 June 2021 (UTC)

I'm thinking waiting another week between moves end and deletion starts would be a good idea. I think it is important to pause much longer than a week before deleting anything. Somebody mentioned 6 months. Perhaps that is excessive, but a single week is far too hasty — GhostInTheMachine ^{talk to me} 18:49, 28 June 2021 (UTC)

GhostInTheMachine Sure it could wait longer, but I really don't see much reason to. We've had notifications placed on top of essentially all books for over a month already and if they weren't noticed during that month I doubt many more would notice them if you give it another month. The reason I thought a weeks wait would be significantly beneficial was that everyone who have a book on their watchlist would see the move and possibly move it if so desired. My thought was that items older than a week were unlikely to show up on peoples watchlists and be checked, but given that it's possible to see things up to 30 days after the edit occurred I guess it's reasonable to keep it for that long. Any longer than that I have a hard time seeing will matter from a practical perspective. Refunds will be easily available with clear instructions. Does another 30 days hold time seem reasonable then? --Trialpears (talk) 13:24, 29 June 2021 (UTC)

I tried to userfy Wikipedia:Books/archive/Malaysia by moving it to User:Chipmunkdavis/MalaysiaBook, but as a non-admin I cannot move "a title with a double-namespace prefix". Would someone be able to carry this out for me? CMD (talk) 02:03, 28 June 2021 (UTC)

@Chipmunkdavis: I just moved it and I'm not an administrator (unless a bureaucrat has gone rogue). Did you put an extra "User:" for your intended target? Sdrqaz (talk) 02:27, 28 June 2021 (UTC)

I really couldn't say either way, but thanks to you and your rogue bureaucrat. If this is a me issue and not a technical, that's good news. CMD (talk) 02:33, 28 June 2021 (UTC)

I was somewhat bold and created {{Book namespace deletion}} so that consistent information could be inserted into the various places that still talk about the Book namespace in the present tense. I will add a link to Wikipedia:Books/archive as soon as that exists — GhostInTheMachine ^{talk to me} 18:36, 28 June 2021 (UTC)

@GhostInTheMachine: I created Wikipedia:Books/archive; please feel free to edit. Best. UnitedStatesian (talk) 20:11, 28 June 2021 (UTC)

Y added a link to the book archive — GhostInTheMachine ^{talk to me} 21:40, 28 June 2021 (UTC)

UnitedStatesian thanks! Firefly also made a version of that page at User:Firefly/booksdraft. I took the liberty to combine your two versions. --Trialpears (talk) 13:39, 29 June 2021 (UTC)

Tracked in Phabricator
Task T285766

All books have now been moved. The Book: and Book talk: namespaces are empty (except Book:A Novel) so I've filed T285766 asking for the namespace to be removed. This will have no impact on userfying books at Wikipedia:Books/archive from the Wikipedia namespace. --Trialpears (talk) 14:41, 29 June 2021 (UTC)

@Trialpears: to help me and others plan, how long do you expect to wait until you proceed with the batch deletion of all the subpages of Wikipedia:Books/archive? UnitedStatesian (talk) 11:46, 30 June 2021 (UTC)

UnitedStatesian My current plan is waiting a month to allow more time for userfying books before deletion. The deletion of the actual namespace I see no reason to delay as there's no content there. --Trialpears (talk) 14:26, 30 June 2021 (UTC)

Thanks, @Trialpears: that sounds great. Question: why did you recreate Book:A Novel after your move designed to save its history? I'm worried its existence will hold up the Phab task and think you should delete it now, so the namespace is completely empty. UnitedStatesian (talk) 15:59, 30 June 2021 (UTC)

UnitedStatesian That was indeed brought up at phab. Since Urbanecm who will be implement this is a steward he will just delete it before deleting the namespace. --Trialpears (talk) 17:43, 30 June 2021 (UTC)

@Trialpears: What should we do about MediaWiki:Titleblacklist-forbidden-book? Should we keep the blacklist entry, or should it be removed as the ns no longer exists? If it should be kept, then the wording of the message and the wording of the comment of this blacklist entry on MediaWiki:Titleblacklist should be changed. 54nd60x (talk) 05:11, 13 July 2021 (UTC)

54nd60x honestly I'm not sure. On one hand the namespace doesn't exist anymore, but on the other it is still very unlikely that people want to edit a page with a Book: prefix and I can see people attempting to do so since it exist on other wikis. For the time being I've edited the message. Xaosflux, do you have any thoughts as the editor who added the blacklist entry? --Trialpears (talk) 07:38, 13 July 2021 (UTC)

At the least we should have a cool-down period, we can live without article titles starting with "Book:*" for a little while, maybe 6 months or a year. — xaosflux ^Talk 10:15, 13 July 2021 (UTC)

@Trialpears: In my opinion, Template:No article text and MediaWiki:Titleblacklist-forbidden-book still need to be changed in some way for the following reasons. First, Talk:Book:Example and other pages beginning with "Book:" after the ns prefix (including e.g. MediaWiki:Book:Example as well) still shows the message when it's not supposed to, because for example, it creates a broken link to [[Talk:Wikipedia:Books/archive/Example]] when the first example is used. "Talk:Book:" or any other "Book:" after any namespace was never a namespace before. MediaWiki:Titleblacklist-forbidden-book doesn't show properly on Book talk:Example either, it doesn't link to the project book archive subpage. 54nd60x (talk) 10:52, 13 July 2021 (UTC)

54nd60x Thanks, I misremembered the scribunto pattern limitations, they have limited zero-width assertions not none. It should now be fixed as well as enabled on book talk pages. Same goes for MediaWiki:Newarticletext. --Trialpears (talk) 11:25, 13 July 2021 (UTC)

Trialpears Book talk:$1 is still being rendered as Wikipedia:Books/archive/$1, but it should be Wikipedia talk:Books/archive/$1. Also, Book:Book: is showing the second "Book:" as "Wikipedia:Books/archive/" instead of just "Book:" 54nd60x (talk) 11:30, 13 July 2021 (UTC)

54nd60x First part is intentional because I thought that would be the more useful location, but I can see both sides of that. We had no orphaned talk pages in the book namespace though. The Book:Book: issue is fixed. --Trialpears (talk) 11:44, 13 July 2021 (UTC)

Is the noindex of Book namespace from search engines preventing us from finding the article? google:Book: A Novel only shows the former page title, I don't know if it has to do with this. 54nd60x (talk) 07:41, 15 July 2021 (UTC)

54nd60x I believe that's just because google hasn't re-crawled it after the move. Looking at the config change it removes indexing for the relevant namespace ids, not based on the url meaning it should be completely unaffected. --Trialpears (talk) 13:00, 15 July 2021 (UTC)

Thanks to Trialpears for planning and executing this plan in such detail. Must be worth at least a barnstar when all is complete! — Martin (MSGJ · talk) 04:20, 19 July 2021 (UTC)

Tomorrow there has been a month since the move. I will probably begin deletions then, but I will also do my first traveling since the start of this over the next few days, so it is likely it won't be done for a couple days, especially when considering some of the related cleanup that can only really start after deletion. --Trialpears (talk) 07:02, 28 July 2021 (UTC)

All Wikipedia:Books/archive/ subpages have now been deleted. There is still some minor cleanup ongoing but all big things should now be done. --Trialpears (talk) 12:26, 3 August 2021 (UTC)

Category:Book-Class articles and Category:Wikipedia books sub-categories still need to be deleted. Gonnym (talk) 12:58, 3 August 2021 (UTC)

@Gonnym: Would you please explain why you are blanking pages within user subpages? The move of some to userspace was explicitly in line with the community consensus. It might also be a good idea to notify users as a courtesy if you are blanking pages within their userspace. CMD (talk) 14:07, 3 August 2021 (UTC)

Ah, I see the templates are up for deletion. Does this mean the old talk pages must be deleted? If so it seems better to ask for them to be deleted instead of simply blanking them. CMD (talk) 14:25, 3 August 2021 (UTC)

Before we delete Category:Book-Class articles and its subcats, we need to ensure that none of them can be populated by mistake - such as by somebody using |class=book for an article about a book (it has happened). Is it best to tackle the individual custom class masks first (example), or amend {{class mask}} together with {{class mask/templatepage}}? --Redrose64 🌹 (talk) 14:35, 3 August 2021 (UTC)

I've deleted Category:Wikipedia books and Category:Wikipedia books (community books with bugs) now and made sure there's no category pollution in Category:Book-Class articles. My plan for the assesment categories is to deal with the class masks first with Category:WikiProject_templates_using_the_book_class listing them all (I'll give it a day to populate) and then remove it from {{class mask}} and friends as well as deleting the categories. --Trialpears (talk) 22:14, 3 August 2021 (UTC)

@Trialpears: How come Wikipedia:Books/archive/Algorithms has not been deleted? Also, should the "do not archive" tag be changed to later after August 7? Because I think more time is needed to discuss the implementation of book (namespace) deletion. 54nd60x (talk) 01:11, 4 August 2021 (UTC)

The article history shows that Indefensible moved the book to user space on 2021-07-05 and moved it back to the archive yesterday (i.e. after the deletions) — GhostInTheMachine ^{talk to me} 06:34, 4 August 2021 (UTC)

Was I not supposed to do that? Noticed the wipe occurred but someone else preserved a bunch of books, so thought moving it back was appropriate instead of just archiving it in my userspace. - Indefensible (talk) 06:37, 4 August 2021 (UTC)

Indefensible Eh, I would say it's fine. It's a clear request that it shouldn't be deleted and placed in a sensible place.

The assesment categories have been dealt with, thanks WOSlinker and Explicit for the help!

There are still some documentation that should be updated and backlinks to deleted categories that should be checked. Books are still supported at {{class}} and quarry:query/54292 with links to the book namespace should be looked through. All of this I intend to deal with if no one else gets to it first.

Some other things that could be done but I feel is quite unecessary is nominating {{Book}} and User:WildBot/b01 for deletion and marking Wikipedia:WikiProject Wikipedia-Books as defunct or historical instead of inactive. That could include deletion of {{User WP Wikipedia-Books}}, {{WikiProject Wikipedia-Books}} and Category:WikiProject Wikipedia-Books. I won't do any of these, but won't object if anyone else feel like it.

Is there anything I've forgotten here? --Trialpears (talk) 09:23, 4 August 2021 (UTC)

formatting of guidance page

Hi all

A couple of years ago I spent quite a lot of time creating a guidance page on Commons to help people find high quality photos to use in Wikipedia articles and also outside of Wikimedia. I know at least a couple of people who use it regularaly in their organisations. https://commons.wikimedia.org/wiki/Commons:Simple_media_reuse_guide

I've just come back to it and some of the formatting has really broken:

1. The titles which are overlayed over the images have disapeared, I guess some ways of coding have been removed?
2. The blocks of text and the title images are different sizes seemingly at random lengths

I've tried all the ways I know to try and fix this, if anyone is able to help I would really really appreciate it.

Thanks very much

John Cummings (talk) 12:40, 26 July 2021 (UTC)

I didn't see anything wrong with the page's display, but I fixed a big pile of unclosed tags. Maybe it will help. – Jonesey95 (talk) 15:58, 26 July 2021 (UTC)

Jonesey95 thanks very much, I've got quite a high resolution display so maybe that has something to do with it. I got it to display to do the wrong sizes on my older laptop by zooming the page out with ctrl and -. John Cummings (talk) 20:19, 26 July 2021 (UTC)

I got the headings back by removing position: relative; from the divs enclosing them. However the page could really use a complete rewrite, ideally using TemplateStyles, so that it works on mobile. the wub "?!" 16:32, 26 July 2021 (UTC)

the wub thanks very much indeed, I've no idea how to do that, do you know anywhere I could make a request like that? John Cummings (talk) 20:19, 26 July 2021 (UTC)

@John Cummings I've started working on it :) The blocks should hopefully all be the same width now. Making it mobile-friendly is going to be tricky though, I'll take another bash at it this weekend. the wub "?!" 00:12, 30 July 2021 (UTC)

the wub thanks so much for this, I spent ages writing it and always very frustrated in trying to make it look right. John Cummings (talk) 08:31, 30 July 2021 (UTC)

@John Cummings Okay, I'm done tinkering with it now and it should look fine on mobile, as well as the code being much easier to maintain. Also took the opportunity to update some of the content, including the lists of competition winners. the wub "?!" 22:48, 2 August 2021 (UTC)

@The wub thanks so much for your help, it looks great. I'll try to reuse the code in other places. Thanks again, John Cummings (talk) 14:44, 3 August 2021 (UTC)

Wikilinter?

I have some code which parses SPI pages using mwparserfromhell. It's mis-parsing Wikipedia:Sockpuppet investigations/Anglo Pyramidologist/Archive. I suspect there's a missing curly brace or something like that. Do we have any good tools for finding such things? -- RoySmith (talk) 20:47, 29 July 2021 (UTC)

Just FYI that page is reporting the following pile of errors:

Old behaviour of link-wrapping font tags	11
Missing end tag	4
Obsolete HTML tags	21
Stripped tags	4

— xaosflux ^Talk 23:14, 29 July 2021 (UTC)

@RoySmith: Do these edits help? --Redrose64 🌹 (talk) 23:21, 29 July 2021 (UTC)

@Redrose64 Yes, they did fix the problem, so thanks for that, but it did give me a few WTF moments as each time I tried a new debugging technique, I got different results as I hit different versions of yours :-( How did you find those problems? And, @Xaosflux what tool did you use to generate your list of errors? -- RoySmith (talk) 23:27, 29 July 2021 (UTC)

Brute force attack: look for any opening brackets, double-brackets, double-braces and triple-braces, and check that each has the appropriate closing construct that balances it at the same nesting level, and which encloses non-markup text. For example, this is a fix for an unmatched closing double-bracket that also fixed an unmatched opening single-bracket. By checking from the innermost level outwards, we pick up this where every opening tag or double-bracket also has a closing double-bracket or tag; but they overlap instead of nest, which is wrong. --Redrose64 🌹 (talk) 00:08, 30 July 2021 (UTC)

Oh, I see Page information from the tool bar to get the list of error counts. Then how do you actually dig down and find the specific places? -- RoySmith (talk) 00:09, 30 July 2021 (UTC)

I for one use lintHint on Special:ExpandTemplates to find responsible code. Nardog (talk) 01:53, 30 July 2021 (UTC)

Pageinfo gives the counts, but doesn't show you where they are or their precise nature. The 11 instances of "Old behaviour of link-wrapping font tags" are in peoples sigs where you have a construct like <font color=A>[[User:B|C]]</font> which should be altered to [[User:B|<font color=A>C</font>]] - I don't know why it's counting 11 where there are actually 13; whilst the 21 instances of "Obsolete HTML tags" should be the <font>...</font> tags (of which there are more than 50 pairs) and the <big>...</big> tags (of which there are more than 30), so I don't know why it's counting 21 where there are almost 90. --Redrose64 🌹 (talk) 08:37, 30 July 2021 (UTC)

The lint counter is not real-time. — xaosflux ^Talk 11:18, 30 July 2021 (UTC)

I have fixed all Lint errors in that page Special:Diff/1036275398. Redrose64, it was showing the count as 11 because font tag with face attribute is not counted as old behaviour of link-wrapping font tag error. Lint error count in page information is not accurate because the count for each type of error in a page maxes out at 20, sometimes 21. So a page can have hundreds of errors and it would still show the count as 20. <big>...</big> tags while obsolete in html 5, is not considered as obsolete by Linter. Apparently MediaWiki will continue support for big tags per mw:User:Legoktm/HTML+MediaWiki ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 14:59, 30 July 2021 (UTC)

That page is Legoktm's opinion; there are several tasks about big tag in Phabricator. Izno (talk) 15:33, 30 July 2021 (UTC)

A proposal really :) I added a notice at the top to clarify though. That said, MediaWiki will continue supporting <big> tags until someone (some group?) decides otherwise. Personally I don't think going around fixing them is a worthwhile use of time, but I'm sure others disagree. Legoktm (talk) 04:32, 3 August 2021 (UTC)

Discussion about Metrolyrics

Metrolyrics has been offline since 29 June 2021 and is most likely dead, there are many metrolyrics references on Wikipedia. Should these dead links be replace with another site's? Powering everyone (talk) 17:24, 31 July 2021 (UTC)

I've always been a bit suspicious of Metrolyrics, partly because it's javascript-heavy, partly because of the advertising, mainly because it seemed to be a wholesale violator of copyrights. Maybe it's been taken down for that last reason. According to www.isitdownrightnow.com it's been down for at least a week. --Redrose64 🌹 (talk) 18:07, 31 July 2021 (UTC)

about 1400 hits all namespaces.

—Trappist the monk (talk) 18:22, 31 July 2021 (UTC)

So what should be done? Powering everyone (User Talk:Powering everyone) 05:37, 1 August 2021 (UTC)

When you are ready to call it dead post to WP:URLREQ and we'll get em archived. -- GreenC 22:02, 1 August 2021 (UTC)

I'd suggest outright removal, or replacing them with {{citation needed}}. Lyrics sites, much less this one, are most likely to be copyvio and fall within WP:ELNEVER. Nardog (talk) 22:23, 1 August 2021 (UTC)

It would require a consensus discussion, probably at RSN, with a result to remove them. The archive bots are not really setup for it, maybe some users have AWB scripts? In the mean time converting dead links to archives is a step forward. -- GreenC 23:44, 1 August 2021 (UTC)

There have been numerous problems with MetroLyrics over the years, leading it to be added to WP:NOTRSMUSIC (see the linked discussions there). "Outright removal" would be better than archiving. —Ojorojo (talk) 14:40, 4 August 2021 (UTC)

And would be much easier and quicker? But then, in many cases, we may be left with empty section... Martinevans123 (talk) 14:52, 4 August 2021 (UTC)

Then the empty section will be removed in the meantime. Lyrics websites are not that fundamental for the articles, don't add anything new and in many cases, if not all, violate copyright. MarioSoulTruthFan (talk) 09:04, 6 August 2021 (UTC)

erroneous "new external links" notification

When I made this edit, I got a warning message stating "Your edit includes new external links." As the diff shows, my edit does nothing of the kind; it merely corrects some punctuation in the text, not even changing an internal link, let alone adding an external one. So whatever script triggers that warning message is buggy. 2605:A601:AADC:2100:C2FA:4802:5984:FA49 (talk) 05:37, 1 August 2021 (UTC)

That sounds like an edit filter false positive. ―Qwerfjkltalk 08:50, 1 August 2021 (UTC)

No, it's from MediaWiki:Fancycaptcha-addurl, the MediaWiki feature which asks for a CAPTCHA when IP's and new users add external links. It can be triggered if a template somewhere on the page produces a new url. PrimeHunter (talk) 10:57, 1 August 2021 (UTC)

My edit neither added nor modified any templates, so if the filter thinks any template generated a new URL, it's still incorrect. 2605:A601:AADC:2100:C2FA:4802:5984:FA49 (talk) 19:20, 1 August 2021 (UTC)

A template anywhere on the page. Hard to say without knowing how Fancycaptcha-addurl works but there are weird things that can happen. If the problem is replicatable, you could save the HTML and extract the http://... and compare to see what is changing from a recent older diff version of the page (also the HTML). -- GreenC 21:56, 1 August 2021 (UTC)

If no one here has access to the Fancycaptcha-addurl code, would someone be willing to report the bug to MediaWiki? They apparently don't want bug reports from the unwashed masses, requiring an account to add one to their bug tracker. I can't determine whether the problem is replicatable without making bogus edits to the live page, but as you say, examining the code is the next logical step anyway. 2605:A601:AADC:2100:C2FA:4802:5984:FA49 (talk) 00:18, 2 August 2021 (UTC)

You could, of course, wash. — JohnFromPinckney (talk / edits) 05:51, 3 August 2021 (UTC)

It's most likely this edit to Module:Find sources/links/google newspapers, which is transcluded via the {{BLP sources}} banner, that triggered the warning. The article cache wasn't up-to-date before your edit. Nardog (talk) 06:04, 3 August 2021 (UTC)

I see. So the root problem is a bug in Fancycaptcha-addurl, where it is unaware of the difference between URLs in the page and URLs present only via transclusion. Should transcluded URLs even be under its consideration? For instance, if my edit had added the {{BLP sources}} banner where it wasn't previously present, this still doesn't seem to fall under the situation the captcha is trying to prevent, that of bots adding spammy external links. If an external link in {{BLP sources}} is inappropriate, that should be addressed to the editor of the template, not the editor of a page using the template, correct? 2605:A601:AADC:2100:C2FA:4802:5984:FA49 (talk) 22:28, 3 August 2021 (UTC)

Color background

Hello! Can someone help me with a weird phenomenon I've been having at SqWiki? At en.wiki, module documentation is rendered over a colored background; see for example, Module:Documentation. At sq.wiki, module documentation is rendered over an uncolored background; see for example, sq:Moduli:Documentation. What needs to be done at sq.wiki to render module documentation over a colored background in the same way that template documentation is rendered over a colored background; for example sq:Stampa:Dokumentacioni?

I don't know what causes the discrepancy. Our module's sandboxes are also lacking the sandbox template (even though I imported it from EnWiki) which I believe it is also related to the problem I explained above. - Klein Muçi (talk) 15:08, 1 August 2021 (UTC)

The messages are under MediaWiki:Scribunto-doc-*. Probably should add a note to that effect on Template:Documentation and/or Module:Documentation since I have to look that up every time. Izno (talk) 15:26, 1 August 2021 (UTC)

Added to Module:Documentation/doc#Porting to other wikis. Izno (talk) 15:38, 1 August 2021 (UTC)

@Izno: Thanks man! It got fixed. :) - Klein Muçi (talk) 13:42, 2 August 2021 (UTC)

Nowikis

Hi there, I sent an editor a message on their talk page wanting to show them how to add dashes to text. So I added both dashes within "nowikis", but instead of the text showing up, the dashes showed up. Eg. – —. Thanks! Magnolia677 (talk) 21:40, 1 August 2021 (UTC)

@Magnolia677: The issue is that the – and similar are HTML entities, rather than wikitext constructs, so wikitext escaping doesn't work. I displayed the code earlier with <code>&amp;ndash;</code>, using an extra level of escaping. Vahurzpu (talk) 22:22, 1 August 2021 (UTC)

@Vahurzpu: That did it! Thanks! Magnolia677 (talk) 22:24, 1 August 2021 (UTC)

@Magnolia677: You could send them a link to Wikipedia:How to make dashes. --Redrose64 🌹 (talk) 22:54, 1 August 2021 (UTC)

{{ndash}} and {{mdash}} also works too, if you want. Sdrqaz (talk) 12:10, 2 August 2021 (UTC)

Nested template that works in some contexts but not in others???

Consider this simple construction:

{{Annotated link|Confédération Mondiale des Activités Subaquatiques|{{lang|fr|Confédération Mondiale des Activités Subaquatiques}}}}

which produces (as it should)

Confédération Mondiale des Activités Subaquatiques – International organisation for underwater activities

It works fine here. It works in my sandbox. It works at Template:Annotated link/doc#Examples (see 'Piped to use template:lang per MOS:FOREIGNITALIC' [which I added yesterday per discussion at template talk page]). But if I put it in the See also of a live page, any live page, I get

[[Confédération Mondiale des Activités Subaquatiques|Confédération Mondiale des Activités Subaquatiques]] – International organisation for underwater activities

(except that the second instance of Confédération etc is in italics, suggesting that it almost worked.

What am I missing? --John Maynard Friedman (talk) 12:14, 2 August 2021 (UTC)

@John Maynard Friedman: When used in mainspace, the {{lang}} template also spits out [[Category:Articles containing French-language text]], which breaks the syntax of your intended wikilink. You can add nocat=yes to avoid this. -- John of Reading (talk) 12:23, 2 August 2021 (UTC)

Result! Have a barnstar on me. Thank you. I'll update {{Annotated link}} accordingly. --John Maynard Friedman (talk) 12:30, 2 August 2021 (UTC)

Photos in article previews are slightly cropped (preview doesn't fit in the window in MS Edge) (Update: and Mozilla Firefox)

This has happened for months so far on my computer but anyways, I'll list my current system configuration.

• OS: Windows 10 21H1 19043.1110
• Edge version: 92.0.902.62 (Official build) (64-bit), running maximised
• Screen (I think the issue is the screen size): 15.6 inch, 1366*768

I have screenshots (in case I couldn't clearly explain the problem) but I don't know where to upload them (Commons or Wikipedia?). I guess that an option to show the article preview to the left or right of the link (if the window is too short which is probably the problem here) can solve this.

Given that this has been going on for months, I thought that someone else woud have reported this but I couldn't find any such reports (but then again I have a history of unknowingly making discussions for things that have already been discussed before (on video game forums, even after checking to make sure I am not making a duplicate discussion) so I may be wrong to assume that I'm the first person to report this) Tube·of·Light 14:38, 2 August 2021 (UTC)

You can report this on WP:Phabricator. It has single-signon with WMF signon. Izno (talk) 14:49, 2 August 2021 (UTC)

I could but I don't want to give my email for a service I'll be rarely using (especially not at my current age). Besides, where should I upload the screenshots? Tube·of·Light 15:11, 2 August 2021 (UTC)

@Tube of Light See Wikipedia:Screenshots of Wikipedia.―Qwerfjkltalk 15:23, 2 August 2021 (UTC)

You shouldn't need to provide your email, the point is that it's the same signon as your WMF signon. Izno (talk) 15:41, 2 August 2021 (UTC)

This has cropped (see what I did there?) up several times in different questions recently, so I started a gallery of examples that I came across - see User:Verbarson/cropping. The Page Previews feature was extensively discussed, tested and documented:

• Mediawikiwiki:mw:Page Previews
• Mediawikiwiki:mw:Page Previews/Functionality
• An overview over all related technical documentation

However, I have yet to find any discussion or documentation of the process that re-sizes a selected image to fit the preview. Can anyone point us to that? --Verbarson (talk) 21:21, 2 August 2021 (UTC)

Yeah, I think we are talking about different issues. I have attached screenshots for my issue below. Tube·of·Light 05:37, 3 August 2021 (UTC)

• 
• 
• 
• 
• 
  New Picture

In the 3rd image the page preview tool even places the top of the preview a bit above the top of the page. Tube·of·Light 05:37, 3 August 2021 (UTC)

Update: Even Chrome (version 92.0.4515.131 (Official Build) (64-bit) ) does the same. Tube·of·Light 05:44, 3 August 2021 (UTC)

It still asks for an email (I haven't provided one for any Wikipedia services). Tube·of·Light 05:37, 3 August 2021 (UTC)

Does this describe the problem?: (A) If the lead image for an article is landscape, then the preview will show the image above the text. (B) If the link being previewed is in the lower half of the screen, then the preview will be positioned above the link. (C) If the screen is small enough (eg a laptop), and (A) and (B) both occur, but the link is only just below half-way down the screen, then the image may be positioned high enough to run off the top of the screen.

I can reproduce that situation on my laptop screen, but it doesn't (and probably can't) happen on my 24" screen. --Verbarson (talk) 09:43, 3 August 2021 (UTC)

There is no issue if the link is not too close to the middle. If the link is in an imaginary band in the middle of the screen, the preview is shown usually above (sometimes below) the link but it ends up cutting part of the photo (or text). I don't know if portrait images have this issue and so far, the portrait images I found have been places to the side of the text Tube·of·Light 10:10, 3 August 2021 (UTC)

PS: I found out just now that text is cut out instead of the picture in some cases (I am adding the picture for that one now, and I've updated the above statement to reflect that). Tube·of·Light 10:11, 3 August 2021 (UTC)

Can someone please file a Phabricator ticket for this? Tube·of·Light 06:00, 4 August 2021 (UTC)

Jdlrobson, is this still your team? Whatamidoing (WMF) (talk) 22:02, 5 August 2021 (UTC)

this is https://phabricator.wikimedia.org/T210873 Jdlrobson (talk) 01:02, 6 August 2021 (UTC)

Jdlrobson, I think that one is the same issue here. I think Wikipedia doesn't realise that the device screen can not show the entire preview if the link is smack in the middle of the screen and the window is too short. You may want to bring that Phabricator ticket's priority up to "medium" or higher since the issue exists on Windows 10 (or make a new ticket as this is on Windows? IDK whether a new ticket is appropriate). And it appears on Firefox as well so it's definitely not a Chromium issue. Maybe programming the tool to show the preview to the left or right of the link on smaller screens (if they're wide enough) will fix it? (signature is below the gallery)

• 
• 

Tube·of·Light 05:15, 6 August 2021 (UTC)

Desktop inconsistencies in mobile editing

I am perplexed in finding that the desktop appearance and editing experience is considerably different when editing with a mobile device depending on which of two possible links you may happen to choose when launching the desktop skin. To conserve space I have collapsed the screenshots and additional details in the box below. I am curious to know why this happens.

Additional details and relivant screenshots This is a screenshot of the desktop skin as rendered when it is launched from the drop-down menu that appears when you click on the three vertical dots in the upper right corner of the page. Notice that while its appearance is similar to the desktop skin, it does not render the array of links across the page that one might desire or expect. This is a screenshot of the desktop skin as rendered when it is launched from the "desktop" hyperlink (not shown in this image) located at the lowermost right corner of the page. While it does render the link array that one might desire or expect, its behavior suggests (to me) that mobile editing will never achieve a "desktop feal". Incidentally, when I was uploading these files to Commons I noticed that their desktop links were identical to ours in both location and performance so I gather that this is not a bug or something that needs to be fixed, but it sure felt buggersome to me.

Thank you.--John Cline (talk) 18:17, 2 August 2021 (UTC)

@John Cline: those "three dots" controls don't seem to be coming from us at all - I think they are a control of your specific browser, that when clicked is trying to re-fetch/re-render the page? — xaosflux ^Talk 19:04, 2 August 2021 (UTC)

@John Cline The first image seems to be on the mobile site, en.m.wikipedia.org―Qwerfjkltalk 19:17, 2 August 2021 (UTC)

Adding to what xaosflux and Qwerfjkl said: use the "Desktop" link at the bottom of the page. The "Desktop" button in the three-dot "kebab" menu is a browser feature that makes it try to pretend to be a desktop browser by changing the User-Agent string. This trick doesn't work correctly on some sites, including Wikipedia. In theory, it should be possible to update Wikipedia's software so that it pays attention to the User-Agent string in this case, but right now it doesn't. – Rummskartoffel 10:18, 3 August 2021 (UTC)

The three-dot menu doesn't work as you expected because our mobile site does not redirect you to the desktop site if you visit it using a desktop browser (or a browser pretending to be desktop) – even though the desktop site redirects to mobile in the opposite scenario. This is known as bug T60425. Matma Rex talk 19:36, 3 August 2021 (UTC)

I appreciate the replies and will comply with the advice therein. Cheers.--John Cline (talk) 05:10, 6 August 2021 (UTC)

Tech News: 2021-31

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

• If your wiki uses markup like <div class="mw-content-ltr"> or <div class="mw-content-rtl"> without the required dir attribute, then these will no longer work in 2 weeks. There is a short-term fix that can be added to your local wiki's Common.css page, which is explained at T287701. From now on, all usages should include the full attributes, for example: <div class="mw-content-ltr" dir="ltr" lang="en"> or <div class="mw-content-rtl" dir="rtl" lang="he">. This also applies to some other HTML tags, such as span or code. You can find existing examples on your wiki that need to be updated, using the instructions at T287701.
• Reminder: Wikimedia has migrated to the Libera Chat IRC network, from the old Freenode network. Local documentation should be updated.

Problems

• Last week, all wikis had slow access or no access for 30 minutes. There was a problem with generating dynamic lists of articles on the Russian Wikinews, due to the bulk import of 200,000+ new articles over 3 days, which led to database problems. The problematic feature has been disabled on that wiki and developers are discussing if it can be fixed properly. [1][2]

Changes later this week

• When adding links to a page using VisualEditor or the 2017 wikitext editor, disambiguation pages will now only appear at the bottom of search results. This is because users do not often want to link to disambiguation pages. [3]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 3 August. It will be on non-Wikipedia wikis and some Wikipedias from 4 August. It will be on all wikis from 5 August (calendar).

Future changes

• The team of the Wikipedia app for Android is working on communication in the app. The developers are working on how to talk to other editors and get notifications. You can read more. They are looking for users who want to test the plans. Any editor who has an Android phone and is willing to download the app can do this.
• The Beta Feature for Discussion tools will be updated in the coming weeks. You will be able to subscribe to individual sections on a talk page at more wikis. You can test this now by adding ?dtenable=1 to the end of the talk page's URL (example).

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

20:45, 2 August 2021 (UTC)

You can test that 'subscribe' feature on this page by clicking this link: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&dtenable=1 Whatamidoing (WMF) (talk) 21:31, 5 August 2021 (UTC)

class=mw-datatable no longer working in Firefox

Tracked in Phabricator
Task T287997

See: Help:Table#mw-datatable.

I noticed this today. I don't know when it started.

class=mw-datatable is no longer working in Firefox in desktop view. I checked in 2 Windows 10 Pro desktop PCs.

In desktop view it works in Chrome and Edge.

It does not work in mobile view in all 3 browsers. I don't know if it ever did. --Timeshifter (talk) 03:17, 3 August 2021 (UTC)

mw-datatable works fine for me on that page. That said, the class in question is not obviously for non-MediaWiki-internal use and you should not expect that it will always work in arbitrary locations. Izno (talk) 04:12, 3 August 2021 (UTC)

Izno. I don't understand what you are saying. Are you saying mw-datatable is highlighting rows in your Firefox browser on the Help:Table page? It is not working for me in 2 desktop PCs in Firefox.

And not just on the Help page. But also in article space. See "What links here" for Template:Static row numbers table. It uses mw-datatable.

Special:WhatLinksHere/Template:Static row numbers table

See the first article listed: Bauxite

I see the table row highlighting (when cursor is over the row) in Chrome and Edge, but not Firefox.

--Timeshifter (talk) 04:46, 3 August 2021 (UTC)

Also  Works for me, PC and Android. I suspect it's an extension you've installed that's interfering. Nardog (talk) 05:55, 3 August 2021 (UTC)

Works for me in Firefox using the monobook skin in desktop view, but the highlighting doesn't work in mobile view or using the minerva skin. —  Jts1882 | talk  07:03, 3 August 2021 (UTC)

@Izno: I don't think that the mw- prefix means that it is for MediaWiki-internal use, but that it is a class that has styling that is bundled with the MediaWiki software, so that it doesn't need to be added to the site's own common.css. As an example, consider the mw-collapsible and mw-collapsed classes: these are documented at mw:Manual:Collapsible elements and are generally preferred to our own collapsible and collapsed classes. --Redrose64 🌹 (talk) 08:17, 3 August 2021 (UTC)

Yeah I also don't think mw-datatable is internal only.. However, it might be that it isn't loaded automatically in the way that collapsible is, so wether or not it works might depend on the skin used and as we know, the skins are seeing quite a few changes recently... —TheDJ (talk • contribs) 08:55, 3 August 2021 (UTC)

I haven't seen anything anywhere to indicate that mw-datatable is meant for non-developer consumption given that it brings styles that conflict (slightly) with wikitable. mw-collapsible and co. were however clearly made to replace collapsible and co. Were mw-datatable meant to be used generally, the styles would be cleaned up such that the only addition they would bring would be the hover. Izno (talk) 13:58, 3 August 2021 (UTC)

Izno is right. This class is tied to an internal PHP class and those styles are not always added, shipped as part of the mediawiki.pager.tablePager module. They have never worked on Minerva for this reason.

It is currently not added in the same way as collapsible, (but could be). Jdlrobson (talk) 20:17, 3 August 2021 (UTC)

I would not have said "works fine for me" if it did not work. Izno (talk) 13:58, 3 August 2021 (UTC)

As regards the original q.:  Works for me in Firefox 89.0.2, Windows 7 Home Premium, version 6.1.7601 --Redrose64 🌹 (talk) 12:19, 3 August 2021 (UTC)

I disabled all my extensions in Firefox, closed all Firefox windows, restarted the PC, and did Ctrl-F5. Nothing has helped so far. It seems that my Firefox is not loading anything from class=mw-datatable. All I see at Help:Table is this:

1	2	3
1-1	2-1	3-1
1-2	2-2	3-2

To me it looks like that with or without class=mw-datatable

I could uninstall all the Firefox extensions and see if that helps. --Timeshifter (talk) 14:46, 3 August 2021 (UTC)

Which skin are you using? —  Jts1882 | talk  16:29, 3 August 2021 (UTC)

The skin is Vector. I've updated the URL above to make that reproducible. This will also impact Modern, MonoBook and CologneBlue this week. I've opened a Phabricator ticket. See top. Jdlrobson (talk) 21:27, 3 August 2021 (UTC)

Yes, I am using Vector. Thanks Jdlrobson for the Phabricator ticket. mw-datatable is used in a lot of tables. People like it for 2 reasons:

1: The row highlighting on hover.

2: The white background for non-header cells. It makes for more contrast especially when there are non-bolded links in the non-header cells. The blue links against the normal gray background of non-header cells are not very contrasting. Bolded blue links against the gray background of header cells are less of a problem, though I think the gray background of headers is too dark of a gray. class=mw-datatable is often used with class=wikitable and the gray header background of class=wikitable overrides the blue background of class=mw-datatable headers. People can see the "Vectorized" Help:Table link in Chrome or Edge to see it working correctly. --Timeshifter (talk) 22:12, 3 August 2021 (UTC)

To clarify, right now mw-datatable works everywhere except on mobile web and in New Vector (e.g. you have opted-in by checking Legacy Vector in the preferences. Perhaps @Timeshifter has done that?). However as others have mentioned, this is indeed not meant for on-wiki use and will, in coming weeks, also become unavailable for wiki pages with regular Vector and in other skins. I've added two lines of CSS to Template:Import-blanktable, which could use instead for cases where you think there is an extraordinary need for highlighting or white background (example). As I pointed out on Phabricator T287997, though, I would recommend against bold adoption on millions of pages. If you believe that wikitable tables have insufficient colour contrast by default for simple text and links (and you may very well be right!), then please override .wikitable { background: #fff; } via MediaWiki:Common.css itself, which would be a far less work and disruption to accomplish. After some exposure and experience, this could then even be taken back into the wiki software itself and benefit all other wikis. If an opt-out is needed for rare cases where a grey background is actually better, a different class could be introduced for that in the same way. E.g. .tpl-wikitable-shaded { background: #f8f9fa; } on {{import-wikitable-shade}} and use as class="wikitable tpl-wikitable-shade". --Krinkle (talk) 00:59, 5 August 2021 (UTC)

Thanks Krinkle. I left a note at Template talk:Import-blanktable. I had my preferences set to "Vector (default)". That appears to be the new Vector. Mw-datatable is not working for me in Firefox and Chrome in new vector. It works in Edge. When I changed to "Legacy Vector" on that preferences page you linked to, then I see that mw-datatable works in Firefox, Chrome, and Edge. --Timeshifter (talk) 02:14, 5 August 2021 (UTC)

Comment. There seems to be some confusion about the number of articles mw-datatable is used in. It is used in a lot of articles, and it is expanding due to its use in templates. An article search for mw-datatable currently pulls up 300+ articles. But mw-datatable is also currently used in 43 templates. The articles those templates are used in are NOT listed in the previously mentioned 300+ articles. For example, the 107 articles using Template: Static row numbers table. See transclusion count. See discussion at Phabricator:T287997. I edit Help:Table and people ask about how to do row highlighting. The info was only relatively recently added to Help:Table. But it is rapidly being used by more and more tables. It would be a shame to lose this very useful function. It is difficult sometimes to follow a row of data across a wide table. Row highlighting on hover makes it much easier. And the white background of mw-datatable makes the light blue hover color stand out. And thus easier to follow across the row. --Timeshifter (talk) 23:37, 4 August 2021 (UTC)

Can I borrow a pair of eyes at template:country density?

After several days of debugging, I can't find what's wrong with this simple template:

• {{density|{{UN population|Bangladesh}}|{{country area|Bangladesh}}}} → works,
• {{country density|Bangladesh}} → Template:Country density doesn't,

when {{country density}} is just basically {{density | {{UN population | {{{1|}}} }} | {{country area | {{{1|}}} }} }}. — Guarapiranga ☎ 07:02, 3 August 2021 (UTC)

The problem is that {{country area|source=|Bangladesh}} is currently returning "Template:Country area/" and presumably the square brackets in the red link are then reported as a problem. Omitting |source= gives a number. Johnuniq (talk) 09:17, 3 August 2021 (UTC)

I've went ahead and set source to default to UN (as it does in {{country area}}). The way parameters work in MediaWiki means if you pass an empty parameter to a template, it will not use the default value. – BrandonXLF (talk) 21:42, 3 August 2021 (UTC)

Aha! Thank you, BrandonXLF.

So is my lesson from this that a parameter passed as empty is not the same as omitted?

Cheers. — Guarapiranga ☎ 22:29, 3 August 2021 (UTC)

Correct. If there is no default then most but not all templates are coded to treat omitted and empty the same. If there is a default then few templates are coded to give the default for an empty parameter. The caller must usually omit the parameter to get the default. If the default for foo is bar then templates usually say {{{foo|bar}}}. If you also want the template to give bar for empty foo= then you can do the more complicated {{#if:{{{foo|}}}|{{{foo}}}|bar}}. Maybe Help:Template should mention this. PrimeHunter (talk) 00:40, 4 August 2021 (UTC)

Strange behavior at Mitrella (gastropod)

The list in this article shows strange behavior for which I can't find an explanation:

• Delicate Mitrella instead of Mitrella delicata
• Mitrella flocked instead of Mitrella floccata
• Fortuitous Mitrella instead of Mitrella fortuita
• Mitrella inaccess instead of Mitrella inaccessa (with a pop-up showing Mitrella inaccessible)
• Neocaledonic Mitrella instead of Mitrella neocaledonica
• Nomadic Mitrella instead of Mirella nomadica
• Mitrella Peroniana instead of Mitrella peroniana

The edit page shows the right spelling of the species names. I have no idea how the wrong names show up. What is the cause and what can be done ? JoJan (talk) 16:27, 3 August 2021 (UTC)

Looks fine to me. It's as if you have some translation script running. —  Jts1882 | talk  16:33, 3 August 2021 (UTC)

Yes, that must be machine translation at your end, probably by Google Chrome or Google Toolbar. PrimeHunter (talk) 10:20, 4 August 2021 (UTC)

New Vector?

What is the official / correct way for a user script to test for a page being viewed by a user that is configured to use the new evil Vector rather than the real Vector? They both show up as mw.config.get('skin') = "vector" — GhostInTheMachine ^{talk to me} 18:06, 3 August 2021 (UTC)

@GhostInTheMachine: try: "options":"VectorSkinVersion" — xaosflux ^Talk 18:23, 3 August 2021 (UTC)

mw.user.options.values.VectorSkinVersion — xaosflux ^Talk 18:25, 3 August 2021 (UTC)

Though technically, that is a user preference, and not necessarily how "a page being viewed" is set, as that page view could have an override such as ?useskin. — xaosflux ^Talk 18:28, 3 August 2021 (UTC)

So — just for anybody else watching — mw.user.options.values.VectorSkinVersion = 1 for real Vector and mw.user.options.values.VectorSkinVersion = 2 for evil Vector — GhostInTheMachine ^{talk to me} 18:41, 3 August 2021 (UTC)

Thanks, but I guess what I really want is to know the skin as it is now being displayed, so that a user script can code around the damage inflicted by Evil Vector — GhostInTheMachine ^{talk to me} 18:54, 3 August 2021 (UTC)

Old Vector has the skin-vector-legacy class on the <body> element, new Vector does not. (Both also have the skin-vector class.) Matma Rex talk 19:33, 3 August 2021 (UTC)

Why is File:Pump.jpg considered salted when the file exists and is not controversial?

I was browsing the list of protected titles. While most of the forbidden titles are forbidden for obvious reasons, I noticed that a few links were blue (mostly ones that would break major articles or tutorials if messed with). One of the ones that stuck out the most was File:Pump.jpg. The inclusion on the list raised a few questions.

1. Why is it on the protected titles list if it is such a uncontroversial image?

2. How does this image exist if it was on the protected titles list?

3. How would this be controversial considering it links to no other pages?

Is there something I am missing here? Maybe it used to be a file related to the village pump that was replaced? Please call me Blue (talk) 18:52, 3 August 2021 (UTC)

See the log (log links are often not displayed). The image uploaded with this filename was, how shall I say, a bit more offensive than the current image. It was repeatedly uploaded and used for vandalism in articles, which you can see by following the links in the log. The protection means that it is 'locally' protected, meaning no one can upload an image with the same name on the English Wikipedia. If the filename exists on Wikimedia Commons (WP:COMMONS), then that's what you see. Anyways, that was 14+ years ago - IMO it's probably been protected long enough. -- zzuuzz ^(talk) 19:50, 3 August 2021 (UTC)

Thanks for the reply. I was wondering what was up with that. Please call me Blue (talk) 20:24, 3 August 2021 (UTC)

Strange error on Sockpuppet Investigations page

Wikipedia:Sockpuppet investigations/Scibaby

It says "Expression error: Unrecognized punctuation character ",". Expression error: Unrecognized punctuation character ",".". I checked the source code and found nothing wrong. What is the error that needs to be fixed? Yleventa2 (talk) 23:12, 3 August 2021 (UTC)

It is not expecting an thousand seperator in Template:SPI archive notice, which it does get from the count of entries in the category for this person. {{PAGESINCATEGORY:Suspected Wikipedia sockpuppets of {{{1}}}}} needs to become {{formatnum:{{PAGESINCATEGORY:Wikipedia sockpuppets of {{{1}}}}}|R}}. This line is used several times.--Snævar (talk) 23:29, 3 August 2021 (UTC)

@Snævar and Yleventa2: You can just add a parameter value of "R" to the magic word to display a raw number. See mw:Help:Magic words#Statistics for more. Terasail^[✉️] 14:14, 4 August 2021 (UTC)

I suck at Photoshop gallaries

I've added a photo gallery to South Bronx Greenway, but after playing with the layout a couple of times, it's still butt-ugly. Could somebody who's good at image layout take a look? This is a DYK, so it would be nice if it could be un-butt-uglified before it hit the front page. Thanks. -- RoySmith (talk) 14:00, 4 August 2021 (UTC)

Two ways to link to a specific revision of a page

What is the difference between Special:Redirect/revision/123456789 and Special:PermanentLink/123456789? Kleinpecan (talk) 16:40, 4 August 2021 (UTC)

They are equivalent. Special:PermanentLink is older. Special:Redirect from 2013 has more features and can add new features.[4] I suggest to always use Special:PermanentLink or Special:PermaLink for permanent links. More users know it, it's documented at Help:Permanent link, and the link under "Tools" says "Permanent link". PrimeHunter (talk) 20:35, 4 August 2021 (UTC)

Interesting, I never even knew Special:Redirect existed. Playing around, it looks like they're almost equivalent. One does (at least by default) a 301, the other a 302.

permalink:< HTTP/2 302
redirect:< HTTP/2 301

-- RoySmith (talk) 20:59, 4 August 2021 (UTC)

None, Special:PermanentLink was introduced in 2010 (after originally being requested in 2004), and in 2013 a more generic Special:Redirect was added primarily to be able to link to users by ID instead of username, but also added revision support since it was trivial. Legoktm (talk) 21:52, 4 August 2021 (UTC)

Thank you all. Kleinpecan (talk) 01:22, 6 August 2021 (UTC)

Template:Coord on Wikispecies

I have imported Template:Coord and subtemplates/ modules to Wikispecies, as species:Template:Coord, but it fails with a "Lua error: callParserFunction: function "#coordinates" was not found." error.

How can this be fixed, there? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:11, 5 August 2021 (UTC)

The GeoData extension needs to be enabled there. See m:Requesting wiki configuration changes for the process. Legoktm (talk) 09:19, 5 August 2021 (UTC)

Answered on wikispecies.--Snævar (talk) 12:19, 5 August 2021 (UTC)

Calvary Baptist Academy (Shreveport, Louisiana)

I'm not sure why the infobox map isn't working. Thanks! Magnolia677 (talk) 10:46, 5 August 2021 (UTC)

What do you mean by not working? Both maps appear to work for me. PrimeHunter (talk) 11:03, 5 August 2021 (UTC)

@PrimeHunter: I tried it in a different browser and it works fine. Must be a Firefox thing. Cheers. Magnolia677 (talk) 11:22, 5 August 2021 (UTC)

 Works for me in Firefox. — xaosflux ^Talk 13:31, 5 August 2021 (UTC)

marking almost all edits as "minor"

I often come across editors who are marking all or almost all of their edits as "minor" even though they are not minor according to our definition. I'm wondering if they must be doing it consciously or there is some preference they have set or tool they are using which could be doing it for them. I know that there used to be a preference option "mark all edits minor by default" but I can't see it available in my preferences now. Zero^talk 14:26, 5 August 2021 (UTC)

It may be that it still works for those who chose it in the olden days. I've also noticed that some academics & journalists have a wholly different concept of what is "minor" to the WP norm. Of course some usage is deliberately deceptive. Johnbod (talk) 14:30, 5 August 2021 (UTC)

Timeline syntax

How do I make this thing work? What am I doing wrong? —hueman1 (talk • contributions) 14:51, 5 August 2021 (UTC)

How are you trying to make it look? You've defined one bar with multiple labeled intervals. But most of the intervals are too small horizontally for the text to appear without overlapping other text. If you want each interval to be on a separate line, you can make each one a separate bar by adding "bar:NAME" to the start of each line in the PlotData section. CodeTalker (talk) 22:08, 5 August 2021 (UTC)

@CodeTalker: I restored it to an older version and it works just fine without "bar:NAME". The problem with the older version is that it's not showing 2021 and 2020 is "2020.2". —hueman1 (talk • contributions) 01:30, 6 August 2021 (UTC)

I'm not really an expert on timelines, but a little experimentation indicates that adding a BarData definition like this:

BarData =

barset:PM

and also adding

barset:PM

to the PlotData (both of which you have in the older working version) resolves the problem. However I don't know why this is necessary; the documentation seems to indicate that declaring a barset should be optional. CodeTalker (talk) 02:50, 6 August 2021 (UTC)

@CodeTalker: Thank you for your suggestions. —hueman1 (talk • contributions) 13:48, 6 August 2021 (UTC)

Monobook site footer left sidebar squish

Tracked in Phabricator
Task T288288

The site footer is currently appearing on the bottom-left side of the screen only. below languages, with the categories the last thing on the right. I suspect something's missing a clear. I'm seeing this on every page with more content than sidebar. I'm using Google Chrome Version 92.0.4515.131, MonoBook, on a widescreen laptop. Please see attached screenshot - I zoomed right the way out, but it's on the bottom left. I checked another computer to see if it had the same issue, which it did, but I don't seem to have it when I'm logged out.--Launchballer 19:56, 5 August 2021 (UTC)

Thanks for the image! You're using the Monobook skin, which looks to have been broken (WP:ITSTHURSDAY), that's why it only happens logged in. I've left a note on a ticket I think might be the cause (phab:T287410), it may get split out as its own issue. Izno (talk) 20:07, 5 August 2021 (UTC)

Also ITSTHURSDAY: the styling for the "[Mark this page as patrolled]" thing has changed in some skins. Timeless still behaves as previously, it has the rule

div.patrollink {
    font-size: 75%;
    text-align: right;
}

but other skins (Cologne Blue, MinervaNeue, Modern, MonoBook and Vector) have the changed rule

div.patrollink {
    clear: both;
}

which mean that it is now normal size and left-aligned. --Redrose64 🌹 (talk) 22:49, 5 August 2021 (UTC)

(Isarra got fed up with the CSS changes ongoing since a year and a half now and is now just using all the CSS from 1.34. That's why Timeless is unaffected.) Izno (talk) 22:52, 5 August 2021 (UTC)

Incomplete signatures

Over the past couple of days my signature has sometimes not fully appeared, even though I've used four tildes and checked in preview. It looks like others may be having a similar issue. Martinevans123 (talk) 21:31, 5 August 2021 (UTC)

Please post an example. Always include an example when you report an issue. The usual cause is an unclosed tag in an earlier section which didn't affect a preview of the edited section, but we have no way of telling without knowing the page. PrimeHunter (talk) 21:54, 5 August 2021 (UTC)

Thanks. If I see it again, I'll post it here. Martinevans123 (talk) 22:45, 5 August 2021 (UTC)

Menu font tinification

Tracked in Phabricator
Task T288336

Sometime recently (last Thursday?), the font size of second level menus got smaller. I really wish that the 30-somethings with perfect eyesight who make these changes would check with the 60-somethings about whether it's still readable before pushing changes like this. Harumph. -- RoySmith (talk) 22:36, 5 August 2021 (UTC)

What, you mean there are menus?? "I don't believe it!" Martinevans123 (talk) 22:48, 5 August 2021 (UTC)

I saw this change show up on Discord I think. There may/not be a task for it already? Izno (talk) 22:54, 5 August 2021 (UTC)

You should be able to fix the size of the menu items using the CSS:

.mm-submenu li {
    font-size: inherit !important;
}

This might be more of an issue with MoreMenu rather than Vector since Vector doesn't have any second-level menus built-in from what I can tell. In that case, the fix would have to be added to MediaWiki:Gadget-MoreMenu.js via the GitHub repo. MusikAnimal, what do you think?– BrandonXLF (talk) 07:32, 6 August 2021 (UTC)

I fixed your MM link. DMacks (talk) 07:47, 6 August 2021 (UTC)

I noticed this the other day also, affecting Easyblock on Legacy Vector. Each submenu gets progressively smaller. This is not part of the MoreMenu set (a gadget I have not enabled). The standard menu-items are 13px, Easyblock's 'Block' menu-entry and its main menu (the second-level visible) are 10.5625px and the third-level visible is 8.58203px. DMacks (talk) 07:45, 6 August 2021 (UTC)

It looks like this is related to phab:T191021 (gerrit:702456) and phab:T287052 (gerrit:705897). Apparently font-size: 0.8125em was applied to .vector-menu-dropdown li a and now it's applied to .vector-menu-dropdown li in Legacy Vector, causing it to be applied recursively. Nardog (talk) 08:27, 6 August 2021 (UTC)

I've gone ahead and opened phab:T288336 since the issues seems to be caused by a small mistake in some of Vector's CSS.– BrandonXLF (talk) 09:06, 6 August 2021 (UTC)

A problem with an archived PDF file

I am working on BrikWars. The third reference is to a PDF. I have tried archiving it using the "Fix Dead Links" tool. However the archived pdf comes back blank. I can see there are good files further back in the wayback machine. I suppose I could just edit the archive tags manually, but I suspect that would not get to the root of the issue. Slimy asparagus (talk) 23:15, 5 August 2021 (UTC)

The archived file ([5]) is cut off at precisely one megabyte (1,048,576 bytes). I assume the archiving simply failed in this one case. Either way it must be a problem with Wayback Machine itself, not our tool. Nardog (talk) 02:53, 6 August 2021 (UTC)

ivmbox css

I noticed the issue at Wikipedia:Arbitration/Requests/Clarification_and_Amendment#Motion:_500/30_amendment

The numbering of the list is messed up. Apparently it's due to this CSS:

.messagebox :only-child, .errorbox :only-child, .warningbox :only-child, .successbox :only-child {
    margin: 0;
}

I can't tell where it's coming from, though. Doesn't seem to be in Common.css or Vector.css. I'm not entirely sure why it's there in the first place. Is it safe to unset this property? ProcrastinatingReader (talk) 10:47, 6 August 2021 (UTC)

These are all WMF classes. (.messagebox is technically our class first but is legacy since .*mbox showed up. It's on my hit list to remove entirely.) As such, they should show up in the ResourceLoader module for the particular skin of use.

In our context, I would guess you can remove .messagebox, first importing the CSS from Common.css while ignoring the CSS from upstream. You can identify more easily in console what that CSS is by using ?debug=true, which will separate the RL files into their different sources. Izno (talk) 14:05, 6 August 2021 (UTC)

The module is skins.vector.styles.legacy, but the code itself appears here, which says it's for printing, which is weird. Whatever its purpose, all only children in mboxes (as opposed to e.g. .messagebox > :only-child) seems way too broad; who knows what else it's making invisible. Nardog (talk) 00:39, 7 August 2021 (UTC)

Cyber security issues

How are potential cyber security issues with a website given in a source dealt with? Having enquired of the user in question, this edit was because they "clicked on this link a couple of times and (their) Norton software flagged it up in large red print as a dangerous website". Mutt Lunker (talk) 10:50, 6 August 2021 (UTC)

Apparently some security software flags www.fifeminingheritage.org.uk as dangerous. That may be accurate either because the site has been hacked and malware installed, or as often happens, the domain name has been taken over by a scammer with malware. Usually, however, it's a false alarm and the website is ok. Putting that URL into the Google checker claims it is ok. Regarding lapsed domain names, the site I used to use for whois no longer works. Is there a whois for domain names at tools? Johnuniq (talk) 11:05, 6 August 2021 (UTC)

Template:User UTC

I had revised {{User UTC}} to let it display the time of the user instead of plain UTC. I hope I didn't break anything. ——羊羊/Yangyang (talk) 03:07, 7 August 2021 (UTC)

Weirdness with moves and watchlist

My watchlist currently has on it:

Move log 15:59:40  Change352 talk contribs block moved page Draft:Tammi Harrison to Draft:Smoke Out Queen ‎(name)

What's weird about that is that after that move, I also moved it (after doing a histmerge). It looks like the watchlist is showing "the most recent move other than your own". Is that intended behavior? Maybe the histmerge is confusing things? -- RoySmith (talk) 16:42, 7 August 2021 (UTC)

Wrong links to World Athletics

Links to World Athletics biographies, using the IAAF template, doesn't seem to work. Is anyone looking into it? See e.g. Hsieh Hsi-en and Yasmeen Al-Dabbagh. Ssu (talk) 21:41, 7 August 2021 (UTC)