Last modified: 2014-09-02 11:21:27 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 T45614, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 43614 - l10n generation in git-deploy
l10n generation in git-deploy
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
Deployment systems (Other open bugs)
unspecified
All All
: High enhancement (vote)
: ---
Assigned To: Brad Jorsch
:
Depends on:
Blocks: 43338
  Show dependency treegraph
 
Reported: 2013-01-03 19:05 UTC by Rob Lanphier
Modified: 2014-09-02 11:21 UTC (History)
4 users (show)

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


Attachments

Description Rob Lanphier 2013-01-03 19:05:28 UTC
Incorporate the generation and distribution of l10n caches in git-deploy.
Comment 1 Chris Steipp 2013-01-12 01:20:15 UTC
Currently, this is slow, but working in the new system. `git-deploy sync` in the core repos will cause the cache to rebuild if needed, and all of the salt minions will fetch the appropriate l10n repo. Currently, only English is rebuilt during deployment, and a cron is used to rebuild the other languages daily

A full rebuild takes about 10 mins in eqiad.

In the near future, we will probably try to use something else to only move the parts of the cdb files that have changed.
Comment 2 Brad Jorsch 2013-01-12 14:12:33 UTC
Technically, all the languages are rebuilt if necessary on deploy. It's just that almost all of the non-English messages will be coming from the LocalisationUpdate extension's cache (which is not being updated on deploy) instead of the deployed code's messages, so they'll still have the old messages.

Gerrit change #42777 should speed up the cron script that rebuilds the LocalisationUpdate cache in many cases, by making it skip extensions that have not changed and by preventing it from invalidating the cache for languages whose messages have not changed. Right now it processes every extension message file, even if the message file has not changed since the previous run, and invalidates every language in the message file, even if none of those translations have actually changed.
Comment 3 Rob Lanphier 2013-02-05 18:14:57 UTC
Brad tells me this work is done.  There still may be some loose ends on cron generation of the l10n caches, but the core task described here is done.

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


Navigation
Links