Change 995055 had a related patch set uploaded (by Thiemo Kreuz (WMDE); author: Thiemo Kreuz (WMDE)):

[mediawiki/extensions/Cite@master] Make it possible to disable the "cite_error" wrapper message

https://gerrit.wikimedia.org/r/995055

Change #995055 merged by jenkins-bot:

[mediawiki/extensions/Cite@master] Make it possible to disable the "cite_error" wrapper message

https://gerrit.wikimedia.org/r/995055

Thiemo has also found a special behavior which will be challenging to reimplement: simply adding a tracking category to all pages where a Cite error occurs might not be fully equivalent to the logic on some wikis, which conditionally adds special tracking categories depending on the type of error or in specific namespaces. In other words, some errors are being ignored.

Conditionally changing the name of tracking categories based on namespace is "standard" tracking category behavior; see https://en.wikipedia.org/wiki/Special:TrackingCategories and every box with more than one link in the "Tracking category" column; eg https://en.wikipedia.org/w/index.php?title=MediaWiki:Broken-file-category&action=edit

So that should work if they "just" add a tracking category.

Can I get some more details on "option as long as the communities use them heavily for all kinds of customizations (tracking categories, custom templates)." An enumeration of the "special" messages and the "special" things they are doing will help us work through the list to find better solutions to each.

We would love to share numbers, but we don't have them yet.

GlobalSearch is probably a good start: https://global-search.toolforge.org/?namespaces=8&q=.&regex=1&title=Cite.(error|warning)(/.*)%3F. Patterns we see so far include:

• Some of the overrides still mention a parameter $2. This is dead code since 2007, see https://phabricator.wikimedia.org/rECITb3b7be4e.
• Some communities just add a bit of styling, e.g. make the text smaller.
• Some add a tracking category only in some namespaces, but not in others.
• Some invoke a complex Lua module with lots of special cases that change the behavior not only based on the namespace, but also based on the specific error message. This is the main reason why we believe we can not touch this message without serious communication efforts.
• We noticed that some communities hide the error messages completely and make them an opt-in feature.
• … more?

Many things about Cite error overrides are surprising, so I'll join in with a few notes about how communities hide the error messages. On English Wikipedia, every system message for cite errors is overridden separately, and the template {{Broken ref}} used to wrap the message: https://en.wikipedia.org/w/index.php?search=insource%3A%22Broken+ref%22&title=Special:Search&profile=advanced&fulltext=1&ns8=1

Then, the template does some wild things with the Lua Namespace detect module, which may or may not result in an application of Broken ref/styles.css and wrapping in a <span class="brokenref"> which defaults to display:none

It's... not simple! Hopefully we can turn this into community configuration rather than reimplementing...

It sort of sounds like "suppressing error messages by namespace" should be a core feature, not something folks have to reimplement with hacks. If you were to replace the current cite-error w/ $1=cite-error-foo with cite-error-article-foo and cite-error-nonarticle-foo it seems like most (but probably not all) hacks could be removed. "Only in some namespaces" seems (looking at the search results) to almost always be "only in namespace 0".

On the other hand, the fact that you can suppress all errors in a certain namespace by hacking "just" the cite-error message, instead of separately adjusting the dozen-ish cite-error-* messages, seems to be a feature. Perhaps as a product request the desired feature would be to pull the suppression capabilities of {{broken ref}} into the server side code, controlled by community configuration, so that they wouldn't have to hack those things into the message.

That could be done incrementally; that is, you'd add community configuration first, and then individual wikis could replace their {{broken ref}} and/or other customizations with the appropriate community configuration once that feature provided equivalent functionality. Doing just "suppression by namespace" first would allow the first 3-4 wikis to convert, etc.

This still doesn't solve the "lego error messages" i18n issue, but at least it would decouple that from the general configuration happening here.

Yes! And we could do a bit of product work with communities about the deeper needs behind the features they've set up in wikitext. My armchair impression is that they want errors to show up in the interface language (as much as that disturbs me), maybe they want certain errors to appear and others not, and they want the ability to hide errors for users but show them to reference-focused maintainers...

On the other hand, the fact that you can suppress all errors in a certain namespace by hacking "just" the cite-error message, instead of separately adjusting the dozen-ish cite-error-* messages, seems to be a feature.

I don't think it's a big deal if English Wikipedia has a few more messages/categories to customize such that it needs full on Community Configuration first. And as one might be able to see in that global search above, there's only about a half dozen wikis similar to en.wp on the point. I'd suggest just fixing what needs fixing.

