Created attachment 315099 [details] cvs modules Action item for bug 426395, we want two cvs modules for the l10n repository. I changed my mind on the names of those, ...Shipped is to focused, ...Frozen is what it's about. I'm not sure anymore if that's supposed to be automated, we'd be overloading shipped-locales once more, that might be harmful. Maye later. Here's what I think the modules file should look like, as attachment. I'll attach a python script, too, that, if run with a mozilla tree in the working dir, prints that to stdout. I think I got it right, though I'm not sure if I guesses right on whether it's l10n/l10n/ab-CD or just l10n/.
Can you put each directory path on its own line? The current list is not very readable... Example: Firefox3All -a \ l10n/af/netwerk \ l10n/af/dom \ ... Actually, one cool thing you could do is to split each locale into its own module and then create modules for Firefox2, Firefox3, etc. that pull in the appropriate locales to match all-locales and shipped-locales for the different Firefox releases. That would give you a ton of flexibility to do different things with this information. Example: l10n-af -a \ l10n/af/netwerk \ l10n/af/dom \ ... Firefox3All -a \ l10n-af \ l10n-ar \ ... What do you think?
We discussed this partly on the call, and one argument was that you wouldn't need per-locale modules as you can just use the module and filter by directory, and get the data per locale in the module. Regarding the formatting, that would be easy.
Reed's suggestion might be good even if you're using the directory paths instead of the module names. Remember that a module pulls the stuff listed in it no matter what revision or branch tag you pull within that module. That means if we're constantly changing around what the definition of a given module is, pulling old versions by tag within that module will not be accurate.
need answers to the questions here still.
Created attachment 316074 [details] new modules file, based on previous comments I'm currently working on a set of locales for trunk, but that has been taking more of today than I expected, unblocking myself on that. I took reed's comments, and we happily dismiss all the problems with pulling modules from old timestamps. This is really to aid bonsai queries during a release cycle, and we bite the bullet that it doesn't cover archeology.
Attachment #315099 - Attachment is obsolete: true
Created attachment 316076 [details] python script, now with pretty printing
Attachment #315100 - Attachment is obsolete: true
Created attachment 316235 [details] bash script to automate the process OK, attached is the script I ended up using to automate the updating of this module list. This gets run from cron.daily every morning. Only commits if it actually makes changes. This is already live, if you see anything that looks funny in here, let me know ASAP. :)
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Is the bin/dumpl10nmodules my attached python script or something different? Just wondering how updates to the locales sets happen.
yes, it's your attached python script. Also, just noticed the stuff in the bug all says Firefox3Shipped but the module name in the file it generates is Firefox3Frozen Not sure if it matters. The module in bonsai is Firefox3Shipped, and it's configured to look for Firefox3Frozen in CVS. Not sure if that's too confusing. I can fix either one to match if you want.
Yeah, ...Shipped is what we did initially, but I changed my mind in comment 0. We didn't really ship anything yet, right? We're still frozen. And this is going to be similar for new localizations onwards. Note that I see Firefox3Frozen on bonsai-l10n.mozilla.org, too, which is good, IMHO.
For the record (since I neglected to say so in comment 8) this is running on recluse in /data/bin
You need to log in before you can comment on or make changes to this bug.