Page MenuHomePhabricator

"Other languages" message is cached in the wrong language when the page is saved
Closed, ResolvedPublic

Description

Steps to reproduce:

  1. In Preferences, set your language to, for example, Polish.
  2. Go to a translatable page such as https://meta.wikimedia.org/wiki/Tech/News/2014/07.
  3. Edit that page.
  4. Set your language back to English.
  5. Force-reload the translatable page.

Expected result:

The text "Other languages:" appears in English, because English is the language of the page.

Actual result:

The text "Other languages:" appears in Polish (as "Inne języki:").

See Also:
T34686: "Page does not exist" title cached in wrong language

Details

Reference
bz60823

Event Timeline

bzimport raised the priority of this task from to Normal.
bzimport set Reference to bz60823.
bzimport added a subscriber: Unknown Object (MLST).

Cannot reproduce :/

Created attachment 14477
screenshot

This was what I saw after Nikerabbit's test edit to the page.

Attached:

Okay I can see it with Incognito mode logged out. Perhaps my regular user account has some cache busting trigger.

In PageTranslationHooks::languages() we do split the parser cache by user language, but then we go to use wfMessage() without passing the correct language code in, which might result the wrong language being cached. Not sure why those two languages would be different though.

In PageTranslationHooks::languages() we do split the parser cache by user language, but then we go to use wfMessage() without passing the correct language code in, which might result the wrong language being cached. Not sure why those two languages would be different though.

Bawolff, ideas?

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 12 2015, 9:58 AM

I can reproduce.

That's super odd

That's super odd

Specifically, I'm surprised we are still storing a parse on edit with "canonical" options. Now that we do all that in the job queue, I thought it would be deferred until then (as I think that's the first time its needed), but looks like that is not the case. I guess that makes sense, as we sort of make a linksupdate object, then turn it into a job, and then do it in the job queue, instead of just doing it only in the job queue.

I also thought we used to have some magic where the globals for user language somehow magically got changed when doing a parse with canonical options, that also appears not the be the case.


tl;dr: Use ->inLanguage( $parser->getOptions()->getUserLangObj() ) for any messages that's outputted by the parser that has to vary by user language. Or just use ->inContentLanguage().

Longer answer:

When someone edits a page, we save it once in their language, and once in the canonical content language ("en" for meta). This happens immediately on edit so the second parse in canonical mode, will still have globals for that user, so directly relying on user language with wfMessage() will result in cache pollution, only for the content-language version of the page.

Change 258730 had a related patch set uploaded (by Brian Wolff):
Don't rely on user lang globals for <translation> tags.

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

Thank you bawolff!

cache pollution, only for the content-language version of the page

This was happening to @guillom also for a page I edited, although it doesn't have anything to do with Translate: he saw the redlinks tooltips in Italian (my interface language). Is there a report covering that case too?

Change 258730 merged by jenkins-bot:
Don't rely on user lang globals for <languages/> tags.

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

Nikerabbit closed this task as Resolved.Dec 16 2015, 10:03 AM
Nikerabbit removed a project: Patch-For-Review.
Nikerabbit removed a subscriber: wikibugs-l-list.
matej_suchanek removed a subscriber: gerritbot.