If a "root cause" is indeed in PAGESINCATEGORY, then it is also present in #expr (see T361583), and probably many other magic words which all interpret entities literally.

@Tgr Thanks for your reaction, but it does not solve the problem me and other users of the tool have.

This problem seems to be long solved (and forgotten). I have just checked and the files are up-to-date. It means there is nothing to fix anymore.

There has been a configuration change on Toolforge which forced tool maintainers to reinstall their crontabs, around this same time. I can only guess that the maintainers of this tool have not done so and that has caused the lack of updates.

In T254646#7574618, @Dinoguy1000 wrote:

Is it desired to also update Phab tasks as part of this?

No one ever actually answered this question, either. I don't know if it would be worth going out of our way to find and update Phab tasks, but I'd at least like to know I wouldn't be stepping on any toes if I update tasks I happen to run across when catching up on email or looking for things or the like.

I understand this question is probably coming way too late, but I still thought I would ask…
Has there ever been any community-wide discussion on this issue before people started changing things?
Is this move backed by a community consensus and/or WMF decision of some kind? If so, can you refer me to it?
I am asking because I watch the ongoing renaming process disrupting users' daily routines, and I observe how much time is being spent on this issue; so I am asking myself whether this social engineering that we are all now made a part of has received any prior sanction within our ecosystem (other than "I'm starting to see people reminding other people" as in the original post).
Thank you for any feedback.

I've been watching this bug for 4 years now, and for all that time, Page link notifications have been useless for me. Fellow Wikipedians regularly mock me (or at least get easily distracted whenever I an showing them something while logged in) for the "99+" unread notifications in my top panel.

@bd808: Hello, thank you for investigating this. I didn't mean to create anything fancy – just an HTTP gateway to executed a fixed SQL query on the database replica and obtain its results.

Sorry, I closed this as a mistake. But I am in favor of this being closed as Declined by someone authoritative enough to tell that nobody is going to take the time to repair those old scripts anymore. Reopening for the meantime.

I suggest marking this a WONTFIX, because it has not even been triaged after almost two years and it has been reported that @Erik_Zachte has retired from the WMF and his stats tools have been largely supeseded by a new version.

As a note, I am going to develop a tool with similar purpose – checking grammar in Wikipedia articles – but that one should probably rely on newer technologies, such as the MediaWiki DOM spec (output of Parsoid) to avoid issues with wikitext syntax. Also, it will only integrate with a particular grammar checker currently under development for the Czech language, and I do not even know yet whether the tool will have separate interface calling the grammar checker's backend, or whether it will be more like copying text there and forth between Wikipedia edit window and a form on the grammar checker's website. Anyway, I could probably take some ideas from the decommissioned WikiCheck and the resulting tool could be useful to people who would like to adapt it to other languages (and checkers), provided I will be able to release the code under a free license (this is going to be a part of a larger research project).

@Urbanecm: Why geolocalization when we have language settings (or at least an educated guess) per user? It's the same one that shows labels and descriptions in some languages and hides others.

That "not used for actual interactions" may actually hold true (in the Wikimedia context, though none of us can easily prove that), while looking at native speakers is a misleading criterion (English is not my mother tongue and I would keep using it with other non-native speakers even if all the native speakers out there suddenly died out) and I can bet that there are people who share only Toki Pona and no other common language (so that that would be their language of choice if they had to talk to each other). This last argument holds even stronger for better established conlangs, particularly Esperanto, for which I could readily provide a list of people pairs whose only shared language it is.

@Liuxinyu970226 Thank you for your suggestion number one. I've been aware of this possibility, yet, as I mention in the ticket description, that would mean a "need to import and maintain a set of templates in each and every project I contribute to, just to be able to set up a user page". For a user like me who has edits on ~100 wikis, that would really be impractical, let alone when some community decides to start a discussion about those new local templates, in their language.

Putting the language code (non-)attribution issue aside, is there an agreement that Babel should only support languages that are also supported as content languages? If so, where has it been voiced, because that's not exactly what the extension seems to be about.

Prior to definitive farewell to the EP extension, all data created within its framework must be archived somewhere, probably as static wiki pages. An enormous amount of work has been invested by volunteers into curating courses and workshops through the extension, enrolling students, listing articles etc. All that is now gone, at least off the eyes of the public and the common Wikipedian (fortunately, it is still preserved in the database AFAIK). Not archiving this information in a place and form accessible to the community (and the public) would be disrespectful towards all those volunteers and harmful for future reports and analyses on the history of the Education Program in the Czech Republic.

@Nikerabbit: Thank you for your reaction. I just wanted to point out that there are people out who are ferocious and loud enemies of artificial languages and that this might be one of them.

As a Toki Pona speaker, I found it offending to see a bug calling to "nuke last visages" of my language and have therefore changed the title.

I think that the core of the problem here is indeed that we do not distinguish between using a language in producing actual content, and using a language to communicate about content.

