Chris Hoffman had been working on an en-IN (india) localization from the en-GB and there are some bugs you can read about.
Our 0.1 milestone might be to create the X-dude langpack; I have to find out what the l10n tools and/or scripts can do for me. I also have to learn python.
Chris Hoffman's en-IN langpack and the X-dude langpack:
The bug talking about en-IN:
and another one about en-CA, that mentions the necessity of automated l10n build tool:
Some of the things I want to highlight from Axel's email:
I envision this code to be python code. We have some existing python code that can extract the localization strings from a working copy,
we're using that to compare localizations, and other tests.
You can find the supporting code on
/source/testing/tests/l10n, together with other tools. The scripts are in 'scripts', the modules in lib.
I think that just overwrites are likely not good enough, at least not on
a file level. One way to start would be to just specify the changed entities and use dynamis' l10n-merge work to fill in the rest, if that
could pick strings from other localizations than just en-US. More
flexibility would be a plus, though.
Try to automate localizations like en-IN or en-CA from en-GB
once you installed the modules via setup.py, you should be able to just run it, say
$> python l10n-diff mozilla/browser/locales/en-US l10n/en-GB/browser
It will spit something out that looks like a unified diff, but really isn't.
I'd say that the first good step would be to actually try to reproduce en-IN from en-GB
the next would be to create en-GB from en-US, up to points like accesskey upper-lower-case.
For en-CA and fr-CA, I guess that the language differences are none, so
you'd really only have to do the post-processing that Chris Hofmann did
for en-IN. intl.properties seems to be a candidate, region.properties,
too, the two defines.inc and bookmarks.html (the links need to have the
locale name twice).