If you set the interface language to something else and then open the page with ?uselang=en, you’ll also get the incorrect messages. Anonymous users are also affected: I see the same messages when downloading the page with curl.

Q55386965 is another example item where this happens, this time in Korean (I think).

Purging the page does fix this issue for that page, by the way (I tried that on some other item).

Adding [?uselang=en-gb](https://www.wikidata.org/wiki/Q52083822?uselang=en-gb) gets you the correct messages, even though at least wikibase-statementsection-statements does not have a specific en-gb version – it correctly falls back to en, even though ?uselang=en uses the wrong language. Curious.

Has anyone been able to reliably produce such a broken page? I tried opening and purging random items with my language set to German, but that didn’t seem to have any effect when looking at the items in English.

it correctly falls back to en, even though ?uselang=en uses the wrong language. Curious.

Makes it sound as if a cache for en is polluted but if it is using it as a fallback it does a new lookup...
Shot in the dark: In the [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+log/master/includes/Message.php | history of Message.php ]] there is one entry that triggers me, because it both talks about message cache and is almost 3 years old but was merged only recently: 174f0d2. However it was first contained in 1.32.0-wmf.7 (Jun 05).

I'll humbly have a look

Pinging Language-Team as it is related to i18n messages somehow. Although not sure if this is not just shooting blindly.
There has not been any recent changes to Wikibase code that could be causing such behaviour. At WMDE we are currently out of ideas what could have gone wrong here.

random observations:

• happens irrespective of uselang
• UI elements are affected
• formatted entity links are not affected
• UI elements rendered on the client side are not affected
• UI entitytermsforlanguagelistview table contents are not affected

And non-Wikibase parts of UI (see e.g. left side bar on the screen cap above) are also NOT affected.

That's already covered above, but re-rendering the UI element on the client side makes the translation be applied as expected.

e.g. hovering over the statement value rank icon (triangle circle triangle icon) the "tool tip" appears in non-English. Clicking edit, and then cancel, and hovering the icon again (now icon has been re-rendered on client), the tool tip is in English.

IMO this indicates issue is with the server-side translation only.

Do we want to rollback to .12 to at least confirm it's only present in .13?

And leave testwikidatawiki on .13 for replication/testing?

Change 447078 had a related patch set uploaded (by Reedy; owner: Reedy):
[operations/mediawiki-config@master] Rollback wikidatawiki to .12

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

@Reedy I guess that's the least we could given Wikidata devs have no better options to offer right now.

Change 447078 merged by jenkins-bot:
[operations/mediawiki-config@master] Rollback wikidatawiki to .12

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

Mentioned in SAL (#wikimedia-operations) [2018-07-20T14:11:04Z] <Reedy> T199983 wikidata wiki abck to .12 on mwdebug1001

Mentioned in SAL (#wikimedia-operations) [2018-07-20T14:15:40Z] <reedy@deploy1001> rebuilt and synchronized wikiversions files: wikidatawiki back to .12 T199983

Also pinging @aaron per below snippet from wikimeda-operations:

(16:11:51) Reedy: Didn't we have some cache corruption stuff with some of Aarons changes recently?
(16:11:59) legoktm: the mcrouter things?
(16:12:08) Reedy: yeah

Maybe that is related to the other wmf.13 blocker: T199941 That is related to language BCP-47 codes and there is patch for Babel https://gerrit.wikimedia.org/r/446766

Maybe Wikibase is affected in a similar way.

Probably caused by 92e96427425126ffe11beb999808de675d47e674

<3
Thanks folks!

Change 447110 had a related patch set uploaded (by Hoo man; owner: Hoo man):
[mediawiki/extensions/Wikibase@master] There are no "canonical" ParserOptions for Wikibase content

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

@hoo: As apparently you've managed to reproduce the issue(s) on your dev box, would you mind providing some instructions for other WMDE folks (as we've failed to test it on Friday)? Do you need some particular cache setup? Anything else? That would be extremely helpful!

@daniel @Anomie as you guys seem to be the most competent to figure out the way to fix it, your input on https://gerrit.wikimedia.org/r/447110 is much appreciated!

Change 447399 had a related patch set uploaded (by WMDE-leszek; owner: WMDE-leszek):
[mediawiki/extensions/Wikibase@master] Pass LocalizedTextProvider instance to "view factory callbacks"

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

@hoo friendly but serious reminder: this is the only blocking task of the current train that does not have a clear way forward. Is there anything we can do here to unblock the train?

Merging https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/447110 will probably unblock the train, although this task should probably remain open until the real fix can be figured out. PS4 there may not be the best hack it could be, but (assuming it works) it seems good enough for UBN.

I've reproduced the issue (finally). I am embarrassed it took me that long.

Here are the steps I took:

1. Login as a user.
2. Change user language in user preferences to non-English.
3. Go to item or property.
4. Make an edit (e.g. add a statement).
5. Open the item or property page as a anon user (e.g. in private browser window)
6. Be surprised to see e.g. Statements header NOT in English

Interestingly, this procedure does not seem to lead to issues on beta wikidata... Different parser cache setup?

Change 447110 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Don't save to ParserCache if not parsing for current user

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

Removing T191059: 1.32.0-wmf.13 deployment blockers as the parent task because of T199983#4447103 and T191059#4447107.

This issue is still occurring, lest anyone think we're done. I just got it on https://www.wikidata.org/wiki/Q55471970 when logged in.

Can you please try purging and see if it still happens for you? I can no longer find an item where it is a problem after that.

When did the fix make it to wikidata.org? I've seen it happen on items last edited on the 26th, e.g. https://www.wikidata.org/wiki/Q20899801

Purging the page has always fixed the page for me, even when the problem first started.

Q20899801 is indeed still affected. Is the individual purge the recommended mitigation or will we try to batch this (if it's the way to go)?

I just got French text on https://www.wikidata.org/wiki/Q1035 (with language set to English) but a purge fixed it.

When did the fix make it to wikidata.org?

If I read logs right, it indeed was on July, 26th, around 9:50 UTC.

@Daniel_Mietchen: last edit made on July, 25th, which was the time before the fix was deployed, so this all would explain the problem, given what said above.

With the fix live and working, and T201170 filed for the proper solution, this can probably be closed.

Change 447399 abandoned by Addshore:

[mediawiki/extensions/Wikibase@master] Use the same language code in ViewFactory and EntityView constructors

Reason:

Abandoning all Wikibase.git patches that have not been touched since 2019.
If you want to revive this patch, or keep it around for your reference please re open it!
We just got to below 100 open changes for Wikibase.git!

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