I happen to be one of the sysops on Toki Pona Wikia as well. The project is not very active, indeed, and I do not request any lift-up of its status on Wikimedia projects.

I'll probably need to try to explain this difference in a clearer way to my colleagues. The uninitiated ones clearly thought that something was broken in the code, while most of the others probably kept being annoyed by the warning. The code above is included for instance in the Recent Changes page (automatically showing the date of the next scheduled meetup) and that page gets edited frequently. I can imagine that this useless warning distracts those editors and may even lead to them ignoring actual bugs in other code on the same page.

Thank you @bmansurov for explanation of the goal of the recent change and @jcrespo for expanding on it and pointing to the source code. I dare consider it bad design that an existing property has been assigned a new meaning, instead of either keeping it untouched or abandoning it completely. In this particular case, the change moreover, perhaps accidentally, favors non-free images, as only those will be returned in queries that have not been adapted to the new schema.

@jcrespo: Thank you for your hint. This is indeed the workaround that I have been using since yesterday. Is this a stable fix, however? If so, does therefore "page_image" as of now mean "page_image_nonfree"? I cannot believe someone would have purportedly broken existing code. I would understand that populating "page_image_free" takes time, but why has the old "page_image" disappeared – or was renamed "page_image_free" with no replacement, although all images on cswiki should be free images (no fair use is allowed there)? These are my questions.

At this moment, the query returns 4 rows. Still yesterday, that was 5. A script or something must be working in the background, but items with "page_image" are disappearing rather than re-appearing. On the other hand, there are 206870 page_image_free items on cswiki.

This broke my tool that generates a map of geographical articles on cswiki with no page image. On production, page images are still shown, so the information is retained. My log indicates that the change ocurred at the end of November 2016.

Thank you very much for acting up on my report so swiftly!
The patch is apparently not yet live on Tool Labs, but hopefully will soon be.

Thank you all for achieving this together – it is a nice gift on the eve of the 101st World Esperanto Congress 2016 in Nitra, Slovakia! Me and KuboF will make sure to spread the word there too. In parallel to Brion Vibber Day, we might want to start calling July 21st the Amir E. Aharoni Day. Long live multilingualism and multilingual input!

@Jdforrester-WMF: Impact of the change is for Esperanto language projects only, all of which have been notified and the issue was discussed with the communities in detail before advancing to making changes.

Does it therefore make sense that I now ask a volunteer programmer from the Czech Wikipedia community to start creating Lua modules that work this way? Or should we rather wait for the new solution be implemented first?

@jcrespo Thanks for staying on the constructive line. FYI, the output in question is https://cs.wikipedia.org/wiki/Wikipedie:%C3%9Adr%C5%BEba/Nekategorizovan%C3%A9_%C4%8Dl%C3%A1nky_s_ohledem_na_skryt%C3%A9_kategorie produced by a query listed on https://cs.wikipedia.org/wiki/Diskuse_k_Wikipedii:%C3%9Adr%C5%BEba/Nekategorizovan%C3%A9_%C4%8Dl%C3%A1nky_s_ohledem_na_skryt%C3%A9_kategorie – users work on categorizing pages from the list and removing items that have been categorized in the meantime (perhaps by another user) and they feel it annoying when I or other developer do a new update which restores some items that should not be there, just because the replicas lack the relevant categorylinks entries. Hope this explains why even a few missing table lines can be annoying.

Thank you. I did not realize there were also SQL dumps, not only XML. Would it perhaps be possible to have the latest dump readily available on an SQL server? That could be an alternative for anyone who can sacrifice recency to accuracy. Needing to periodicaly install new dumps into my own user tables feels like adding too much extra work (that might break in the process) for it to be feasible, plus it is possibly redundant if more users need to access the same data.

Just noticed this bug just before opening a new bug report on cswiki_p missing virtually all revisions and categorylinks from between 2016-03-08 18:00 and 21:00 UTC, which spoils the results of a tool of mine that is supposed to find non-categorized articles (in no other than possibly some hidden categories).

Right now, even the correct URL – such as https://parsoid-tests.wikimedia.org/parsoid/enwiki/Wikipedia – does not work anymore and results in an error message "Cannot GET /enwiki/Wikipedia". It seems like some has played with URL rewrites on the server, breaking the rest of the available functionality.

Thank you very much, @matmarex !

The original feature request was targeting newbies, i.e. people who may even not yet know that there are several editors to choose from. Today, most help pages are concerned with wikitext only, and even if we added VisualEditor alternatives everywhere, it would result in a nasty mixture. At the same, we do not want to force VisualEditor either as any default for those folks who prefer or want to learn wikitext. And it would be boring to need to answer to "which one do you prefer?" everytime before you can read a help page on any topic.

