Page MenuHomePhabricator

Wikidata showing wrong language for page elements
Closed, ResolvedPublic

Description

I opened the page https://www.wikidata.org/wiki/Q52083822 and it is showing Czech language for the page-content's section headings. My interface language is set to English, and if I switch to German (which works as expected) and then back to English it still shows the Czech headings.

Screenshot at 2018-07-19 12-08-26.png (743×1 px, 97 KB)

Screenshot at 2018-07-19 12-08-16.png (743×1 px, 131 KB)

I have purposefully not tried purging the page, in case that helps you reproduce/diagnose.
Addshore suggested it was probably related to page-cache getting mixed up somehow.

Other users are reporting the same problem, with other languages and items, at https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team#Interface_language_bug


See T201170: Allow wikibase to render entities for an arbitrary target language, instead of the user's UI language for a complete solution.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

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).

Lea_Lacroix_WMDE triaged this task as Unbreak Now! priority.Jul 20 2018, 10:40 AM
Lea_Lacroix_WMDE subscribed.

(Lydia here)

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

Bildschirmfoto von 2018-07-20 15-39-02.png (856×1 px, 104 KB)

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

Reedy lowered the priority of this task from Unbreak Now! to High.Jul 20 2018, 2:19 PM

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.

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 moved this task from Incoming to Peer Review on the Wikidata-Campsite board.

@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

zeljkofilipin raised the priority of this task from High to Unbreak Now!.Jul 23 2018, 3:24 PM
zeljkofilipin subscribed.

Changing priority to UBN since it's blocking the train.

Friendly reminder: the train is blocked because of this task. (It's not the only blocker at the time I write this.) Any updates?

@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

WMDE-leszek lowered the priority of this task from Unbreak Now! to High.Jul 24 2018, 8:39 AM

With https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/ /447110 being merged the issues should not happen any more. Therefore lowering the priority again.

As @Anomie mentioned, not closing the task yet though. It should stay open until the proper fix is in place.

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)?

Bildschirmfoto von 2018-07-30 16-15-15.png (1×1 px, 188 KB)

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.

daniel updated the task description. (Show Details)

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

Lydia_Pintscher claimed this task.
Lydia_Pintscher moved this task from Test (Verification) to Done on the Wikidata-Campsite board.

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