client.mk and optional L10n directories
Robert Kaiser
<https://bugzilla.mozilla.org/show_bug.cgi?id=397246>), so that L10n of
it can be optional, even if ChatZilla is built into SeaMonkey.
The only left problem currently is client.mk pulling the L10n files.
We have two options:
- either always pull the dir from l10n/, which means the dir itself
needs to exist for every locale that has a SeaMonkey L10n or client.mk
fails (just like we have it already with dictionaries),
- or always pulling all of l10n/ab-CD/ for all our products, which would
solve thise problem for all optional things we could have (we'd still
leave the LOCALES_* variables in there for now, as the new
compare-locales scripts need those to determine what to check).
Axel Hecht asked for Benjamin Smedberg to decide that, but he in turn
forwarded this decision to build people, as he says the only reason he
might not want to pull all of l10n/ab-CD is that it makes it more
difficult to figure out what changes might affect Firefox - so on
branches (for instance) we might have to be a lot more careful about
managing l10n checkins.
He said on IRC "I think this should be brought up on mozilla.dev.builds
and get rhelmer to concur on whatever decision... I don't care myself"
So, here I am asking for a decision on this last link. What way should
we go for this?
If locales ever move to hg, I'd expect us to pull all of l10n/ab-CD at
once there anyways, but current L10n repackaging machines, esp. with
Windows VMs having sucky I/O perf, would also probably take longer for a
checkout.
I'm a bit divided between those solutions myself, both have their pros
and cons, but I'd like to move forward on this soon, one way or the other.
Robert Kaiser
Robert Kaiser
> The only left problem currently is client.mk pulling the L10n files.
Filed as https://bugzilla.mozilla.org/show_bug.cgi?id=405856
Robert Kaiser
Rob Helmer
> We're adding extensions/irc to l10n/ using dependent langpacks (see
> <https://bugzilla.mozilla.org/show_bug.cgi?id=397246>), so that L10n of
> it can be optional, even if ChatZilla is built into SeaMonkey.
> The only left problem currently is client.mk pulling the L10n files.
> We have two options:
> - either always pull the dir from l10n/, which means the dir itself
> needs to exist for every locale that has a SeaMonkey L10n or client.mk
> fails (just like we have it already with dictionaries),
> - or always pulling all of l10n/ab-CD/ for all our products, which would
> solve thise problem for all optional things we could have (we'd still
> leave the LOCALES_* variables in there for now, as the new
> compare-locales scripts need those to determine what to check).
>
> Axel Hecht asked for Benjamin Smedberg to decide that, but he in turn
> forwarded this decision to build people, as he says the only reason he
> might not want to pull all of l10n/ab-CD is that it makes it more
> difficult to figure out what changes might affect Firefox - so on
> branches (for instance) we might have to be a lot more careful about
> managing l10n checkins.
> He said on IRC "I think this should be brought up on mozilla.dev.builds
> and get rhelmer to concur on whatever decision... I don't care myself"
I looked into it, and we currently pull and tag all files in each
locale CVS directory that we intend to ship:
http://mxr.mozilla.org/mozilla/source/tools/release/Bootstrap/Step/Tag/l10n.pm#57
So for releases I think this would be fine, it would just take longer
to do the l10n checkout than it currently does.