See https://tet.wikipedia.org/wiki/Espesi%C3%A1l:Book/P%C3%A1jina_Mahuluk (or https://tet.wikipedia.org/wiki/Espesi%C3%A1l:MovePage/P%C3%A1jina_Mahuluk for unlocalized name)
Version: 1.24rc
Severity: major
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=68781
https://bugzilla.wikimedia.org/show_bug.cgi?id=71870
https://tet.wikipedia.org/w/api.php?action=query&meta=siteinfo&siprop=specialpagealiases
<specialpage realname="Movepage">
<aliases>
<alias>Book</alias>
<alias>MovePage</alias>
</aliases>
</specialpage>Special:Book is an alias for Special:Movepage.
WTF?
The last time someone moved a page was on 4 September. The same user asked on my talk page today why the Special page had suddenly disappeared.
Ah, I though Book was also a namespace and it was somehow conflicting. Sorry about that
I think this is an issue somewhere in the special page alias/localisation code.
SpecialPageFactory::getAliasList() says that "Book" is an alias for a special page named "Book", not Movepage...
The alias for "Book" is coming from the collection extension (even though it's not deployed), which is overriding the core alias.
I'm not really sure how to fix this...ideally we would just undo whatever caused this, but I don't know what did. CC'ing a few more people who might know what's going on?
(In reply to MF-Warburg from comment #4)
The last time someone moved a page was on 4 September.
Sounds like a collateral effect of bug 68781, then.
(In reply to Nemo from comment #10)
(In reply to MF-Warburg from comment #4)
The last time someone moved a page was on 4 September.
Sounds like a collateral effect of bug 68781, then.
This conflict has existed for a long time, since either the Collection extension was deployed to WMF wikis or since 'Book' was added as an alias for 'Movepage' in the tet language (whichever came last). It was just never noticed before.
Before bug 68781, the specialPageAliases list happened to have the aliases entry for 'Book' before the entry for 'Movepage'. A side effect of the fix for bug 68781 is that the aliases list is reordered, which in this case means the entry for 'Movepage' is now before the entry for 'Book'.
SpecialPageFactory::getAliasList() doesn't check for conflicts at all when taking all these canonical name to alias entries to construct the mapping of aliases to canonical names. It just happens to use the last entry for each alias. So when 'Movepage' was last it used that, and now that 'Book' is last is uses that instead.
The proper fix here is probably to eliminate the conflict by changing the Movepage alias in tet to something other than "Book". That'll also stop the potential confusion for people who enter the canonical name "Special:Book" expecting to get to the Collection extension's special page.
Another "fix" would be to add an entry for 'tet' to Collection.alias.php; this should have a side effect of causing the alias entry for 'Book' to be before the entry for 'Movepage' again, so the alias collision will happen to work like it used to.
Or, as a third option, we could construct the alias-to-canonical mapping in LocalisationCache so it can choose the aliases in order by the fallback chain. That'd increase the size of the l10n caches, though, and in this particular case it'd still have the problem that the canonical name for the special page wouldn't work on certain wikis because of a l10n override.
(In reply to Brad Jorsch from comment #11)
The proper fix here is probably to eliminate the conflict by changing the
Movepage alias in tet to something other than "Book".
This is what we'd do normally, though it's odd for an extension to trump core.
(In reply to Brad Jorsch from comment #12)
Or, as a third option, we could construct the alias-to-canonical mapping in
LocalisationCache so it can choose the aliases in order by the fallback
chain. That'd increase the size of the l10n caches, though, and in this
particular case it'd still have the problem that the canonical name for the
special page wouldn't work on certain wikis because of a l10n override.
This bug is still a Wikimedia issue though, isn't it? It wouldn't happen to a normal tet wiki with Collection disabled.
As for solutions in core, touching language fallback is overkill and practically certain to cause other problems. It would be mentally cleaner to make canonical names win over any alias: then we'd "only" have to bother about conflicts in canonical names, as usual.
I changed the alias now (https://translatewiki.net/w/i.php?title=MediaWiki:Sp-translate-data-SpecialPageAliases/tet&action=history) to make this problem go away.
However, maybe a change can be made so that the English name will always work? Currently Special:MovePage simply redirects to Special:Book which then doesn't exist.
(In reply to MF-Warburg from comment #14)
I changed the alias now
(<https://translatewiki.net/w/i.php?title=MediaWiki:Sp-translate-data-
SpecialPageAliases/tet&action=history>) to make this problem go away.
Unfortunately this change was so far not deployed.
However, maybe a change can be made so that the English name will always
work? Currently Special:MovePage simply redirects to Special:Book which then
doesn't exist.
Any opinions?
This bug has been marked "Highest" for a week now, would need an assignee. (Hint: translatewiki.net is not the assignee.)
(In reply to Nemo from comment #16)
This bug has been marked "Highest" for a week now, would need an assignee.
(Hint: translatewiki.net is not the assignee.)
"In order for these fields to retain meaning and effectiveness, communication is essential. For example, the priority Immediate or Highest has no meaning if no one has agreed to get it resolved quickly."
https://www.mediawiki.org/wiki/Bug_management/How_to_triage#Setting_priority
(In reply to Nemo from comment #13)
It would be mentally cleaner to
make canonical names win over any alias: then we'd "only" have to bother
about conflicts in canonical names, as usual.
Define "canonical". Is it the one that gets redirected to (which is just the first alias in the alias list, often localized), or the English alias that would theoretically work everywhere?
(In reply to Brad Jorsch from comment #18)
Define "canonical". Is it the one that gets redirected to (which is just the
first alias in the alias list, often localized), or the English alias that
would theoretically work everywhere?
The "first" English name, which IIRC is usually what we call canonical (terminology is not so well defined).
(In reply to Nemo from comment #19)
(In reply to Brad Jorsch from comment #18)
Define "canonical". Is it the one that gets redirected to (which is just the
first alias in the alias list, often localized), or the English alias that
would theoretically work everywhere?The "first" English name, which IIRC is usually what we call canonical
(terminology is not so well defined).
Isn't that exactly what this bug is complaining about, though? The first English name for the Collection extension's special page started winning out. You seemed to not prefer this situation in comment 13.
In JavaScript there's a global variable called wgCanonicalSpecialPageName [1], which is often used by scripts to detect if the current page is a specific special page, and that name is invariant of the wiki or user language.
[1] https://www.mediawiki.org/wiki/Manual:Interface/JavaScript#Page-specific
(In reply to Jesús Martínez Novo (Ciencia Al Poder) from comment #21)
In JavaScript there's a global variable called wgCanonicalSpecialPageName
[1], which is often used by scripts to detect if the current page is a
specific special page, and that name is invariant of the wiki or user
language.
I had thought for some reason that using that variable wouldn't necessarily work unless the name there was also configured as an alias, but now I see that I was wrong (it won't necessarily be listed as an alias, but it'll still *work*).
So the most-sensible behavior in general for translating "Special:Foo" to a special page seems to be to use the special page with wgCanonicalSpecialPageName "Foo" if any, then the special page that has "Foo" as its first localized alias if any, then whatever.
So in the case of this bug, Collection's Special:Book would still have won because "Book" is the canonical name. But at the same time, Special:MovePage should *not* have been redirecting to Special:Book; it should have used whatever the second-choice localization was.
Change 161499 had a related patch set uploaded by Anomie:
More sensible behavior when special page aliases conflict
Change 161499 merged by jenkins-bot:
More sensible behavior when special page aliases conflict
Niklas: If you (or someone) can prepare the backports, please add them to a SWAT window.
Change 162923 had a related patch set uploaded by Legoktm:
More sensible behavior when special page aliases conflict
(In reply to Nemo from comment #26)
Approved by Nikerabbit, would use backporting
I uploaded a backport to REL1_24 for Anomie's patch, but do we also need to backport MF-W's change to the alias?
(In reply to MF-Warburg from comment #30)
This core function will soon be broken for at least a month.
https://gerrit.wikimedia.org/r/#/c/161499/ was merged on September 25.
Do you want to imply that it did not fix the problem?
(In reply to Andre Klapper from comment #31)
https://gerrit.wikimedia.org/r/#/c/161499/ was merged on September 25.
Do you want to imply that it did not fix the problem?
The fix was reverted and restored several times.
(In reply to Andre Klapper from comment #31)
(In reply to MF-Warburg from comment #30)
This core function will soon be broken for at least a month.
https://gerrit.wikimedia.org/r/#/c/161499/ was merged on September 25.
Do you want to imply that it did not fix the problem?
Yes, check it for yourself on https://tet.wikipedia.org/wiki/Espesi%C3%A1l:Book/P%C3%A1jina_Mahuluk.
(In reply to Mark A. Hershberger from comment #35)
fix was was reverted
Did you read the bug? It was reverted and then restored.
(In reply to Kunal Mehta (Legoktm) from comment #36)
(In reply to Mark A. Hershberger from comment #35)
fix was was reverted
Did you read the bug? It was reverted and then restored.
Actually, it was never reverted out of master. Just on a wmf branch.
Change 162923 merged by jenkins-bot:
More sensible behavior when special page aliases conflict
(In reply to Andre Klapper from comment #34)
"Backport_WMF?" as that was set on 2014-09-25, I guess that can be reset
now? :-/
Guess that means yes - removing that flag.
Backport to REL_1_24 requested in comment 29 was merged in comment 38 - setting that flag to +.