Last modified: 2014-09-12 17:36:03 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T70781, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 68781 - Incorrect use of Russian translation on Ukrainian wiki when Ukrainian translation available (incorrect fallback merging?)
Incorrect use of Russian translation on Ukrainian wiki when Ukrainian transla...
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
Deployment systems (Other open bugs)
wmf-deployment
All All
: High normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: i18n
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-07-29 03:22 UTC by Matthew Flaschen
Modified: 2014-09-12 17:36 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Matthew Flaschen 2014-07-29 03:22:01 UTC
This is an apparent separate bug discovered in the course of bug 67805.

Niklas suggested, "LC issue is possibly caused by incorrect fallback merging, because L10nupdate contains update for ru, but not for uk (because the translation is already up to date for uk):"
Comment 1 Brad Jorsch 2014-07-29 11:26:52 UTC
Further detail from bug 67805: "I tracked that one as far as observing that the json file for uk that the cdb file gets built from has "Править вики-текст" as the value for messages:visualeditor-ca-editsource rather than "Редагувати код"."

So the problem seems to be in the (new JSON-based) l10nupdate process.
Comment 2 Andre Klapper 2014-07-30 10:03:06 UTC
(In reply to Brad Jorsch from comment #1)
> So the problem seems to be in the (new JSON-based) l10nupdate process.

Moving to "Deployment systems"; feel free to move back.
Comment 3 Greg Grossmeier 2014-09-02 21:25:37 UTC
Niklas: Can you give any pointers to Brad to help him get up to speed on this?
Comment 4 Brad Jorsch 2014-09-02 22:16:20 UTC
(In reply to Greg Grossmeier from comment #3)
> Niklas: Can you give any pointers to Brad to help him get up to speed on
> this?

More specifically, I tracked the problem down as far as "the .json files are wrong". When I asked around, you were the only person anyone could point to who knows anything about the json-generating code. Where do I find this code? If it's not going to be obvious, how generally does that code work? Is there a known way to run just the json-generator and output files to some temporary directory?
Comment 5 Nemo 2014-09-03 05:18:03 UTC
(In reply to Brad Jorsch from comment #4)
> point to
> who knows anything about the json-generating code.

https://git.wikimedia.org/blob/mediawiki%2Ftools%2Fscap.git/HEAD/bin%2FrefreshCdbJsonFiles (authors Bryan and Antoine, AFAICS).
Comment 6 Niklas Laxström 2014-09-03 05:38:39 UTC
To clarify, are we talking about the json created by LocalisationUpdate (which are then included in the CDB files by LocalisationCache), or the json files created from the CDB files by the deployment scripts for efficient syncing?
Comment 7 Brad Jorsch 2014-09-03 14:39:41 UTC
(In reply to Nemo from comment #5)
> https://git.wikimedia.org/blob/mediawiki%2Ftools%2Fscap.git/HEAD/
> bin%2FrefreshCdbJsonFiles (authors Bryan and Antoine, AFAICS).

Yeah, I asked them. They said they didn't know anything about the actual generation of the json stuff.

(In reply to Niklas Laxström from comment #6)
> To clarify, are we talking about the json created by LocalisationUpdate
> (which are then included in the CDB files by LocalisationCache), or the json
> files created from the CDB files by the deployment scripts for efficient
> syncing?

There's two different json files? I'm glad I asked for help: I didn't know that it generated json files for the updated messages, then built cdbs, then generated more json files from the cdbs, and then generated cdbs again from the json files.

I was referring to the json files that are created from the cdbs and then used to recreate the cdbs. Now that I know better how things work, I'm digging further into it.
Comment 8 Gerrit Notification Bot 2014-09-03 18:18:07 UTC
Change 158146 had a related patch set uploaded by Anomie:
LocalisationCache: Process one fallback at a time

https://gerrit.wikimedia.org/r/158146
Comment 9 Gerrit Notification Bot 2014-09-03 18:18:23 UTC
Change 158147 had a related patch set uploaded by Anomie:
Use new LocalisationCacheRecacheFallback hook

https://gerrit.wikimedia.org/r/158147
Comment 10 Brad Jorsch 2014-09-03 18:18:44 UTC
The problem is over-optimization: in LocalisationUpdate you're storing only the changed messages for each language, but that's causing problems when the current language doesn't have a change but a fallback language does. We've had this bug before, and it was worked around in r104041.

Rather than doing the same thing as r104041 again and having this recur again the next time someone tries to optimize things, let's really fix it: LocalisationUpdate needs a hook to call for each fallback before it's merged into the final array, rather than one hook after we've already lost the information as to which language each message came from. But to do that, we have to rearrange the processing in LocalisationCache so it accumulates the data for each fallback language
Comment 11 Gerrit Notification Bot 2014-09-04 14:52:41 UTC
Change 158147 merged by jenkins-bot:
Use new LocalisationCacheRecacheFallback hook

https://gerrit.wikimedia.org/r/158147
Comment 12 Gerrit Notification Bot 2014-09-04 17:15:46 UTC
Change 158146 merged by jenkins-bot:
LocalisationCache: Process one fallback at a time

https://gerrit.wikimedia.org/r/158146
Comment 13 James Forrester 2014-09-04 17:29:26 UTC
Now theoretically FIXED (once the code is deployed)?
Comment 14 Gerrit Notification Bot 2014-09-04 17:34:05 UTC
Change 158421 had a related patch set uploaded by Reedy:
LocalisationCache: Process one fallback at a time

https://gerrit.wikimedia.org/r/158421
Comment 15 Gerrit Notification Bot 2014-09-04 17:34:24 UTC
Change 158422 had a related patch set uploaded by Reedy:
Use new LocalisationCacheRecacheFallback hook

https://gerrit.wikimedia.org/r/158422
Comment 16 Gerrit Notification Bot 2014-09-04 17:35:01 UTC
Change 158423 had a related patch set uploaded by Reedy:
LocalisationCache: Process one fallback at a time

https://gerrit.wikimedia.org/r/158423
Comment 17 Gerrit Notification Bot 2014-09-04 17:39:30 UTC
Change 158422 merged by jenkins-bot:
Use new LocalisationCacheRecacheFallback hook

https://gerrit.wikimedia.org/r/158422
Comment 18 Gerrit Notification Bot 2014-09-04 17:53:19 UTC
Change 158421 merged by jenkins-bot:
LocalisationCache: Process one fallback at a time

https://gerrit.wikimedia.org/r/158421
Comment 19 Gerrit Notification Bot 2014-09-04 17:55:04 UTC
Change 158423 merged by jenkins-bot:
LocalisationCache: Process one fallback at a time

https://gerrit.wikimedia.org/r/158423
Comment 20 Brad Jorsch 2014-09-04 18:08:49 UTC
I think it's safe to mark this fixed now, although we still have to force-update all the l10n caches to make sure brokenness doesn't stay cached somewhere. Reedy says on IRC that he'll do that once he finishes the train deploy that's going on right now.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links