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 T62823#652161, @Nikerabbit wrote:

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?

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?

T34686#371887

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

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