I just added Fennec localization stati to the l10n dashboard. It’s only pretending to do arm linux tgz’s right now, and it’s not uploading them anywhere. I expect that will happen soon on the main build machines.
There were a few funky edges to make fennec build similar to what we have in Firefox now. Most notably, Fennec uses a completely different directory structure, which looks really familiar once on disk. The main difference is that when Fennec developers check in to a file in mobile/locales/en-US/chrome, that file is actually in locales/en-US/chrome in the repository. When a localizer catches up with that change, they’re really landing to ab-CD/mobile/chrome. That requires some special hooks in the code that watches for l10n changes on the build master. The biggest hurdle was surprisingly the all-locales file in the end. That just blew the logic I had. I’m now loading the all-locales file by assuming that it’s right next to l10n.ini, while I’m still using the path to all-locales in l10n.ini to control what the AllLocalesWatcher pays attention to, to update the list of all-locales in the master when that’s changing in the repo.
What I really like is that we’re adding this product to our localization story in good shape. In my little universe, the big winner is that we’re starting with l10n-merge working. Thanks to mfinkle’s timely reviews, I added logic to the build to export both the gecko and the fennec revisions of the en-US build that’s repackaged, so one can run compare-locales (with or without l10n-merge) against the sources that actually went into the build. This is really important to get the missing strings right, and to ensure that the build is working as good as it can.
So, localizers, now is the time to land. Please make sure to touch base with Stas on any questions regarding web services. Using what we have for Firefox is a good base, though. Gandalf can help with general technical issues, as can I. If you’re not part of the fun, and want to join, please file a bug.
We’re well aware that you’ll need a descent infrastructure to test with. What is most important to you guys? Leave a comment on this post?
Nice post. One quick question you might enjoy explaining:
How did the all-locales file actually end up blowing up your logic?
Another general set of questions:
* What does AllLocalesWatcher pay attention to?
* I assume it’s the same for Firefox?
* And, does AllLocalesWatcher update the all-locales in the master or is that something else?
Would love to learn more about this, just out of my own curiosity…
This looks like it might have actually been a challenging but fun exercise because a lot of things are starting from the correct point given all you have learned with building and shipping Firefox over the years.
Comment by seth bindernagel — February 27, 2009 @ 11:40 am
So, there are two occurences of all-locales in the build logic. One is to load the list of all-locales, i.e., we need (for hg) a url to the hg repo. In this case http://hg.mozilla.org/mobile-browser/file/tip/locales/all-locales. The raw-file version of this, but that doesn’t display nicely when you click on the link. The main point here is that you’re seeing the tail to be locales/all-locales.
The second occurence is the AllLocalesWatcher. It’s getting all changes to the repos, and if it’s seeing the mobile-browser repo, it looks if locales/all-locales was changed. If so, it triggers reload of the above url.
The combination of the two keeps an up-to-date list of which locales build this app inside the scheduler, and that list is used to ignore changes to locales that shouldn’t be built, and to kick of the right set of locales for nightlies and en-US-triggered builds.
Now to the fun part. How do we get the URL? For all other projects I had worked on before, the l10n.ini file was in the directory $(app)/locales/ in the outer-most repo. Either mozilla-central for firefox, or comm-central for thunderbird et al. comm-central does include other repos, but they’re all checked out as child directories of comm-central. So when referencing paths from l10n.ini, I could say “go two directories up, and then browser, toolkit, etc” or “go two directories up and then use browser/locales/all-locales”.
There was already a light tweak required for CVS, which comes with a leading ‘mozilla/’, but that resolved happily with how I get files from CVS anyway.
Now, for mobile, to reference toolkit, I still need to say “go up two, then toolkit, mobile, etc”. But if I say “go up two, then locales/all-locales”, I end up outside of the mobile-browser repo.
Thus, using the same depth for references to modules in a checked out version on disk as well as remote repository location died.
Is that any clear? I can’t read as much as I typed on this small comment field.
Comment by Axel Hecht — February 27, 2009 @ 3:13 pm
Yeah, that’s all clear. I can see how the structure changed based on your description above. Thanks.
Comment by sethb — February 27, 2009 @ 4:16 pm