Page MenuHomePhabricator

References with no visible content are reported as empty now
Closed, InvalidPublic

Description

It turns out the fact a <ref> </ref> with the only content being whitespace was indeed used as a feature: https://de.wikipedia.org/w/?oldid=188779548. The current revision is already fixed: https://de.wikipedia.org/wiki/Adelsgesellschaft.

Reported at https://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia#Kategorie%3AWikipedia%3ASeite_mit_Einzelnachweisfehlern. As far as we know this is the only article on German Wikipedia.

More detailed explanation:

For the extends="…" feature it was decided that a <ref extends="…"> </ref> with no visible content should behave the same as <ref extends="…"></ref> and <ref extends="…" />. This decision was made before we realized the existing code was applying trimming in a very inconsistent way. While we tried hard to not change any existing behavior, we decided it would make the situation worse to report <ref extends="…"> </ref> as invalid, but not <ref> </ref>. This user-facing change went live on all Wikipedia wikis with wmf.8 on December 5th.

What the article effectively does is using grouped, but otherwise empty <ref> and <references> to create paired anchors that can be used to jump back and forth between linked sections. The code for this used to look like <ref group="1"> </ref> and <references group="1" /> before it started displaying errors.

The same effect is typically achieved using the Anker template, e.g. {{Anker|hoch1}}[[#runter1|↓]] and {{Anker|runter1}}[[#hoch1|↑]].

Another possible workaround is to use other kinds of invisible content, e.g. <ref group="1"><i></i></ref>, or a tiny HTML snippet or template that uses display: none. We don't plan to consider this "having no content".

This ticket is to collect all examples we are being made aware of, and possible discuss if we need to consider this a Regression.

Event Timeline

Yikes! What happened to this article is horrid. Don't throw error messages in the middle of an article.
Even worse, for German readers the article is spammed with foreign language garbage text.

  • This is the same article that's already listed above, and the only one we know was affected. Are you aware of another one?
  • The Cite extension displays some messages in the text since it was created in 2005. This hasn't changed.
  • These messages should be displayed in the users language. If they show up in a foreign language, that would be a bug. Please open a new ticket if this is the case.
  • If there is literally "garbage text", translatewiki.net either got spammed or one of the messages was not good to begin with. Please report this separately.

I don't think I have ever before seen the software dump a message like this into an article, outside of preview or the reflist-block. It is seriously horrid behavior. Remember, almost everyone looking at the page is a reader, and our primary job is to present the page for that reader.

Part of being a wiki is that the software has to make a best-effort to display a reasonable page, even if the software is unhappy/confused by what some random user did.

Personally, I agree. But as said the <ref> feature behaves like this since 2005. There are some ideas how this can be improved (see T238061), but this is barely in the scope of the currently ongoing Cite-Extends project.

Also please note this discussion is misplaced here and won't be seen by anybody. You can comment on T238061 or open a new ticket if you feel what you have to say doesn't fit in T238061.

Here is an older report where the previous behavior of not trimming the content was reported as a bug: T117037: Named ref are considered different when the content is a whitespace for refs 2 to n. I closed the ticket as already being resolved, and would like to add it to the list of arguments to keep the current behavior.

No other complains for 2 years now. Let's stick to the original decision to trim whitespace in all cases.