The same bug – prefered attribution – is annoying me at every single moment I decide to upload something to Wikimedia Commons. I want my real name to be used when attributing the photographs that I publish, and I now need to remove the nickname and replace it with my user name every time when I start the UploadWizard.

@Dvorapa: Making the behavior of edit links depend on user's choice of editor is being solved in T114531.
I would therefore prefer this issue to take care only of redirecting to page A or B depending on the editor, e.g. for two sets of help pages, as originally proposed.

@Dvorapa: Edit links which are part of the (cached) rendered page need to be uniform - because of the caching. Single edit tab may change the behavior of what happens after you click a red link (action=edit) and might eventually navigate the user to VE if he prefers that one (but this is only my gues). Any absolute edit links you would like to generate yourself cannot be customized for each user, again because of the caching.

I am afraid that "editor used by the currently viewing logged-in user" cannot be turned into a magic word, because that would require evalution at virtually every view (by many different editors) and would break the current practice of caching (with VE/wikitext, there would now be two possible renderings of the page, but more could come with more possible values in the future). The example in the top post would also make it impossible to tell generally (i.e. user-independently), where a page redirects to (which is necessary e.g. for fixing double redirects). Obviously, magic words would not work for this.

Thank you for suggesting to use the REST API instead. I had kind of known about it, but did not realize it would fulfill also converting the other way around that I need (after I modify the HTML, I need to get the corresponding wikitext back out of it). I will now try to modify my code to use this instead.

Still demonstrating the same behavior (because, sadly, nobody has yet even triaged this in the month that has passed).

I can confirm that the issue persists and that it also involves bad interpretation of the file names – localized File: prefixes for files on Commons, such as "Fichier:" (fr) or "Soubor:" (cs) are not translated and a "missing link" is therefore reported, although images are displayed correctly during the editing.

The prices of .cz domains today are so low today (5 US$) that I am in favor of not giving up the domain totally and let it end up in whoever's hands this discussion concludes. WMCZ records indicate that virtually all .cz domain names derived from English and Czech names of WMF projects are currently registered until 2020. And certificates should nowadays be free of charge, if I understand it right, unless WMF requires the use of a specific paid certificate.

Thank you for your advice. It is sometimes difficult to figure out where to report what, particularly if it already takes a lot of work to find out first where in code a feature is located, which libraries it calls and whether all those scripts are either site specific, project specific, MediaWiki core or some extension (local or global). The associated talk page was last edited in 2013, which did not seem very welcoming, but I have now posted my report there in hope of somebody indeed coming across it. It seems that the bug has actually been fixed since a few days, but so far for a few other similar cases only. I have tried to share your suggestion regarding the called function in that page too, but that may well be useless there, as one would need to report that separately to the maintainer of the other extension which creates the actual "User Uploads" link.

I think this bug is rather severe, because it makes virtually every citation of an older version of an article contain false or at least misleading information.

@Krenair: What kind of community consensus do we need here anymore? @KuboF's post from Apr 15 has demonstrated that community consensus has been reached on all Wikimedia wikis that use Esperanto as its content language. I think we are now waiting only for someone to review @brion's patch and apply it. Considering the specifity (and age) of this issue, how can we find a suitable reviewer?

I have successfully received the files, thank you for your help!

My use case for this is that my notifications are flooded with new links to very general articles that I once created and which get linked very often (such as an administrative unit being linked from every single new article on its subdivision, of which there may be thousands). I do not want to disable the whole feature ("new links to articles that I have created") because I still want to see new links to those more specific articles that consist the majority of my contributions (but a minority of my new links notifications, at the moment). I thought there might be other users warring this, or who may have disabled this kind of notifications only for the hassle it brings when you are a somewhat aged contributor (or just happen to be the first acting Wikipedian when a new general topic comes to existence).

2.5 years since last post and I am still forced to upload images with names such as https://commons.wikimedia.org/wiki/File:Brno,_Dominik%C3%A1nsk%C3%A1,_odlo%C5%BEen%C3%A1_uli%C4%8Dn%C3%AD_cedule.JPG – which confuses users of those images who need to pay attention to the extension's letter case – only because my camera names them "P1550467.JPG" and Upload Wizard does not allow me to change the extension :-(

@brion, when do you think you'll find the time to have a look at this and complete the process?

In order to further simplify the transition, I have set up an automatic filter that tags edits where the user has used surrogate letters instead of proper Esperanto letters. This way, we will be able to detect users who might be confused by the fact that the conversion now occurs on-the-fly (as opposed to after submit) and would force the surrogates into the edit window, and also any other users for whom the ULS did not work as expected. KuboF and I will be monitoring such tagged edits after the transition. The filter: https://eo.wikipedia.org/wiki/Special:Abusefilter/3

Run across this bug today while working with {{#invoke:String|…}}. This bug forces me to make nasty obfuscations in my code that sometimes hang on the level of workability. And I guess that the more we use Lua/Scribunto, the more we will bump into annoyances caused by this bug.