Summary of MLP-Staff meeting 2005-03-15
Mark Tyndall
Items:
- trunk L10n (FF/TB) status
- MLP page restructuring status
- new locale name rules
** trunk L10n (FF/TB) status **
* Firefox L10n *
gandalf announced that the l10n directories for trunk builds of Firefox
are now ready, with the exception of Help and DOM Inspector.
L10n teams with Firefox localisations in CVS are invited to begin
copying their files over from the AVIARY branch to the new directory
structure on the trunk, and update them with the changes since 1.0.
'cvs add' is your friend here.
You will have the following directories, which more closely mirror the
canonical en-US directories:
./browser/locales
./toolkit/locales
./netwerk/locales
./dom/locales
Notes:
If different teams are localising Fx and Tb for the same locale, please
start communicating with each other *now* - /toolkit is shared between
Fx and Tb.
If a team wants to move to a shortened locale name (see below) (eg -
de-DE and de-AT --> de), then please decide this *before* adding l10n
files to trunk CVS.
* Thunderbird L10n *
gandalf will be tackling TB forthwith. He also leaps tall buildings in
a single bound and saves small kittens from trees :-)
** MLP page restructuring status **
The restructuring is progressing; a structure has been agreed. We're
still wondering whether the l10n pages should include download lists (of
localised builds of Fx, TB, Suite, etc) or simply point end-users to the
appropriate /product/<foo>/<all-locales> list.
** new locale name rules **
see <http://wiki.mozilla.org/wiki/L10n:Simple_locale_names>
The build system will now accept (for trunk Firefox only at the moment)
locale names of the following types:
ab-CD / abc-CD -- language *ab*/*abc*, country *CD*
- this is the current naming scheme
In future, we only want to use this if the region affects the
localisation (eg es-ES/es-AR)
ab -- language *ab*.
For languages which don't need to differentiate between regions (either
spoken only in one country, or generic across the countries it is spoken
in (eg fr, de, eo).
abc-CD-sil -- language *abc*, country *CD* and SIL identifier
This last code type is intended for dialects for which there is no ISO
639.2 language code. Note that SIL identifier can be up to eight
characters long (eg de-DE-bavaria, en-GB-scouse).
L10n teams wishing to shorten their language code should decide on this
*before* adding their Firefox files to the trunk :)
Next meeting is Wednesday 13th April, 18:00 UTC (remember it'll be
summer time)
Mark, MLP-Staff member
--
Mark Tyndall - British English Language Packs for
Mozilla Suite - <http://www.tyndall.org.uk/moz_en-gb.html>
Firefox - <http://www.tyndall.org.uk/fb_en-gb.html>
Thunderbird - <http://www.tyndall.org.uk/tb_en-gb.html>
Zbigniew Braniecki
example.
Greetings
Zbigniew Braniecki
--
MLP (http://www.mozilla.org)
Zbigniew Braniecki
> I only want to add that pl-PL should work ok, so one can use it as an
> example.
Also, you may want to look at the diff between 1.0 and trunk from
20050314. (http://bugs.aviary.pl/attachment.cgi?id=348).
Anne van Kesteren
> abc-CD-sil -- language *abc*, country *CD* and SIL identifier
>
> This last code type is intended for dialects for which there is no ISO
> 639.2 language code. Note that SIL identifier can be up to eight
> characters long (eg de-DE-bavaria, en-GB-scouse).
I believe SIL codes are three letter codes per definition. Which makes
sense, because that allows them to express 26^3 languages, which is more
than enough.
You are talking about the optional third parameter per RFC 3066 which
may take up from 3 to 8 characters.
That is also the difference between
ll-CC-ddd
... and ll-CC-sil. Normally the third part should mark the dialect, not
the language.
(The official way to mark a SIL language per the people who designed is:
x-sil-XXX
... by the way, but has been discussed.)
--
Anne van Kesteren
<http://annevankesteren.nl/>
Andras Timar
>
> L10n teams wishing to shorten their language code should decide on this
> *before* adding their Firefox files to the trunk :)
>
>
What should I do? Add hu directories to CVS myself?
Thanks,
Andras
Mark Tyndall
> Mark Tyndall wrote:
>
>> abc-CD-sil -- language *abc*, country *CD* and SIL identifier
>>
>> This last code type is intended for dialects for which there is no ISO
>> 639.2 language code. Note that SIL identifier can be up to eight
>> characters long (eg de-DE-bavaria, en-GB-scouse).
>
> I believe SIL codes are three letter codes per definition. Which makes
> sense, because that allows them to express 26^3 languages, which is more
> than enough.
>
> You are talking about the optional third parameter per RFC 3066 which
> may take up from 3 to 8 characters.
You're right, I am.
To clarify: the build process (for Firefox on the trunk) can cope with
* ab
* ab-CD
* abc-CD
* abc-CD-SIL
* abc-CD-dialect
where
* ab/abc - from ISO 639.1/639.2
* CD - from ISO 3166
* SIL - from the SIL list <http://www.ethnologue.com/codes/>
* dialect - following the rules from RFC 3066
regards,
Mark, who obviously needs to read RFC3066 again..
--
British English localisations of:
Mozilla Suite <http://www.tyndall.org.uk/moz_en-gb.html>
Firefox <http://www.tyndall.org.uk/fb_en-gb.html>
Thunderbird <http://www.tyndall.org.uk/tb_en-gb.html>
Alexander L. Slovesnik
17.03.2005 0:30 you wrote:
> You will have the following directories, which more closely mirror the
> canonical en-US directories:
>
> ./browser/locales
> ./toolkit/locales
> ./netwerk/locales
> ./dom/locales
>
Is it correct? Cause I see in pl-PL localization also ./other-licenses
and ./security directories
--
Sincerely yours,
Alexander L. Slovesnik a.k.a. Unghost
==>Web-page: http://forum.mozilla.ru/
==>Jabber ID: a...@mozilla.ru
==>ICQ: 205497659
==>IRC: ircs://irc.mozilla.org:6697/mozilla-ru
Mark Tyndall
> Hi Mark Tyndall
> 17.03.2005 0:30 you wrote:
>
>>You will have the following directories, which more closely mirror the
>>canonical en-US directories:
>>
>>./browser/locales
>>./toolkit/locales
>>./netwerk/locales
>>./dom/locales
>
> Is it correct? Cause I see in pl-PL localization also ./other-licenses
> and ./security directories
Hmm. pippki and pipnss used to be in /toolkit (as el-GR, he-IL and
nb-NO locales show on the trunk).
Erm, gandalf, are you doing further restructuring?
Mark..
Alexander L. Slovesnik
17.03.2005 1:09 you wrote:
> I only want to add that pl-PL should work ok, so one can use it as an
> example.
>
> Greetings Zbigniew Braniecki
Should we do it too? Cause in "Summary of MLP-Staff meeting 2005-03-15":
> gandalf announced that the l10n directories for trunk builds of
> Firefox are now ready, with the exception of Help and DOM Inspector.
--
Alexander L. Slovesnik
17.03.2005 4:25 you wrote:
> Zbigniew Braniecki wrote:
>
>> I only want to add that pl-PL should work ok, so one can use it as an
>> example.
>
>
> Also, you may want to look at the diff between 1.0 and trunk from
> 20050314. (http://bugs.aviary.pl/attachment.cgi?id=348).
>
> Greetings
> Zbigniew Braniecki
In pl-PL ./browser/chrome/cookie and ./browser/chrome/global directories
are empty. Are they needed?
Дамјан Георгиевски
> copying their files over from the AVIARY branch to the new directory
> structure on the trunk, and update them with the changes since 1.0.
> 'cvs add' is your friend here.
I hope there will be a more detailed HOWTO about what exactly needs to be
done (and why), before its too late.
> You will have the following directories, which more closely mirror the
> canonical en-US directories:
>
> ./browser/locales
> ./toolkit/locales
> ./netwerk/locales
> ./dom/locales
>
> Notes:
> If different teams are localising Fx and Tb for the same locale, please
> start communicating with each other *now* - /toolkit is shared between
> Fx and Tb.
>
> If a team wants to move to a shortened locale name (see below) (eg -
> de-DE and de-AT --> de), then please decide this *before* adding l10n
> files to trunk CVS.
--
дамјан
Give a man a fish and you feed him for a day;
teach him to use the Net and he won't bother you for weeks.
Pavel Franc
> nb-NO locales show on the trunk).
been nowhere for l10n and then Gandalf moved them in the /security
(https://bugzilla.mozilla.org/show_bug.cgi?id=279768#c72).
> You've put help files in ./browser/chrome/help
If I recall Gandalf's answer correctly, we could put it there, but it is
not used yet in the build process, so there is no reason to do it.
IMHO we should wait ;)
> Cause I see in pl-PL localization also ./other-licenses
/other-licenses directory is used for building FF/TB with the official
branding names.
Pavel Franc
-----------------------------------
Czech Mozilla Project
http://www.czilla.cz
Pavel Franc
> done (and why), before its too late.
What kind of info do you expect ?
Simple howto for someone who wants to build localized Firefox from trunk
is at http://benjamin.smedbergs.us/l10n/trunk-l10n.html
If you want to do only localization, you don't need to pull the whole
tree in step 2 - you can cvs checkout only the needed directories.
For FF:
mozilla/browser/locales
mozilla/other-licenses/branding/firefox/locales/
For FF and TB:
mozilla/dom/locales
mozilla/netwerk/locales/
mozilla/security/manager/locales
mozilla/toolkit/locales/
For TB (not done yet):
mozilla/editor/ui/locales
mozilla/mail/locales/
mozilla/other-licenses/branding/thunderbird/locales/
In step 7, I use my favourite UTF-8 editor and diff. You can probably
use MozillaTranslator to migrate from aviary to trunk either but I guess
some magic need to be applied.
Robert Kaiser
> That is also the difference between
>
> ll-CC-ddd
>
> ... and ll-CC-sil. Normally the third part should mark the dialect, not
> the language.
You can view a non-defined language (as of ISO 639.2) as a dialect of a
language family (which are defined in ISO 639.2, e.g. roa for Romance
languages).
We just recommend you use the SIL code as dialect identifier in that way
if it exists. The identifier accepts any 1-8 letter dialect identifier
though.
> (The official way to mark a SIL language per the people who designed is:
>
> x-sil-XXX
>
> ... by the way, but has been discussed.)
We don't support this, as it doesn't fit with the
<language>-<region>-<dialect> scheme at all.
Robert Kaiser
Robert Kaiser
> Let's suppose I decided to shorten my language code from hu-HU to hu.
> What should I do? Add hu directories to CVS myself?
You need to do that for trunk anyways. The difference is just that you
create a "hu" directory there instead of a "hu-HU".
For branch, nothing changes, the new system isn't applied there. Same
for Mozilla suite (as it not in CVS and content packs may cause problems).
Robert Kaiser
Andras Timar
If you ever used CVS for Mozilla Suite l10n, would you share the
"common" files between the Suite and FF/TB? Some files are identical,
therefore they could be physically the same in the CVS (same location,
same revision). Did you think about this possibility? From l10n point of
view it would make maintenance of translation easier. But if I used hu
for FF/TB and hu-HU for the Suite, that would not be possible.
Thanks,
Andras
Anne van Kesteren
> We just recommend you use the SIL code as dialect identifier in that way
> if it exists. The identifier accepts any 1-8 letter dialect identifier
> though.
That is in error with RFC 3066, which if I recall correctly only allows
3-8 characters; not 1-8.
Axel Hecht
<...>
> ** new locale name rules **
>
> see <http://wiki.mozilla.org/wiki/L10n:Simple_locale_names>
>
> The build system will now accept (for trunk Firefox only at the moment)
> locale names of the following types:
>
> ab-CD / abc-CD -- language *ab*/*abc*, country *CD*
> - this is the current naming scheme
> In future, we only want to use this if the region affects the
> localisation (eg es-ES/es-AR)
>
> ab -- language *ab*.
>
> For languages which don't need to differentiate between regions (either
> spoken only in one country, or generic across the countries it is spoken
> in (eg fr, de, eo).
There is a minor disturbance in the force around this and the
compatibility of localized extensions.
It'd be painful if extensions supposed to work on both 1.0.x and 1.x
would need to duplicate locales, like for example translate to both de
and de-DE.
IMHO, this needs some further investigation.
Chase is going to get some feedback on this from our download stats and
redirect folks, too.
Axel
Moritz 'Morty' Strübe
>
> There is a minor disturbance in the force around this and the
> compatibility of localized extensions.
> It'd be painful if extensions supposed to work on both 1.0.x and 1.x
> would need to duplicate locales, like for example translate to both de
> and de-DE.
>
> IMHO, this needs some further investigation.
>
> Chase is going to get some feedback on this from our download stats and
> redirect folks, too.
>
> Axel
I'm not familiar with this, but wouldn't wildcards make sense? I.e. it
might be sensible to have de-DE and de-AT. Not for translation but for
the bookmarks and search (Just like en-en & en-gb). This might eaven
make sense in cvs. If you build de-de you take the strings from de and
overwrite them with de-de. I think this would make customization much
more easy for different countries with the same language. Or en-GB would
be made with the en-strings overwritten by the GB strings.
Maby the Idea is stupid, maby its too complicated, but when the Idea is
good we (ahh you ;-) ) should do it now....
Morty
Robert Kaiser
> Robert Kaiser wrote:
>
>> We just recommend you use the SIL code as dialect identifier in that
>> way if it exists. The identifier accepts any 1-8 letter dialect
>> identifier though.
>
>
> That is in error with RFC 3066, which if I recall correctly only allows
> 3-8 characters; not 1-8.
Sure, it's 3-8, sorry.
Robert Kaiser
Robert Kaiser
> I'm not familiar with this, but wouldn't wildcards make sense? I.e. it
> might be sensible to have de-DE and de-AT. Not for translation but for
> the bookmarks and search (Just like en-en & en-gb). This might eaven
> make sense in cvs. If you build de-de you take the strings from de and
> overwrite them with de-de. I think this would make customization much
> more easy for different countries with the same language. Or en-GB would
> be made with the en-strings overwritten by the GB strings.
> Maby the Idea is stupid, maby its too complicated, but when the Idea is
> good we (ahh you ;-) ) should do it now....
That's a thought for the future, but we're not ready for that yet. I
know that GNU gettext has ways for this, but as we currently have no
fallbacks at all, we're quite some distance away from that at the moment.
For "de" this is a non-issue at the moment, I believe, though.
I've been doing a "de-AT" suite for a long time now used for all German
speaking countries without any changes.
Robert Kaiser
Robert Kaiser
Mozilla suite will not come to CVS, IMO.
The new suite project ("seamonkey" or with whatever name we end up with)
will hopefully make the move though. But as I have a big word in that
project, and I am a seamonkey localizer as well, and my thoughts about
this started with wanting to rename my project from "de-AT" to "de", you
can be sure it will be no problem when we move to CVS with that project.
My personal plan is to remove the seperate content packs and merge their
content into en-US.jar - but we'll see what our final solution will be.
Conclusion:
When the suite moves to CVS, this problem will be solved. As I'm
planning to do that move with my own locale on the suite, I'll take care
of that one.
Robert Kaiser
Andras Timar
>
> Conclusion:
> When the suite moves to CVS, this problem will be solved. As I'm
> planning to do that move with my own locale on the suite, I'll take care
> of that one.
>
> Robert Kaiser
Excellent! Thanks.
Andras
Benoit
> Mark Tyndall wrote:
>>
>> For languages which don't need to differentiate between regions
>> (either spoken only in one country, or generic across the countries it
>> is spoken in (eg fr, de, eo).
>
> There is a minor disturbance in the force around this and the
> compatibility of localized extensions.
> It'd be painful if extensions supposed to work on both 1.0.x and 1.x
> would need to duplicate locales, like for example translate to both de
> and de-DE.
>
> IMHO, this needs some further investigation.
Hi, any news on this? We are carefully waiting to land as "fr" on the
trunk (at least partly) because of that possible issue.
I've seen on lxr that the russian localization is now using the
two-letter scheme on the trunk, has it been tested with existing extensions?
--
Benoit
FrenchMozilla l10n team
Robert Kaiser
> Hi, any news on this? We are carefully waiting to land as "fr" on the
> trunk (at least partly) because of that possible issue.
Yes.
Benjamin Smedberg said: "Don't care about that, it should just work".
Obviously, he has once again done some incredibly fine programming and
made that work before it ever did happen...
Robert Kaiser
Hasse
Are there any other remaining issues with this. According to this page,
http://wiki.mozilla.org/L10n:Simple_locale_names
Chase had some concerns about the update system.
--
Hasse
Mozilla sv-SE L10n team
Robert Kaiser
I agreed with him that it's best if we are landing a few locales with
the new names soon, as we have something to base testing on then.
Better to have those things early and we can tweak the tools (update,
tinderbox, bouncer) for them early enough before 1.1 comes up.
So, essentially, if you're landing locales on the trunk that weren't
there before, and you want to use shortened locale names (or need to use
longer ones), then please fo it, as long as you adhere to the outlayed
specification of locale names.
Robert Kaiser
Axel Hecht
did you get around to that inquiry yet? If so, was there feedback on it?
Thanks
Axel