"Source L10n" Available For SeaMonkey Trunk
Robert Kaiser
[this post has also been blogged as
<http://home.kairo.at/blog/2007-11/source_l10n_available_for_seamonkey_trun>]
I'm proud to announce to SeaMonkey localizers that the suite is ready to
start into the world of so-called "source L10n", i.e. building localized
builds based of files that are all available in our public repositories.
With that, the development trunk of SeaMonkey, which is in a pre-Alpha
state for a future SeaMonkey 2, will be localizable using the Core L10n
files that are already in CVS. with additional SeaMonkey-specific files
added in the suite/ subdirectory and some in the editor/ui/ subdirectory
of the respective language directories in the l10n/ CVS repository.
If the SeaMonkey localizer for a language has already CVS access and he
is the locale owner or gets authorization from the owner, and if a
Firefox localization is already present (and therefore the "core", i.e.
dom/, netwerk/, security/ and toolkit/, as well as extensions/reporter
are already present for their localization), he can add the
SeaMonkey-specific files to the L10n CVS right away. Else, the locale
owner or a peer that already has CVS access can do the checkins, and the
SeaMonkey localizer should file a bug for CVS access and let the locale
owner vouch for him. In any case, the core as mentioned above should be
in the tree first. If no core localization is present yet, please follow
the Firefox rules for getting the core L10n files in first.
Once your localization gets complete (check that with compare-locales),
please file a bug for adding your locale to all-locales for SeaMonkey
(in "Mozilla Application Suite > Build Config") and assign it to
"kairo@" so I can add you there and repackaging of nightlies will be done.
We don't need any special reviews for bookmarks, start pages or search
engines at the moment as we have no special agreements with any
providers of such resources. You probably should keep the existing
default bookmarks unchanged though, possibly adding a small (!)
selection of localized ones - not without asking the link targets if
they are OK with that, though.
You also should only change any URLs we point to if you really know what
you are doing and have ensured that the target can handle the amount of
traffic generated by this change and you are allowed to use any brand
that might occur in SeaMonkey due to your changes. This is true for
bookmarks, stage pages and search engines as well as any other URLs in
SeaMonkey. Be careful with all of those!
For the technical side of search plugins, the only file you need to have
in that dir is the list.txt file, please do NOT copy the en-US plugins
themselves, if the list.txt points to a plugin not existing in your
locale but in en-US, the plugin from en-US will be packaged
automatically. If you add plugins for local search providers, you need
to add the base name of the files in list.txt and provide a .src and
.png file for the search plugin, using the "old" sherlock format as used
by mycroft.mozdev.org. Note that all icons need to be PNG, not GIF or
something else, as our localization process only picks up .png files.
As we are still in pre-Alpha with this SeaMonkey development cycle, we
have not yet figured out exactly how we will deal with releases, I hope
I can give a better picture of that when we are nearing Alpha. What we
know, as that we'll probably go into the final localization freeze for
or shortly after Beta, but we don't know yet when this will exactly be.
Once a locale has been added to all-locales, you'll notice the SeaMonkey
nightly build machines appearing on the respective Mozilla-l10n-*
tinderbox waterfall page and nightly builds generated when those columns
there are green. Those nightly builds will appear in the latest-trunk
FTP directory and should be usable to a big part.
Warning: We know of some features that are still broken in localized
builds at the moment, those are all marked as dependencies of the source
L10n bug: Download manager and password manager windows do not work, as
well as system integration hooks (on Windows) - we are working on
replacing the old implementations of those with newer ones and therefore
did not enable the old code to work with source L10n.
I hope we can improve quality and availability of SeaMonkey
localizations with this step, so that SeaMonkey 2 will be an even better
suite product than any other such all-in-one application before.
Greetings,
Robert Kaiser
Robert Kaiser
> I'm proud to announce to SeaMonkey localizers that the suite is ready to
> start into the world of so-called "source L10n", i.e. building localized
> builds based of files that are all available in our public repositories.
Note that this does not include ChatZilla yet, which we are still
working on to get proper localization.
Robert Kaiser
Toni Hermoso Pulido
thanks for having contributed to make SeaMonkey CVS localization
possible. This will make life a lot easier ;)
So, is IRC going to be moved from extensions/irc to another location?
2007/11/16, Robert Kaiser <ka...@kairo.at>:
> _______________________________________________
> dev-l10n mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n
>
--
Toni Hermoso Pulido
http://www.cau.cat
Robert Kaiser
> thanks for having contributed to make SeaMonkey CVS localization
> possible. This will make life a lot easier ;)
I hope so - it will make all our lives easier and also improve thing for
the SeaMonkey project as we can go live with SeaMonkey2-based releases
having binaries in all languages and platforms we support :)
> So, is IRC going to be moved from extensions/irc to another location?
No, we just don't have the proper way of localization process in place
for it, but we're very near to getting it.
So, if you already have committed it, leave it there and wait for an
announcement regarding it.
But if you haven't committed it yet, please leave it out until we have
that process in place and I make another announcement for it.
Robert Kaiser
Siarhei
I do the following things to checkout en-US files for Firefox, Thunderbird:
--------
export CVSROOT=":pserver:anon...@cvs-mirror.mozilla.org:/cvsroot"
cvs co mozilla/client.mk
cd mozilla
make -f client.mk l10n-checkout MOZ_CO_PROJECT=browser,mail MOZ_CO_LOCALES=be
--------
Could I checkout SeaMonkey files the same way?
Best regards,
Siarhei
Robert Kaiser
Yes, the MOZ_CO_PROJECT variable for SeaMonkey is "suite".
So, MOZ_CO_PROJECT=browser,mail,suite will check out all files needed
for Firefox, Thunderbird and SeaMonkey.
Do you know in what MDC pages we are listing those options? I think it
might be a good idea now to add SeaMonkey there.
Robert Kaiser
Mad Maks
>
> Do you know in what MDC pages we are listing those options? I think it
> might be a good idea now to add SeaMonkey there.
http://developer.mozilla.org/en/docs/Mozilla_Source_Code_%28CVS%29#Selecting_a_Project_to_Pull
Siarhei
Robert Kaiser напісаў(ла):
Siarhei
browser,mail checkouts 9,9MB
browser,mail,suite checkouts 89MB
It seems that we could checkout SeaMonkey-specific files with two commands:
cvs -z9 -d :pserver:anon...@cvs-mirror.mozilla.org:/cvsroot checkout -r mozilla/suite/debugQA/locales/en-US
cvs -z9 -d :pserver:anon...@cvs-mirror.mozilla.org:/cvsroot checkout -r mozilla/suite/locales/en-US
Robert Kaiser напісаў(ла):
Siarhei
> Unfortunately, it doesn't work well, it checkouts a lot of files not
> useful for localizer.
>
> browser,mail checkouts 9,9MB
> browser,mail,suite checkouts 89MB
>
> It seems that we could checkout SeaMonkey-specific files with two commands:
>
> cvs -z9 -d :pserver:anon...@cvs-mirror.mozilla.org:/cvsroot checkout
> -r mozilla/suite/debugQA/locales/en-US
> cvs -z9 -d :pserver:anon...@cvs-mirror.mozilla.org:/cvsroot checkout
> -r mozilla/suite/locales/en-US
without *-r*
Robert Kaiser
> Unfortunately, it doesn't work well, it checkouts a lot of files not
> useful for localizer.
>
> browser,mail checkouts 9,9MB
> browser,mail,suite checkouts 89MB
Then there is a bug we need to fix. I need to look into that, could you
please file that bug?
> It seems that we could checkout SeaMonkey-specific files with two commands:
>
> cvs -z9 -d :pserver:anon...@cvs-mirror.mozilla.org:/cvsroot checkout
> -r mozilla/suite/debugQA/locales/en-US
For get those. They are NOT localizable right now (or actually not
intended for localization and we never pick up their localization if it
exists). They are only used for a debug extension that is not shipped to
end users and if we ever add L10n for that we want to keep it optional.
> cvs -z9 -d :pserver:anon...@cvs-mirror.mozilla.org:/cvsroot checkout
> -r mozilla/suite/locales/en-US
If you already have localized everything pulled by browser,mail then
those should be all you need. Note that lots of strings in editor/ui are
actually SeaMonkey-specific as well, though, even if mail pulls them.
Robert Kaiser
Asrail
>> cvs -z9 -d :pserver:anon...@cvs-mirror.mozilla.org:/cvsroot checkout
>> -r mozilla/suite/locales/en-US
>
> If you already have localized everything pulled by browser,mail then
> those should be all you need. Note that lots of strings in editor/ui are
> actually SeaMonkey-specific as well, though, even if mail pulls them.
Is there a list of what are these files?
Axel Hecht
> Siarhei wrote:
>> Unfortunately, it doesn't work well, it checkouts a lot of files not
>> useful for localizer.
>>
>> browser,mail checkouts 9,9MB
>> browser,mail,suite checkouts 89MB
>
> Then there is a bug we need to fix. I need to look into that, could you
> please file that bug?
I just recently FIXED l10n-checkout to pull /cvsroot less optimistic.
There are a lot of things in both toolkit and the application dir (at
least in browser and mail) that are needed to actually build in the end.
I'm optimistic that we can cut down on the amount of data pulled at some
point in time (and then we get hg, and blow it), but this was the safest
bet.
The trick is that I pull all of toolkit, and all of the app dir, and all
of extensions.
Everything else turned out to be brittle at configure time.
Once we have tinderboxens using l10n-checkout on the main trees and have
something that turns red on an l10n-checkout bustage, we can more
reliably cut down the size of check outs again.
Axel
Robert Kaiser
> The trick is that I pull all of toolkit, and all of the app dir, and all
> of extensions.
Ugh, that's HUGE then.
Robert Kaiser
Robert Kaiser
Is that where localizers are pointed to to get the project to check out?
Robert Kaiser
Axel Hecht
Most documentation on MDC is targeting newbies, I'm not very keen on
adding a bunch of projects to each of those page everywhere where I'm
using 'browser' right now.
I guess that projects want to have their own entry-level documentation
for localization, pointing out what other l10n documentation can be
used, and how.
Axel
Cédric Corazza
>> If you already have localized everything pulled by browser,mail then
>> those should be all you need. Note that lots of strings in editor/ui
>> are actually SeaMonkey-specific as well, though, even if mail pulls
>> them.
> Is there a list of what are these files?
I think you are looking for this files :
https://bugzilla.mozilla.org/show_bug.cgi?id=379007
Cédric
Asrail
Thanks a lot.
Siarhei
Disk usage is 74M.
It takes about 50 minutes for me to get the source.
Siarhei
Axel Hecht напісаў(ла):
Axel Hecht
is that check-out or update? I'm not so worried about the disk size, and
I'd neglect the initial checkout time, too, I guess. What I would care
about is update time.
Disk size shouldn't really matter, and if the initial check out is the
only problem, we can create a zip to pull an initial tree.
Axel
Siarhei
Axel Hecht напісаў(ла):
> is that check-out or update? I'm not so worried about the disk size, and
> I'd neglect the initial checkout time, too, I guess. What I would care
> about is update time.
It is check-out.
>
> Disk size shouldn't really matter, and if the initial check out is the
> only problem, we can create a zip to pull an initial tree.
>
It is good idea.
Siarhei
Axel Hecht
So how long does a cvs update take for you? Just as a datapoint for my
thinking? And what kind of connection would that be?
Axel
Siarhei
The problem is that cvs checkout takes about 50 minutes.
Sometime I need to do checkout to get new directories introduced into en-US.
I use dial-up connection.
Siarhei
Axel Hecht напісаў(ла):
Rimas Kudelis
I got used to checking out only en-US dirs manually (I have a
shellscript which I call to update them though), and here's the result:
rq@sugar:/usr/src/mozilla/trunk $ du -hs *
0 en
5,5M lt
8,0M mozilla
Here, `en/` contains a few directories and a bunch of symlinks to
`mozilla/` (I use `en/` to compare-locales), and `lt/` is a translated
tree. Oh, and `mozilla/` is bigger than `lt/` just because it includes
suite.
How's that?
RQ
Siarhei rašė:
Siarhei
How could you be sure that your list is actual one?
The official way to get files to localize is l10n-checkout.
Rimas Kudelis напісаў(ла):
Siarhei
make -f client.mk l10n-checkout MOZ_CO_PROJECT=browser,mail,suite
So there is not need to get all the source every time new directory introduced.
Siarhei напісаў(ла):
Rimas Kudelis
> Hi,
>
> How could you be sure that your list is actual one?
I rely on Tinderboxes. I assume as long as they are green, the
translation IS the actual one and complete.
> The official way to get files to localize is l10n-checkout.
Yeah, but my way is faster and easier, IMO. ;)
RQ
Axel Hecht
I'd suggest to use different build dirs for doing the language packs for
testing for the different apps, though.
Something like
./mozilla/browser/locales/en-US
./l10n/ab-CD/browser
./build/browser
./build/suite
./build/mail
where you would mkdir the build dirs, and then configure in each of
those, like
../../mozilla/configure --disable-compile-environment
--enable-application=browser
in build/browser.
Makes sense?
Axel