Page MenuHomePhabricator

Show an error if a named <ref> is defined multiple times with different content
Closed, ResolvedPublic

Description

Cite should show an error if a named <ref> is defined multiple times (with possible different text).
We identified this at dewiki as a relative often error with at least 12.000 occurrences.
Maybe at first there should be only a tracking category added.

Example:

car is red<ref name="car">source: red car</ref>
car is blue<ref name="car">source: blue car</ref>

Effective reference: source: red car

Event Timeline

Se4598 raised the priority of this task from to Needs Triage.
Se4598 updated the task description. (Show Details)
Se4598 added a project: Cite.
Se4598 subscribed.
eranroz set Security to None.

Change 226464 had a related patch set uploaded (by Eranroz):
Show an error if a named ref is defined multiple times

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

An error (that all users would see) seems too much, especially as the content can be identical. A tracking category is a good idea.

An error (that all users would see) seems too much, especially as the content can be identical. A tracking category is a good idea.

If you read the discussion in gerrit, the current work is just on non-identical multiple definitions.

This will need a similar fix in Parsoid after the core cite extension has this fixed.

Change 226464 merged by jenkins-bot:
Show an error if a named ref is defined multiple times

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

matmarex edited projects, added User-notice; removed Patch-For-Review.
matmarex subscribed.

The change has been merged and will be deployed to Wikimedia wikis between 6 and 8 October with MediaWiki version 1.27.0-wmf.2, per the schedule at https://www.mediawiki.org/wiki/MediaWiki_1.27/Roadmap.

matmarex renamed this task from Show an error if a named <ref> is defined multiple times to Show an error if a named <ref> is defined multiple times with different content.Oct 6 2015, 6:11 PM

Hello, @matmarex, why did you change this? You mean the new future can't recognize the error of the refs with the same name and the same context?

Yes, defining the same ref multiple times with the same content is explicitly not an error, primarily to support template-generated refs (and transclusion in general).

Features that rely on the current behavior include {{sfn}} citations, various infoboxes and navboxes that generate references (I know of Zwierzę infobox (Infobox animal) on pl.wp, my home wiki), templates defining content reused on multiple pages (e.g. the tables in United States at the 2008 Summer Olympics are also reused in more detailed articles for each discipline) and Wikisource books (which have to display the references on individual pages, but also when all of the pages are transcluded together; I've been pointed to Polish Wikisource books using this, but no doubt examples in other languages also exist).

I see, @matmarex. Thanks. Looks reasonable. So after I'll fix different content on our wiki, I'll rerun the bot that searched any content before this feature was added, to delete same text on the SAME page.

PS: I changed Help:Extension:Cite accordingly.

By the way: I checked now on enwiki, it doesn't work yet. Special:Version shows October, 6 for Media Wiki and October, 5 for Extension:Cite. Something wrong?

No, all is fine. The English Wikipedia is still running 1.27.0-wmf.1, while this patch is included in 1.27.0-wmf.2 (the next version), which currently is deployed on only one production wiki: mediawiki.org (see https://www.mediawiki.org/wiki/MediaWiki_1.27/Roadmap). You should be able to test it there.

1.27.0-wmf.1 has only seen small updates during the last week. Looking at https://phabricator.wikimedia.org/diffusion/MW/history/wmf%252F1.27.0-wmf.1/, changes since "Creating new WMF 1.27.0-wmf.1 branch" include some small backported hotfixes (for example rMW53edbe109065, which fixed an issue with Vector's watch star) and Ori's performance work.

For the English Wikipedia, stay tuned for two more days :)

It seems to work if you add <references/>, which most pages probably have. Still, it should work without it as well. I'll investigate.

Thanks. And it is indeed a problem, because some user forgot to do not know about using <references/>.

3 more issues (see https://www.mediawiki.org/w/index.php?title=User:IKhitron/draft&oldid=1910217 for all of them):

  1. The MediaWiki message should finish by newline, otherwise, it is continued by irrelevant text from the page.
  2. The MediaWiki message should include group name $ parameter (if any), to distinguish different refs with the same name.
  3. If the page has 5 refs with the same name and different content, there are 4 MediaWiki messages there. Is it correct?

In the new patch, 2 became irrelevant.

It might be worth noting that Cite won't raise this kind of error unless a <references> tag is provided: with (error) and without (no error).

Yeah, that's unintentional and tracked on T114898. I'll try to get that fixed tomorrow.

And also 1 is irrelevant. Somebody can answer about 3? (An answer "Yes, it is", will be good enough, if you think it's the right one.)

Yes, it is. It's a bit ugly but IMO it's fine.

Hi, thanks for this great idea. But in not latin wikis it is very difficult to use it because it looks like "

Invalid <ref> tag; name ".D5.A9" defined multiple times with different content

instead of

"Invalid <ref> tag; name "թ" defined multiple times with different content"

Is it possible to solve this error?

Indeed. I solved it a lot of time ago. You should lua-decode the text of the parameter. Do you understand me, or I'll explain the details, @Ashot1997?

Indeed. I solved it a lot of time ago. You should lua-decode the text of the parameter. Do you understand me, or I'll explain the details, @Ashot1997?

Thanks for reply․ But I do not understand you. If it is not difficult, @IKhitron

Macro please-explain:

OK.

  1. (I already did this for you here) Create new page "Module:Decoder" with the code
function main(frame)
	return mw.uri.decode(frame.args[1])
end
return {main = main}
  1. (I already did this for you here) Create new page "Template:Decode" with the code
{{#invoke:decoder|main|{{{1|}}}}}
  1. (I can't do this fo you, I need sysop rights) Create new page "Mediawiki:Cite error references duplicate key". You'll see there the code
$1

Replace it with the code

{{decode|{{replace|$1|.|%}}}}

That's it, @Ashot1997. Tell me if it works. I hope I wrote all as needed, if no - we'll fix.

Hi, thanks for this great idea. But in not latin wikis it is very difficult to use it because it looks like "

Invalid <ref> tag; name ".D5.A9" defined multiple times with different content

instead of

"Invalid <ref> tag; name "թ" defined multiple times with different content"

Is it possible to solve this error?

I looked into this and it doesn't seem possible to easily fix this, sorry :( The patch for T114898 should make it display the error message next to the affected ref, though, making it easier to find which one the error is about.

@IKhitron, thank you very much, it works fine. Displaying the error message next to the affected ref is also great idea.

You are welcome, @Ashot1997.
@matmarex, it works fine in many other cite error messages. What is different here?

The other error messages are usually generated immediately when parsing the <ref> tags, at which point they have access to the original attributes. This one is generated when parsing the <references> tag, at which point the original name for each ref has been encoded into a form suitable for using as an id attribute in HTML. It's of course not impossible to fix it, but it would require some careful refactoring of code I'm not familiar with and that I'm afraid to break :)

Thank you, @matmarex. I can understand now why "mediawiki:cite error references no text" has the same problem. But why "mediawiki:cite error references missing key" has this problem? It is evaluated immediately.