As a note for future self next time I open this ticket: the current behaviour of removing only the wrapper and not the full message is (very) problematic for Parsoid (i.e. I have no idea how to implement that right now).

I agree with Scott that

On the other hand, the fact that you can suppress all errors in a certain namespace by hacking "just" the cite-error message, instead of separately adjusting the dozen-ish cite-error-* messages, seems to be a feature."

In particular, if only removing the wrapper is desired, then the solution is to put $1 in the custom message, not -. Overall, I'm not convinced that https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Cite/+/995055 was actually the right thing to do, because it does change the behaviour for overriding wikis quite a bit.

@ihurbain Sorry to ask, but it seems like I'm missing an important bit. From my perspective https://gerrit.wikimedia.org/r/995055 alone doesn't change anything. I specifically designed it to allow the wrapper message to be either "$1" or "-". Both works.

@thiemowmde Don't apologize, it seems clear we have a different understanding of this code :D

I do believe that that patch changes the behavior on "-": before the patch, neither the wrapper nor the message is displayed; after the patch, only the wrapper is hidden.
(Although I'm *almost* sure that having "-" in cite_error used to disable the whole thing at some point, and if I only revert this single patch I have "-" displayed as error message in my local wiki).

Oh, and for further clarity: I'm talking about wikis that *currently* change that message to "-" or "" (as it is the case for pswiki https://ps.wikipedia.org/w/index.php?title=%D9%85%D9%8A%DA%89%D9%8A%D8%A7%D9%88%D9%8A%DA%A9%D9%8A:Cite_error)

Ok, I see.

The behavior for "-" was indeed that the dash would be displayed. That was not really useful for anything. https://gerrit.wikimedia.org/r/995055 changed that to do something useful.

The behavior for "" did indeed change. However, it turns out our wikis don't use this. What they do instead is some template syntax that conditionally (e.g. depending on the namespace) outputs an empty string or a category. This still works as before. Such messages are not considered disabled according to Message::isDisabled.

It looks like all local overrides contain the placeholder $1. About 30 contain template syntax. About 40 don't. GlobalSearch makes it look like no override is empty (why doesn't it find the pswiki example?). From the 5 that contain a dash none uses it to disable the message.

I would like to argue that emptying this message was never a supported feature. I mean, what's even the point? Doing so doesn't even leave a category behind. <ref>s just disappear and nobody has the slightest clue why. There are multiple other ways to achieve the same, e.g. CSS.

Your link to "all local overrides" is to a search that contain the string $1 (and indeed they do :) ), and I can't manage to get a GlobalSearch that displays all local overrides. I have not managed to exhibit pswiki in GlobalSearch for this (I wouldn't be surprised if GlobalSearch/CloudElastic, maybe?), and that may be a sign that other wiki does the same thing.

I would say that this was not an *intentional* feature (considering the fact that this string has been there since the early time of that code), but I couldn't have said with any confidence that it's *not* a feature. I will allow that the fact that it's been merged and in production for more than a year without anything getting reported is a good sign of that, though, and I'm not trying to make problems where none exist.

I still have no idea how to implement that on the Parsoid side of things, though. But, one problem at a time, probably.

I compared the search for »$1« with a search for ».*«. Both find 72 results.

I expected the regex ».*« to find empty pages as well. Turns out T326994: Global search can't find empty pages. 😢️

in production for more than a year without anything getting reported is a good sign […]

Haha, true. 😆️ And it makes sense when I think about it. I mean, what would you do when you suddenly see a ref error in an article? I would fix the ref error in the article.

still have no idea how to implement that on the Parsoid side […]

You mean the "disable" part? We can undo that if it turns out to be a blocker for Parsoid. The most likely way forward I currently see is to replace the content of the two messages with nothing but "$1" (as described in this ticket) but otherwise leave them in place.

Change #1154075 had a related patch set uploaded (by Thiemo Kreuz (WMDE); author: Thiemo Kreuz (WMDE)):

[mediawiki/extensions/Cite@master] Remove cite_warning wrapper message in favor of cite_error

https://gerrit.wikimedia.org/r/1154075

Change #1154075 merged by jenkins-bot:

[mediawiki/extensions/Cite@master] Remove cite_warning wrapper message in favor of cite_error

https://gerrit.wikimedia.org/r/1154075