Confirmed users, Bureaucrats and Sysops emeriti
2,976
edits
User:AxelHecht/Building l10n: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 47: | Line 47: | ||
=== l10n status === | === l10n status === | ||
Right now, we have 121 l10n tinderbox pages listed on | Right now, we have 121 l10n tinderbox pages listed on [http://tinderbox.mozilla.org/showbuilds.cgi showbuilds], each of which show three platforms, and something between 1 and 4 products. Just for trunk, it's 63, and I'm not counting the 1.8.0 boxens at all, those don't seem to have any builds these days. | ||
Going into Firefox 3, we lacked any understanding of how those trees were looking, and we're still facing the same problem for Thunderbird 3. The lack of information here probably hid problems that are now delaying some of our localizations. | Going into Firefox 3, we lacked any understanding of how those trees were looking, and we're still facing the same problem for Thunderbird 3. The lack of information here probably hid problems that are now delaying some of our localizations. | ||
| Line 68: | Line 68: | ||
The next step in this direction is to actually do something reasonable for common failures, i.e., missing strings. This piece is nick-named l10n-merge ({{bug|399014}}). l10n-merge enables us to create builds of incomplete localizations, fixing grammar errors is beyond its scope, though. | The next step in this direction is to actually do something reasonable for common failures, i.e., missing strings. This piece is nick-named l10n-merge ({{bug|399014}}). l10n-merge enables us to create builds of incomplete localizations, fixing grammar errors is beyond its scope, though. | ||
There are different ways to hook up l10n-merge, too. I'm personally scared of in-place editing the cvs checkout, and I think it's going to be perf-bad on check-out, too. The other solution would be to hook it up into make-jars, which is possible, but involved. Most speedy, for sure. The third is to l10n-merge into a temp l10n dir, which would require an adjustment in the build system to not hardcode ../l10n as l10n root dir. | |||
== Buildbot == | |||
Switching over to buildbot. So the basic idea goes like this | |||
* whenever you have to: | |||
** get the en-US source | |||
** get the l10n source | |||
** for each affected locale and product: | |||
*** compare-locales | |||
**** possibly l10n-merge | |||
*** if those are cool: | |||
**** build | |||
**** (runtime test) | |||
There are a few fuzzy terms here, I'll go into detail in some not-so random order. | |||
''build'' means repackaging an existing binary, and we should run our source checks against the source of that build. Finding out which one that is would be {{bug|398954}}. | |||
''whenever you have to'' is another interesting question, I don't have a full answer to that. The goal would be "when there's a good reason to build this app for this locale". For the l10n side of things, this is involved, but with a clear answer. When a localizer checks in, build all products that that check-in affected. More on that below. | |||
For en-US, things are more confuzzled in my head. Let's take a check-in to /cvsroot. That may or may not affect localization, if it does, it would impact all locales for all apps that include that localizable string. Butt. At the time of that check-in, there's no build with that change yet. I think there's some value in running compare-locales at the point, but it's not uber-big. I guess for en-US, we really need to figure out which builds we want to repackage, and what their source is. Right now, firefox nightlies would be good again, for an actively evolving line of development, being more agile is key. Like, if localizers only have 24 hours to fix a late-l10n issue, we shouldn't wait for the next nightly to tell them. Not sure how much horse power a full repack run on each nightly would take, and for how many products we want to cough that up. Right now, linux cycles around 1.5 hours on l10n, dep en-US builds are around 4 per hour. Just doing a full compare-locales run is a lot quicker, though. Maybe compare-locales tip against tip, and l10n-merge against the time-stamped source. | |||