Jun 6 2019
Re: Retro's comments: There is already a bot working through a limited set of signatures. See https://en.wikipedia.org/wiki/Wikipedia:Bots/Requests_for_approval/Ahechtbot_5 and its siblings. The current BRFA process, and the time-consuming nature of finding faulty signatures in talk pages and figuring out a fix for each one, makes it pretty slow to chip away at faulty signatures, but it is possible.
Jun 4 2019
Can we please have this report for main space pages?
Jun 3 2019
I welcome bot fixes of Linter errors in signatures. They will not fix the root cause of the problem, however, which is that custom signature code is allowed to contain Linter errors. @WOSlinker proposed a reasonable fix above.
May 17 2019
If this change has been deployed on en.WP, it did not resolve the problems. Sorry.
May 9 2019
Thanks for the patch. Things are much better today, but still not entirely fixed.
May 7 2019
The bot should not insert an invalid title. If it is unable to insert a valid title, it should leave the title blank so that the error message makes it obvious to editors that something needs to be fixed.
May 6 2019
This is a significant problem affecting some of the most active editors, at least at en.WP. If it helps, here are the Watchlist preference settings that I have selected:
May 2 2019
Apr 11 2019
I think I have found a similar situation here:
Apr 10 2019
Still happening as of April 5:
Here's a link to a broken page:
Thanks for the quick patch, but wouldn't it make more sense to roll this out with the normal Thursday/Friday patch cycle? Now that I think of it, why was this non-urgent change applied out-of-cycle in the first place, without the usual announcement in Technical News? (As always, I am probably misinformed about how this process works; I am merely a volunteer editor, not a developer or other insider.)
Apr 9 2019
It is not really even obvious what this new thing does
, or where the useful slider GUI went. Whatever choices the developers are making, can you please move these experiments to the bottom of the page, or into a collapsed box, so that busy editors can see the actual links in the actual revision history, which is the title of the page, after all. Thanks.
Apr 4 2019
Apr 2 2019
Mar 28 2019
It is possible that the situation has deteriorated. I don't remember if the foreign-language text was present in the gray-on-white subheaders last summer, but now I'm seeing things like:
Mar 27 2019
Please increase the priority of this fix. Signatures are still causing Linter errors. Here's a two-day-old one that I just fixed:
Mar 15 2019
This appears to be happening again:
Mar 14 2019
Per @Izno, this also appears to be happening with DOI and ISSN links. More junk for gnomes to clean up. See https://en.wikipedia.org/w/index.php?title=Purges_of_the_Communist_Party_of_the_Soviet_Union&diff=prev&oldid=884801720 for a sample diff.
The link to ISBN exists for a reason, as @Izno explains.
Mar 12 2019
This is still a problem. See https://en.wikipedia.org/wiki/Template_talk:Infobox_settlement#Category:Wikipedia_page_with_obscure_country_or_subdivision_and_this_template for a recent discussion where only about half of the articles had been updated after a month.
Feb 19 2019
This one is actually flagged as an error on en.WP:
Delete the manual line breaks after the /nowiki tags.
This would be a useful addition, if it is possible. I have fixed a few thousand pages with Linter errors, including many transcluded pages, on en.WP, and here are some things to consider:
A variant on this bug:
Possibly related: "left150px" is not recognized as a bogus option.
Possibly related: <code>|upright =1.5|</code> (with a space between "upright" and the equals sign) is ignored (the image renders as upright=1.0), but is not detected as a bogus option.
Feb 13 2019
See also the second example here:
Feb 3 2019
It would be great to have this feature request addressed. People are still able to add high-priority Linter errors to talk pages with every signature that they add. Here's an example from the last 24 hours: https://en.wikipedia.org/w/index.php?title=User_talk%3AMosrod&type=revision&diff=881456280&oldid=881435006
Jan 28 2019
Still happening. Please fix.
Dec 5 2018
The CS1 templates (on en.WP at least) have a df= parameter that Citoid could set based on the "Use XXX dates" template that is present in the article. That way, any supported date format could be entered into the cite template's date fields, and the df= parameter would format the dates correctly.
Reported so far at the following venues (that I have seen):
Nov 22 2018
This problem (adding nowiki tags around ISBNs in Visual Editor) is still happening. Here's an edit from 6 November 2018:
Oct 18 2018
Oct 15 2018
Oct 13 2018
Oct 3 2018
The bot is also leaving pipes in the url= parameter, causing the same error and breaking the URL. Pipes in the URL parameter should be replaced with %7c.
Sep 3 2018
Accessibility is a matter of WMF policy. Make this right, please.
Can someone please fix this Visual Editor bug? It is causing gnomes to have to do unnecessary work. In an extreme example, this VE-using editor unwittingly added Special:BookSources links to 170+ articles on a single day:
Of course they can change it. It's WordPress. It's almost as easy to change text in WordPress as it is to change text in a Wikimedia site! All they have to do is copy and paste the English over the German. This should have been done a month ago when the problem was originally pointed out.
Please fix this obvious bug by changing the German text to English as soon as possible. Once it is changed, you will have time to develop a reader-friendly, accessible way to demonstrate that WMF projects are available in multiple languages. I can think of a few; feel free to post here if you would like ideas from your volunteer and donor community.
Aug 28 2018
We still need this. Pages are still showing up every day in the Linter error page lists (for en.WP), even though the Linter lists were created many months ago. We can't fix the errors if they are not on a list or a category somewhere.
Aug 22 2018
I don't use RC either. I don't think I've ever even visited that page; the idea of seeing all recent changes is mind-boggling on en.WP. I suspect that the vast majority of active editors (on en.WP) use Watchlist but not RC.
Aug 20 2018
Replying to Quiddity above, assuming that the Watchlist works in basically the same way: To improve it, put a date/time stamp for the most recent change to the left of the page name, and show something like:
Jun 10 2018
Bumping this again. Every time I am away from WP for a few days, I am reminded of the pointlessness and waste of time involved in having to look at multiple links to see changes for each day. It is especially pointless since the "day" in question is arbitrary, based on the time zone my computer happens to be in.
Jun 5 2018
Please fix. This is still happening frequently.
Apr 4 2018
Bumping this. Can we get this running, please?
Jan 21 2018
The erroneous message is in "MediaWiki:Category-empty", and in English, it gives this incorrect message: "There are no pages or files in this category."
Dec 24 2017
Is this faulty edit (internal anchor links with manual superscript, and nowiki tags around ISBNs) related to this open bug?
Dec 5 2017
Dec 1 2017
All or most of these problems exist in the Vector skin as well, at least on en.WP.
Change can be jarring, and we'll get used to most of it, but the lack of bounding boxes or lines of some sort around each section is clearly a UI bug that should be fixed.
Nov 20 2017
You can see an example of the above bad data being imported into an article at https://en.wikipedia.org/w/index.php?title=Kelo_v._City_of_New_London&diff=prev&oldid=810668090
Nov 16 2017
Nov 15 2017
It seems like this particular problem would be resolved by displaying the aliases vertically in a list, rather than concatenating them horizontally. I do not know if that would have negative side effects somewhere else, however.
Nov 9 2017
This sounds great. One month seems like a reasonable update time.
Nov 6 2017
This is still happening, and gnomes need to clean up every time it happens. Can you please fix it? Here's one of the latest additions:
Sep 17 2017
This feature needs an opt-out button, i.e. "Do not show me these pop-up messages again".
Aug 29 2017
I don't know how it's happening. Maybe the editor who created the diff above will know.
Aug 28 2017
Jun 30 2017
It would be great to make some progress on this task. On en.WP, Category:Pages using ISBN magic links is still populating, seven months after the MediaWiki code change that created it. This bug is blocking implementation of things like the Tidy conversion and removal of magic links.
May 13 2017
This is probably the wrong venue for talking about changes to en.WP's MOS or CS1 templates, but the short version is that the "YYYY-MM" format is discouraged because of ambiguity. If an editor (or script) inputs "2004-05" to mean "2004–2005", the template rejects that ambiguous date format rather than convert it to "May 2004".
May 12 2017
Come on over to https://en.wikipedia.org/wiki/Help_talk:Citation_Style_1 and start a conversation. It can work: @Whatamidoing-WMF has been consistent in engaging with en.WP about Tidy going away, coming back with updates, and that has built some trust, at least within a small community of gnomes. Efforts like that will go a long way toward improving the relationship between en.WP and WMF.
Re: the "05, 2007" example above, I do not understand why it is a big deal to convert "May" into "Maio" if you are on the Italian Wikipedia. It's a straight one-to-one conversion for most languages. You must have a table somewhere. BattyBot task 25 uses a set of regexes on en.WP to do date conversions for many languages; the code is right there, ready for reuse.
May 3 2017
This, or something like it (ISBN with number inserted wrapped in nowiki tags) is still happening, even though all of the related bugs appear to be closed. See this April 25, 2017 edit:
May 1 2017
This is also happening here:
Same error message today with this file:
Apr 28 2017
Apr 12 2017
Yes please. This is a long-standing problem. Let me know if I can support this task in any way (testing or QA; I am not a developer).
Apr 10 2017
Bumping this. Having at least a user-modifiable setting to show changes without regard to artificial day boundaries would be useful.
Apr 6 2017
Apr 3 2017
This error should generate an error message at the site of the error, at least in Preview mode, so that editors have a fighting chance of finding (or at least being able to report) the problem.
Mar 28 2017
Note that magic links are going away.
Mar 27 2017
Any progress on this one? Can you run it with the automatic rate-limiter turned on? (I forget what it's called.)
Mar 12 2017
Feb 18 2017
Legoktm, thanks for tracking down this information. I agree with your judgement that editing a few highly used templates would achieve similar results to null-editing pages, but it would still take a long time (see the bug from which this task was forked for more information), it would clog up the job queue, and it would not systematically null-edit every page.
Feb 17 2017
With this change, will Tidy continue to process
reasonably? There are still articles on multiple WM installations with that invalid self-closed tag present.
Feb 16 2017
It doesn't make sense to change any templates until the root cause of this problem is identified. What has changed recently to cause this problem?
Feb 13 2017
I believe that the proportion of pages missing from the error category at en.WP is much lower because a few of us have done systematic insource searches for a long list of regex patterns and fixed errors that we found. I searched for many of these patterns a few months ago and found a large number of pages that were not in the error category. Now that the searches have been done, there should be very few pages left to add to the error category.
Feb 10 2017
If the upstream data has changed, maybe Citoid needs to be modified to strip the "PMC" characters from the PMC value, leaving only the numbers. This is just a guess.
Feb 9 2017
Thanks for forking this into its own bug. An update: I am still finding pages with self-closed HTML tag errors that have not made it into the error category. A null edit puts them in the category. We are now at eight months after the MW code change that created this error category.
Feb 3 2017
Dec 25 2016
Nov 15 2016
Nov 3 2016
Related to, or possibly a duplicate of, T106685.
I don't think this is a bug. The regex is malformed, so an error is returned. The regex in question should be: