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:
Just another example, if it helps to find a solution to this problem.
Oct 26 2016
One of the benefits of using a template is that it allows for easy validation of ISBNs, the display of error messages for invalid ISBNs, and categorization of pages with invalid ISBNs. Are those features available with parser functions?
Oct 22 2016
This may be related to, or the same as, T18683.
This is still a problem. Examples:
Including User pages in the report also results in false positives, like "Template:' + 'subst:afd" being listed on the report. Actually, this looks like a Wikimedia bug. I'll see if there is another phab report.
It would be great to have a list that excluded transclusions in the same namespaces that are excluded from Citation Style 1 error categorization (in en.WP at least), namely Book talk, Category talk, Draft, Draft talk, Education Program talk, File talk, Help talk, MediaWiki talk, Module talk, Portal talk, Talk, Template talk, TimedText talk, User, User talk, and Wikipedia talk. Transclusions and errors in those namespaces are sometimes not fixable (e.g. .js files in User space), are often examples that should not be "fixed", or do not degrade the reader's experience.
Oct 8 2016
Is this supposed to check for self-closed instances of every tag listed on lines 376-381 of https://gerrit.wikimedia.org/r/#/c/286928/11/includes/Sanitizer.php ?
Oct 7 2016
Sep 28 2016
Sep 4 2016
This doesn't seem quite right. "Ennis" should come before "Ennis Jones" and before "Ennis-Jones". Not to make this too circular, but quoting https://en.wikipedia.org/wiki/Alphabetical_order, "If the first letters are the same, then the second letters are compared, and so on. If a position is reached where one string has no more letters to compare while the other does, then the first (shorter) string is deemed to come first in alphabetical order." Or as my librarian in grade three taught us, "Nothing comes before something."
Aug 11 2016
Jun 29 2016
Thank you. I have posted an edit request at that page on en.wiki.
I would love to do it myself (for everyone, not just in my own vector.js). @IKhitron, do you have a link to instructions on how to take care of it on en.wiki? Thanks.
Jun 28 2016
If possible, it might be a good idea to limit the namespaces to which this category applies. For an example, see the Citation Style 1 error messages and categories on en.wiki, e.g. "Category:Pages with archiveurl citation errors":
Jun 14 2016
I reported this to the Zotero developers:
Feb 5 2016
Jan 29 2016
If this is the feature that was rolled out by mistake on en.WP yesterday, it is not done being developed yet. See https://phabricator.wikimedia.org/T125171 for comments about its implementation. Specifically, editors need to be able to choose whether to show/hide category additions and category removals on the Watchlist page. They should be able to show or hide either one or both. Hiding both would mean that you just want to watch the content of the Category page itself (e.g. to monitor for vandalism or explanatory text changes).
There should also be a checkbox in the "Hide" section of the Watchlist page to hide/show removals and to hide/show additions to categories. Often I only want to see one or the other.
Jan 28 2016
This task is "Approved" as done as part of the Google Code-in. I will take care of implementation from the sandbox and subsequent troubleshooting. Great work, Pranavmk98.
Jan 22 2016
Super. Now we need to wait a few days for feedback before changing the BillboardID template to add the tracking category. Changing "illegal name entered" to "invalid artist" in the subtemplates is optional, but it makes the error message more consistent with other error messages on Wikipedia and with the new category's name.
I added a new, simplified section to the singlechart testcase page so that it actually shows the desired error and emits the error category without any spurious reference errors.
Jan 20 2016
The point of the request is that language=English is no longer an unnecessary parameter, therefore AWB should not remove it anymore.
Jan 19 2016
Make sure to add each of the template sandboxes to your watchlist and check your watchlist to see diffs when I change something.
You have to modify the sandbox version of each template to call the sandbox version of the templates that it calls. See my recent changes to Singlechart and BillboardURL for an example.
I removed white space in the template that was breaking URLS, and I added some examples to your user sandbox. Use your sandbox as a page for test cases to make sure you understand how the live templates work. Examples of the live templates and of your sandbox, using valid artists, should always work.
That's progress. To make it useful, the templates that use BillboardID should emit this category in a reasonable way. That includes:
Jan 18 2016
I have also create this sandbox:
Sorry, I assumed more familiarity with how Wikipedia works. First, look at the "death date and age" template I linked above, click on the sandbox link in the documentation, click on View Source (or Edit), but do not save, and walk through the template's syntax until you have a basic understanding of how it works, especially the error categorization.
First, read the talk page: https://en.wikipedia.org/wiki/Template_talk:BillboardID
Jan 8 2016
See discussion here:
Nov 7 2015
I will mentor this in #GCI2015
Nov 3 2015
I don't have the gerrit skills to parse the code to understand whether this change will allow a page to emit a tracking category specific to monitor articles and templates that need to be updated. If it will, some instruction would be helpful. If it currently will not, please make whatever code modification is necessary to allow a page to emit such a tracking category. Thank you.
Oct 29 2015
I am seeing similar behavior on en.WP. This change is not limited to Commons.
Oct 19 2015
This may be a subset of T14930. As explained in that long-standing request, we need a tracking category added any time one of these new error messages is created.
Oct 9 2015
This is still happening. See https://en.wikipedia.org/w/index.php?title=C%C3%BAllar_Vega&type=revision&diff=684709457&oldid=662429942
Sep 11 2015
I see that this patch has been committed. I'm looking forward to this fix being put in production, as I am fixing a few of these errors daily at en.wp.