Quick builds for localisers (full or partial)
Dwayne Bailey
a number of times here is the script that I use to quickly create
localised XPI and Windows builds.
http://translate.sourceforge.net/wiki/toolkit/moz-l10n-builder
This works for PO and well as non-PO users. Its pretty fast if you only
have one language (the migration can take time). If you are not using
PO format then just look at the last steps.
If you are using PO then the whole script applies to you and you can
safely build partial translations for testing purposes.
The script essentially does this:
* Updates the Mozilla sources
* Build 10n/en-US and creates POT files
* Migrates your existing translations to the latest POT files
* Does various hacks to clean things up and copy files
* Converts PO to .properties and .dtd
* Builds and XPI and repacks a Windows .exe
TADA simple
I'd love others to help make this generic and not so Translate.org.za
specific. To do the Windows .exe building you need nsis and you can run
that on Linux using wine.
You of course need the translate toolkit together with some of its bash
scripts which are not currently packaged with the toolkit. You will
need upx and I think 7zip
Future
------
Most of this should happen in official Mozilla Makefiles. I also find
that I need to do some building before I can run these repackagers. It
would be nice if someone with Makefile know-how could help fix
tools/l10n/l10n.mk so that it can build all the dependencies such as
nsinstall and friends.
--
Dwayne Bailey
Translate.org.za
+27-12-460-1095 (w)
+27-83-443-7114 (cell)
Axel Hecht
I haven't checked
http://developer.mozilla.org/en/docs/Creating_a_Language_Pack on a
pristine l10n-checkout for a while, but that's how things should go.
Replace ab-CD with your locale code, of course.
You may have to build nsinstall, too.
That is subject to change, of course, moving that over to one python
script. And NSIS etc if you want to build an installer and not just a
language pack.
Axel
Erdal Ronahi
> I haven't checked
> http://developer.mozilla.org/en/docs/Creating_a_Language_Pack on a
> pristine l10n-checkout for a while, but that's how things should go.
> Replace ab-CD with your locale code, of course.
This may be correct, but the problem lies in sentece 1: "To create a
language pack, you first need most of Build, at least you need to run
configure to generate Makefiles for the localization directories."
To understand and apply that, you have to know much much more than the
average localizer does. Noone from our team knew how to do all the
complicated stuff that is necessary to make a complete build. The two
lines from that Wikipage are just the very last step of an extremely
complicated process.
But we are translators, not programmers.
Erdal
Dwayne Bailey
Is there any way that we can get the dependencies built also? This
confused me for a while.
./configure
make langpack-ab-CD
> That is subject to change, of course, moving that over to one python
> script. And NSIS etc if you want to build an installer and not just a
> language pack.
Would that include multilingual building? I'm now interested in adding
that to our build process and if you have a script lying around then I'd
love ot see it :)
Axel Hecht
I guess you would have to do a
make -C config export
or something, but I really would like to go without. And chances are
that it's easier to just redo that on the trunk and be done with it.
>> That is subject to change, of course, moving that over to one python
>> script. And NSIS etc if you want to build an installer and not just a
>> language pack.
>
> Would that include multilingual building? I'm now interested in adding
> that to our build process and if you have a script lying around then I'd
> love ot see it :)
>
multilingual building is actually a piece of cake, it's merely that
there seems to be a bunch of issues around that.
Talking to caillon who maintains the redhat port, matchOS is not really
performant. To some extent, that's component registration at startup,
which isn't that much of a problem for a regional build, I guess, that's
'just' 10 more packages, compare that to your extension list. But still,
it's a performance impact.
There is another question about what navigator.language should be. Which
of course is DOM0 and undefined :-(.
My current resume is, we can do multilingual builds pretty easily, but I
don't think we have a full line of issues to make those 'good mozilla'
builds.
Axel
Dwayne Bailey
Is matchOS is this used for installation - ie choosing the correct
install lang, based on locale settings or for ensuring the app matches
the locale setting, which may change.
Most people in our environment has an en-US setup, so for us we're
probably less concerned about the locale as it usually has not been set
by the user anyway. I can imagine in many developing nations it will be
the same.
> There is another question about what navigator.language should be. Which
> of course is DOM0 and undefined :-(.
Yes not sure what to that should do. Although based on my stats in
South Africa, no-one here has that set to anything other then en-US :(
It does look like it would entail some complicated hackery to use the UI
language unless the user has changed it...
> My current resume is, we can do multilingual builds pretty easily, but I
> don't think we have a full line of issues to make those 'good mozilla'
> builds.
I'd really like to enable this for our test builds as it makes it easier
to get them to people. Is there a way to magically build with new
extensions, as I assume that is what we are adding with extra languages?
I'd really love to be able to inject multiple langpacks into the
repackage-win32 target in Makefile.
Axel Hecht
Did we have a bug on that? I can't find that ad-hoc. If so, I'd attach
my ad-hoc patch I still have lingering around.
Axel