Page MenuHomePhabricator

Edit links in different language to rest of User-Interface after "uselang" specified.
Closed, ResolvedPublic

Description

Author: nickpj

Description:
Note: Need to be logged in for this to work; and the language used in the
"uselang" parameter doesn't seem to matter, as long as it's valid.
Step 1: Go to
http://en.wikipedia.org/w/index.php?title=Outer_Mongolia&uselang=pl&action=purge
... and all of the UI is in Polish (which is fine and expected).
Step 2: Go to http://en.wikipedia.org/w/index.php?title=Outer_Mongolia ... and
then only the edit links show in Polish (see "[edytuj]" not "[edit]"), but
everything else (sidebar, header, etc) is in English (which is not fine -
shouldn't the UI all be in one language?).
Step 3: Then I press F5 / refresh, and still only the edit links show in Polish,
everything else is in English (which is still not fine).


Version: 1.8.x
Severity: minor

Details

Reference
bz7676

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:26 PM
bzimport added a project: MediaWiki-Parser.
bzimport set Reference to bz7676.
bzimport added a subscriber: Unknown Object (MLST).

ayg wrote:

It doesn't happen for me. Everything is in English when I go to the second
link, as expected (since uselang wasn't specified).

nickpj wrote:

Does it happen for you on a test wiki? (Just trying to eliminate squids /
caching / multiple servers / other users / etc from the equation).
E.g. for me, if I go to my test wiki's Main Page with a uselang + purge argument:
http://192.168.0.64/wiki/index.php?title=Main_Page&uselang=ja&action=purge
And then go to the same page without the uselang arg:
http://192.168.0.64/wiki/index.php?title=Main_Page
... then I see the edit links in a different language (Japanese in this case),
but the rest of the UI in English.
Even after repeatedly pressing refresh / shift-refresh / ctrl-refresh, or
clicking the "Article" link, all the edit links are still in the wrong language.
The only way to stop the [edit] links being in the wrong language seems to be to do:
http://192.168.0.64/wiki/index.php?title=Main_Page&action=purge
I guess the questions are: A) Am I the only one to experience this behaviour? B)
Is this normal / expected?

ayg wrote:

Doesn't happen on a test wiki for me either.

nickpj wrote:

Method:

On IRC channel MediaWiki-General have 3 users performing 4 tests relating to this.

Test-1 = On your local private dev test wiki, login, and follow the test above
(specify uselang + purge, then open the page again without uselang or purge).
Test-2 = Repeat test-1, except on http://theplaypit.nickj.org/ (a SVN checkout
of r17215, with minor modifications which should be unrelated to this).
Test-3 = Go to http://theplaypit.nickj.org/wiki/index.php?title=Fake2&uselang=de
, are the edit links in English or German?
Test-4 = Repeat test-1 on the English Wikipedia, as per comment #1.

Fail = the edit links are not in the expected language (either English where
uselang is not specified, or are not in the requested language where as uselang
parameter was specified).
Pass = the edit links are in the expected language.
???? = results not known.

Results:

.User:..|..Nickj..|..Simetrical..|..Fyren
--------+---------+--------------+-------
Test-1:.|..Fail...|..Pass........|..Fail.
Test-2:.|..Pass...|..Pass........|..Fail.
Test-3:.|..Fail...|..Fail........|..Fail.
Test-4:.|..Fail...|..Pass........|..????.

robchur wrote:

The parser calls Linker::editSectionLink() to construct the links. This function
uses wfMsg() to retrieve the text for the link.

The problem is that the parser cache key varies based on the language preference
for which it is told to render, which is *NOT* the same thing as $wgLang.
$wgLang is initialised* from $wgUser's language preference, overridden with the
value of uselang, if present in the request...

...to boil it down - the thing that makes the edit links will respect uselang if
present, but the parser cache doesn't know anything about that, leading to a
cache inconsistency.

[* Forget the StubObject origins.]

nickpj wrote:

May have been fixed by Tim in r18850 ; I can no longer reproduce, so I'm going
to mark this as resolved (but please reopen if anyone can reliably reproduce on
a recent SVN checkout and/or on MediaWiki >= 1.9.0).