source L10n for ChatZilla
Robert Kaiser
I checked in today the support for CVS-based localization of ChatZilla,
see <https://bugzilla.mozilla.org/show_bug.cgi?id=394315>
This means that you can add localizations for ChatZilla in
l10n/<locale>/extensions/irc/ and those can be used in two ways for
getting a localized ChatZilla:
1) Once SeaMonkey supports source L10n (tracked in
<https://bugzilla.mozilla.org/show_bug.cgi?id=286110>), we will be able
to build your localized ChatZilla into it instead of the default
US-English one.
2) With the scripts available in the ChatZilla source, you can even
build a localized ChatZilla XPI package directly this those commands
(replace "de" with your local code):
---------------------
cvs -d :pserver:anon...@cvs-mirror.mozilla.org:/cvsroot co
mozilla/config mozilla/extensions/irc
cvs -d :pserver:anon...@cvs-mirror.mozilla.org:/l10n co
l10n/de/extensions/irc
cd mozilla/extensions/irc/xpi/
export AB_CD=de
sh makexpi.sh
---------------------
If you built an English version before from the same directories (or the
fallback to English was in place), either remove jar-tree and xpi-tree
directories by hand before running makexpi.sh or run a "sh makexpi.sh
clean" before it - else you will get any locale built before also in
your new XPI package.
For both variants, the locales/all-locales file in the ChatZilla source
plays an important role: If your locale code is present there at its own
line, your locale will be built. If it is not present there, the build
will fall back to using en-US.
This way, we can make localizations possible without requiring them.
There are still some open questions surrounding that topic, regarding
locale repackaging for SeaMonkey builds, automatic updates of localized
SeaMonkey builds (which both aren't used/working yet anyways, but are
planned for the future), and also about what packages might be uploaded
to AMO in the future (possibilities there are one multi-language version
or extension locale packs), but all those open questions should not
affect the files that you can now add to the L10n CVS repository.
I'm looking into providing the same infrastructure for venkman (see
<https://bugzilla.mozilla.org/show_bug.cgi?id=394633>), but I think not
many languages have localized that in the past anyways.
For DOM inspector, we still have
<https://bugzilla.mozilla.org/show_bug.cgi?id=355793> open, but we
probably need to look into resolving the open questions I mentioned
above first before getting something actually moving there.
For now, I hope we can move ChatZilla localizations from being only
available on private hard drives to having a place on our public
repository, which is a good step in any case :)
Robert Kaiser
Ricardo Palomares Martinez
> Hi localizers,
>
> I checked in today the support for CVS-based localization of ChatZilla,
> see <https://bugzilla.mozilla.org/show_bug.cgi?id=394315>
>
> This means that you can add localizations for ChatZilla in
>
> There are still some open questions surrounding that topic, regarding
> locale repackaging for SeaMonkey builds, automatic updates of localized
> SeaMonkey builds (which both aren't used/working yet anyways, but are
> planned for the future), and also about what packages might be uploaded
> to AMO in the future (possibilities there are one multi-language version
> or extension locale packs), but all those open questions should not
> affect the files that you can now add to the L10n CVS repository.
Robert, I looked at the bug (which has been reopened) and I'm not sure
if there is really green light to put ChatZilla locales into CVS.
Also, it would be nice to have a clearer picture of how the different
versions will be handled (for instance, SeaMonkey usually ships an
older version than the latest available in ChatZilla's page; will
trunk contain bleeding edge CZ while branches for SM get a stable
version?).
>
> I'm looking into providing the same infrastructure for venkman (see
> <https://bugzilla.mozilla.org/show_bug.cgi?id=394633>), but I think not
> many languages have localized that in the past anyways.
es-ES has it localized, FWIW.
TIA
--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?
Axel Hecht
I tend to think that chatzilla should have one-off localizations, pretty
much like DOMI has today. Given that it's just some 60 strings, I'd vote
for hooking those up after string freeze, and ignore l10n of chatzilla
up to then.
I don't think that for this particular use case, a localization in the
l10n rep is going to give us much.
I'm tempted to suggest the same scheme for DOMI, too.
I chatted with Robert about this a bit and there are more questions to
ask and answer wrt l10n of mozilla/extensions, but if we're talking
about a few dirs with a few dozen (stable) strings, I don't really buy
all the hassle about CVS. Like, for cz, we have a cvs account request
just for that.
Robert, do you have the full list of stuff somewhere? I guess my brain
dropped 50% of it again by now, and I might come up with a different 50%
if you'd ask me again.
Axel
Robert Kaiser
> I tend to think that chatzilla should have one-off localizations, pretty
> much like DOMI has today. Given that it's just some 60 strings, I'd vote
> for hooking those up after string freeze, and ignore l10n of chatzilla
> up to then.
Umm, what does have 60 strings? DOMI might, but ChatZilla is really huge
in terms of string numbers, even if the number of files is small - but
just look into chatzilla.properties and wonder ;-)
> I don't think that for this particular use case, a localization in the
> l10n rep is going to give us much.
I think having stuff in the L10n rep is good for anything. it's all in
all a cleaner solution to have a general scheme for L10n on anything,
and it's better if someone from the L10n team can check in changes and
those people don't have to run it by someone with main CVS access - even
if changes might be small and rare.
Also, in terms of SeaMonkey, I want to enable people to get a fully
localized SeaMonkey shipped when SeaMonkey 2 arrives based on Gecko 1.9,
esp. as the current self-built contributed SeaMonkey 1.1.x builds are
able to have that and I'd really like to not regress L10n user
experience with the move to toolkit.
And I surely want to still enable users who barely know English to use
our integrated IRC client.
> Robert, do you have the full list of stuff somewhere? I guess my brain
> dropped 50% of it again by now, and I might come up with a different 50%
> if you'd ask me again.
I have a log of our chat and I'll do a post here about it as soon as I
have ordered everything in there, but I had some private engagements the
last two nights and little time for this in between. I'll try to do that
this weekend.
Robert Kaiser
Ricardo Palomares Martinez
> Axel Hecht wrote:
>> I tend to think that chatzilla should have one-off localizations,
>> pretty much like DOMI has today. Given that it's just some 60 strings,
>> I'd vote for hooking those up after string freeze, and ignore l10n of
>> chatzilla up to then.
>
> Umm, what does have 60 strings? DOMI might, but ChatZilla is really huge
> in terms of string numbers, even if the number of files is small - but
> just look into chatzilla.properties and wonder ;-)
Just for the record, MozillaTranslator says that ChatZilla 0.9.75.1,
the version shipped with SM 1.1.x, has 1358 strings, whereas Firefox
trunk (without counting toolkit) is around 2200 strings. Not bad for
"just an extension".
>
>> I don't think that for this particular use case, a localization in the
>> l10n rep is going to give us much.
>
> I think having stuff in the L10n rep is good for anything.
I agree with Robert in this. Moving to a VCS-based (no misspelling)
localization was a really painful change, and now that we have it
somehow sorted out, we should take advantage of every opportunity to
use it. While theoretically it could involve some overload in CVS
account requests, in practice I think most of us already have CVS
access, or will have to ask for it for SeaMonkey 2 anyway.
Ricardo.