Localization decisions regarding firefox 1.0
Benjamin D. Smedberg
There have been many complaints on this newsgroup and elsewhere
regarding the difficulty of localizing Firefox 0.9. I apologize for any
lack of communication that made it more difficult to localize the
Firefox release. It is true that features and bugfixes in the extension
manager caused many other priorities to be dropped during the 0.9
release cycle.
Providing an ongoing and sustainable localization mechanism for the
new-toolkit apps is one of our top priorities heading into Firefox 1.0.
This message outlines the planned localization system:
LOCALIZING THE MAIN FIREFOX/THUNDERBIRD APP:
* All language-sepcific files will exist in CVS in centralized
locations:
toolkit/locale/ab-CD/...
browser/locale/ab-CD/...
mail/locale/ab-CD/...
This includes files packaged as browser chrome, as well as
miscellaneous other files such as installer scripts and
profile defaults.
This *includes* the en-US language files. I will be working on
reorganizing the current English files into their new location over
the next few days. I will send out an email when this process is
complete, so that other languages can follow the pattern specified.
* The en-US language will continue to be the "development" language.
This means that when toolkit/browser developers make changes that
require localization, they must commit changes to the en-US language.
Other languages may update as often as necessary to stay current with
the en-US directory structure.
* Localizers who are comfortable using automated tools
such as the Mozilla translator will still be able to use them. You can
JAR the en-US directory, edit it using the Mozilla Translator, and
un-JAR your results to commit into CVS.
* Localization changes will not require review/superreview. Each
language will have an owner, who may make changes as appropriate. If
others wish to make changes, they must obtain the approval of that
owner.
If you wish to be owner of a localization, or wish to nominate someone
else, please email me (bsme...@covad.net).
mozilla.org will be responsible for producing official localized
firefox/thunderbird builds.
It is also possible, but shouldn't normally be necessary, to ship a
firefox/thunderbird langpack as an extension. Firefox will not be
providing locale-switching UI.
LOCALIZING EXTENSIONS:
Extension are localized differently than major apps. Every extension
should ship at least one locale with its content package (I expect that
would normally be English, but that is up to the extension developer).
The extension *may* choose to ship multiple locales by default. Extra
locale-packs for that extension will also be installed as extensions.
(So you would install the "Foopy" extension which came with English;
then you would also install "Foopy Deutche langpack").
update.mozilla.org will be gradually improved to offer more localization
features. By firefox1.0, the auto-update feature will be locale-aware,
at least for the main app (localization support for extensions will take
some significant backend work in the chrome registry and extension
manager, which may not be ready for Firefox 1.0).
I welcome constructive comments on this localization plan; please post
comment here at npm.l10n (I do not read mozillazine forums, please don't
post comments for me there). I know that there have been disagreements
with regard to putting localizations in the CVS tree, but Ben Goodger
and I agree that this is the best solution for long-term management of
the tree.
Sincerely,
Benjamin Smedberg
Axel Hecht
Benjamin D. Smedberg wrote:
> Dear localizers:
>
> There have been many complaints on this newsgroup and elsewhere
> regarding the difficulty of localizing Firefox 0.9. I apologize for any
> lack of communication that made it more difficult to localize the
> Firefox release. It is true that features and bugfixes in the extension
> manager caused many other priorities to be dropped during the 0.9
> release cycle.
>
> Providing an ongoing and sustainable localization mechanism for the
> new-toolkit apps is one of our top priorities heading into Firefox 1.0.
> This message outlines the planned localization system:
>
> LOCALIZING THE MAIN FIREFOX/THUNDERBIRD APP:
>
> * All language-sepcific files will exist in CVS in centralized
> locations:
>
> toolkit/locale/ab-CD/...
> browser/locale/ab-CD/...
> mail/locale/ab-CD/...
>
> This includes files packaged as browser chrome, as well as
> miscellaneous other files such as installer scripts and
> profile defaults.
>
> This *includes* the en-US language files. I will be working on
> reorganizing the current English files into their new location over
> the next few days. I will send out an email when this process is
> complete, so that other languages can follow the pattern specified.
Mozilla Europe will be happy to assist here, may it be in terms of
evangelising the decision in the one direction or the other.
We should probably note that this scheme tries to cut down the process
with our branding/trademark policy. I personally think it's a very good
thing to see mozilla.org taking the responsability for the creation of
localized builds, that should get the builds public and official much
quicker than it has happened in the past.
> * The en-US language will continue to be the "development" language.
> This means that when toolkit/browser developers make changes that
> require localization, they must commit changes to the en-US language.
> Other languages may update as often as necessary to stay current with
> the en-US directory structure.
mozilla.org should probably handle branch management for l10n teams.
That is one of the more involved problems. How about getting the
branches done together with the en tree (that might just happen
naturally), and announce in the newsgroup how to pull that branch.
Talkin about pulling the tree, could we make it such that folks can
decide which languages they want to pull from the server? I have a modem
(yes silly), but other localizers have that, too, and being able to just
pull the relevant files for the work you're doing will be important, I
guess.
> * Localizers who are comfortable using automated tools
> such as the Mozilla translator will still be able to use them. You can
> JAR the en-US directory, edit it using the Mozilla Translator, and
> un-JAR your results to commit into CVS.
Very good news.
> * Localization changes will not require review/superreview. Each
> language will have an owner, who may make changes as appropriate. If
> others wish to make changes, they must obtain the approval of that
> owner.
Does that mean that localisation owners can create the tree rules they
want? Or will there be a single tree rule for all languages?
> If you wish to be owner of a localization, or wish to nominate someone
> else, please email me (bsme...@covad.net).
>
> mozilla.org will be responsible for producing official localized
> firefox/thunderbird builds.
Guess I said "yay" already.
So testing of localisations should be done with the release candidates?
Seems fine, but how should things work for alphas and betas?
We will likely need a way for l10n owners to signal a "yes, this has
been tested and bugs were fixed". Tracking bugs?
Who in mozilla.org will be the coordinating person, is that settled yet?
A name will probably help.
> It is also possible, but shouldn't normally be necessary, to ship a
> firefox/thunderbird langpack as an extension. Firefox will not be
> providing locale-switching UI.
Let's hope that we just need a single extension to get an extension
locale-switching UI working.
> LOCALIZING EXTENSIONS:
>
> Extension are localized differently than major apps. Every extension
> should ship at least one locale with its content package (I expect that
> would normally be English, but that is up to the extension developer).
> The extension *may* choose to ship multiple locales by default. Extra
> locale-packs for that extension will also be installed as extensions.
> (So you would install the "Foopy" extension which came with English;
> then you would also install "Foopy Deutche langpack").
I blogged about this on
http://www.axel-hecht.de/blog/archives/000112.html, comments here or in
a new thread, please. I disabled comments on my blog due to excessive spam.
> UPDATE.MOZILLA.ORG:
>
> update.mozilla.org will be gradually improved to offer more localization
> features. By firefox1.0, the auto-update feature will be locale-aware,
> at least for the main app (localization support for extensions will take
> some significant backend work in the chrome registry and extension
> manager, which may not be ready for Firefox 1.0).
>
> I welcome constructive comments on this localization plan; please post
> comment here at npm.l10n (I do not read mozillazine forums, please don't
> post comments for me there). I know that there have been disagreements
> with regard to putting localizations in the CVS tree, but Ben Goodger
> and I agree that this is the best solution for long-term management of
> the tree.
Axel
Ville Pohjanheimo
> * All language-sepcific files will exist in CVS in centralized
> locations
[snip]
> mozilla.org will be responsible for producing official localized
> firefox/thunderbird builds.
The fact that packaging builds becomes mozilla.org's responsibility is
a major improvement to the current situation and I thank all those
responsible for that.
This improvement ofcourse is made possible by the switch to CVS but,
though I am willing to pay the price of learning CVS to get rid of
managing builds, I wonder if it would be possible to make a simpler
front-end for localizers to contribute (than cvs). Perhaps a password
secured upload page where we could simply upload our .JARs and a
script on mozilla.org would take care of unzipping the package and
committing it. Whether this script could also be somewhat intelligent
and know where to commit the inspector -directory is something that
depends on implementation difficulties and I'm not sure if that is
possible.
A simple upload-page like this would allow us localizers to focus on
what is most important - the quality of our translations.
I would also like to ask your thoughts on a string freeze -policy for
Firefox/Thunderbird? A sufficiently long string freeze would greatly
increase the amount of complete translations at lauch times. The
length should probably be discussed with largest (by users)
localizations but still taking into account the often simulatenous
launches of FF and TB as some localization projects are a one man
effort (like mine) and two launches at the same time can be a strech.
Ville Pohjanheimo
fi-FI localization Firefox / Thunderbird
Tímár András
Benjamin D. Smedberg írta:
>
> * The en-US language will continue to be the "development" language.
> This means that when toolkit/browser developers make changes that
> require localization, they must commit changes to the en-US language.
> Other languages may update as often as necessary to stay current with
> the en-US directory structure.
>
Great news! Please consider to adopt the process which the developers of
Mozilla Caledar follow. When they commit a change to en-US language, the
commit the English string to all ab-CD languages, too. Then they send a
notification to registered translators and ask them to make a patch.
If you do not commit new English strings to every language, it may
result in XUL errors or other problems in localized builds.
> mozilla.org will be responsible for producing official localized
> firefox/thunderbird builds.
>
Are config.ini, install.ini, uninstall.ini etc. localisable in mozilla
CVS tree right now? Also, hardcoded "(en)" strings should be removed
from install.js files before you can produce a fully localized build
automatically.
Cheers,
Andras Timar
David Fraser
> Dear localizers:
>
> There have been many complaints on this newsgroup and elsewhere
> regarding the difficulty of localizing Firefox 0.9. I apologize for any
> lack of communication that made it more difficult to localize the
> Firefox release. It is true that features and bugfixes in the extension
> manager caused many other priorities to be dropped during the 0.9
> release cycle.
>
> Providing an ongoing and sustainable localization mechanism for the
> new-toolkit apps is one of our top priorities heading into Firefox 1.0.
Glad to hear it! Thanks for sorting this out...
> This message outlines the planned localization system:
>
> LOCALIZING THE MAIN FIREFOX/THUNDERBIRD APP:
>
> * All language-sepcific files will exist in CVS in centralized
> locations:
>
> toolkit/locale/ab-CD/...
> browser/locale/ab-CD/...
> mail/locale/ab-CD/...
>
> This includes files packaged as browser chrome, as well as
> miscellaneous other files such as installer scripts and
> profile defaults.
>
> This *includes* the en-US language files. I will be working on
> reorganizing the current English files into their new location over
> the next few days. I will send out an email when this process is
> complete, so that other languages can follow the pattern specified.
>
Excellent plan.
> * The en-US language will continue to be the "development" language.
> This means that when toolkit/browser developers make changes that
> require localization, they must commit changes to the en-US language.
> Other languages may update as often as necessary to stay current with
> the en-US directory structure.
>
> * Localizers who are comfortable using automated tools
> such as the Mozilla translator will still be able to use them. You can
> JAR the en-US directory, edit it using the Mozilla Translator, and
> un-JAR your results to commit into CVS.
>
> * Localization changes will not require review/superreview. Each
> language will have an owner, who may make changes as appropriate. If
> others wish to make changes, they must obtain the approval of that
> owner.
>
> If you wish to be owner of a localization, or wish to nominate someone
> else, please email me (bsme...@covad.net).
>
> mozilla.org will be responsible for producing official localized
> firefox/thunderbird builds.
>
This is great. Will you allow multi-language builds?
> It is also possible, but shouldn't normally be necessary, to ship a
> firefox/thunderbird langpack as an extension. Firefox will not be
> providing locale-switching UI.
>
Is the reason to cut down on code bloat? When somebody writes
locale-switching UI, would you give an estimate of the maximum number of
bytes allowed for this feature? :-)
> LOCALIZING EXTENSIONS:
>
> Extension are localized differently than major apps. Every extension
> should ship at least one locale with its content package (I expect that
> would normally be English, but that is up to the extension developer).
> The extension *may* choose to ship multiple locales by default. Extra
> locale-packs for that extension will also be installed as extensions.
> (So you would install the "Foopy" extension which came with English;
> then you would also install "Foopy Deutche langpack").
>
Can we make this happen automatically? How will language packs be
categorised / found?
> UPDATE.MOZILLA.ORG:
>
> update.mozilla.org will be gradually improved to offer more localization
> features. By firefox1.0, the auto-update feature will be locale-aware,
> at least for the main app (localization support for extensions will take
> some significant backend work in the chrome registry and extension
> manager, which may not be ready for Firefox 1.0).
>
> I welcome constructive comments on this localization plan; please post
> comment here at npm.l10n (I do not read mozillazine forums, please don't
> post comments for me there). I know that there have been disagreements
> with regard to putting localizations in the CVS tree, but Ben Goodger
> and I agree that this is the best solution for long-term management of
> the tree.
Glad they are going in to CVS. Presumably this is going to affect the
main mozilla branch as well (which affects even more localizers
currently) ... any plans as to that?
David
David Fraser
>> * The en-US language will continue to be the "development" language.
>> This means that when toolkit/browser developers make changes that
>> require localization, they must commit changes to the en-US language.
>> Other languages may update as often as necessary to stay current with
>> the en-US directory structure.
>
>
> mozilla.org should probably handle branch management for l10n teams.
> That is one of the more involved problems. How about getting the
> branches done together with the en tree (that might just happen
> naturally), and announce in the newsgroup how to pull that branch.
>
> Talkin about pulling the tree, could we make it such that folks can
> decide which languages they want to pull from the server? I have a modem
> (yes silly), but other localizers have that, too, and being able to just
> pull the relevant files for the work you're doing will be important, I
> guess.
>
Even cvs modules would be useful for this ... an alias for each language
that gets all of the l10n files for that language would be fantastic (so
you can do stuff without getting any of the main source code etc).
I presume there could be a .mozconfig switch for people using that
system, something like
ac_add_options --enable-languages=en-US,af-ZA,zu-ZA,nso-ZA
>> It is also possible, but shouldn't normally be necessary, to ship a
>> firefox/thunderbird langpack as an extension. Firefox will not be
>> providing locale-switching UI.
>
>
> Let's hope that we just need a single extension to get an extension
> locale-switching UI working.
>
It would be great to have multi-language builds (Western Europe, Eastern
Europe, Africa, All Languages) with this extension included... think of
internet cafes etc.
>> LOCALIZING EXTENSIONS:
>>
>> Extension are localized differently than major apps. Every extension
>> should ship at least one locale with its content package (I expect
>> that would normally be English, but that is up to the extension
>> developer). The extension *may* choose to ship multiple locales by
>> default. Extra locale-packs for that extension will also be installed
>> as extensions. (So you would install the "Foopy" extension which came
>> with English; then you would also install "Foopy Deutche langpack").
>
>
> I blogged about this on
> http://www.axel-hecht.de/blog/archives/000112.html, comments here or in
> a new thread, please. I disabled comments on my blog due to excessive spam.
>
I'm pretty convinced that actually the extension manager needs to
understand localization packages as a special category, not try and
handle them with dependencies. Likewise for update.mozdev.org. If you
look at the discussions they've had on the debian lists about apt-get
doing this, and think that apt-get is a bit more powerful than the
extensions manager, it should make sense.
David
mpco...@rogers.com
> This improvement ofcourse is made possible by the switch to CVS but,
> though I am willing to pay the price of learning CVS to get rid of
> managing builds, I wonder if it would be possible to make a simpler
> front-end for localizers to contribute (than cvs). Perhaps a password
> secured upload page where we could simply upload our .JARs and a
> script on mozilla.org would take care of unzipping the package and
> committing it. Whether this script could also be somewhat intelligent
> and know where to commit the inspector -directory is something that
> depends on implementation difficulties and I'm not sure if that is
> possible.
>
> A simple upload-page like this would allow us localizers to focus on
> what is most important - the quality of our translations.
In terms of what you're really going to need to know for CVS purposes, I
can write a tutorial that's quite straightforward.
However, for an example, here's all you'd need, ideally:
set CVSROOT=user%dom...@cvs.mozilla.org:/cvsroot (unless you use
multiple cvs accounts, you can make this a global variable)
cvs co mozilla/browser/locale/ab-CD mozilla/toolkit/locale/ab-CD
<make whatever changes to the appropriate files>
if files were added:
cvs add mozilla/browser/locale/ab-CD mozilla/toolkit/locale/ab-CD"
cvs commit -m "updates for ab-CD localization"
mozilla/browser/locale/ab-CD mozilla/toolkit/locale/ab-CD
And the changes are in.
> I would also like to ask your thoughts on a string freeze -policy for
> Firefox/Thunderbird? A sufficiently long string freeze would greatly
> increase the amount of complete translations at lauch times.
mozilla.org already does l10n freezes for releases of Mozilla Suite,
I'll assume we will do the same.
KaiRo - Robert Kaiser
> main mozilla branch as well (which affects even more localizers
> currently) ... any plans as to that?
From what Benjamin is telling here, it's currently not affecting
Seamonkey, as we don't use toolkit/, mail/ or browser/ there. Maybe we
should think of adopting this way of this there as well though. It's
something I have thought of a long time as a completely different way to
get L10n into CVS, probably even the better way from the view of a tree.
The problem is that people pulling the source might pull all the
localizations with it, causing lots of traffic for unusued files, and
people pulling the localizations or updating them have to work in a
bunch of different directories on CVS and don't have everything in one
place as they would with using the top-level l10n/ directory in CVS.
Another question is how to get other localized resources into the
builds, such as spellchecking directories, localized default bookmarks
or localized search plugins.
Robert Kaiser
Oscar Manuel Gómez Senovilla
> Dear localizers:
Hello. I'm from the spanish team.
> There have been many complaints on this newsgroup and elsewhere
> regarding the difficulty of localizing Firefox 0.9. I apologize for any
> lack of communication that made it more difficult to localize the
> Firefox release. It is true that features and bugfixes in the extension
> manager caused many other priorities to be dropped during the 0.9
> release cycle.
>
> Providing an ongoing and sustainable localization mechanism for the
> new-toolkit apps is one of our top priorities heading into Firefox 1.0.
> This message outlines the planned localization system:
>
> LOCALIZING THE MAIN FIREFOX/THUNDERBIRD APP:
>
> * All language-sepcific files will exist in CVS in centralized
> locations:
>
> toolkit/locale/ab-CD/...
> browser/locale/ab-CD/...
> mail/locale/ab-CD/...
Well, I cut here, since I could agree, but mostly not.
At this point, I think that if mozilla.org really wants to care about
the localizers feeling comfortable with their effort, they must provide
the necessary tools (not just info and leave that on the localizer's
skill and/or free time to investigate). Mozilla.org must do the efforts
(not just listening or even providing hosting), but developing
whatever's necessary for this work.
Below, you mentioned that people using tools like MT could go on using
them. I thinks this is not bad, but can't stay idle anymore.
As I mentioned in the bug, I can't understand what stops mozilla.org
from providing a high-level tool for managing the translations, and give
the results to mozilla.org (and we can make our custom builds, of
course). MT is a very good tool (not perfect), but should be reviewed by
mozilla.org to fit the "new formats". I take MT as starting point just
in order to save time, but maybe mozilla.org wants to start from
scratch. It's up to the developers' choice.
Localizers who still want to use the "raw method" (uncompress and edit
by hand), it's up to themselves, but I personally find it a pain.
My opinion is that mozilla.org should provide a separate package
(ideally an en-US.xpi file) containing the _full_ strings (don't forget
inspector or whatever can be inside the UI) that had the proper
structure so any localization team doesn't have to investigate how to
build it, just give it to the high-level tool, and this one should be on
charge of analyzing the xpi, find the differences, and show them to the
localizator. This as main basic start. Further discussion could be a bug
or more messages in the thread. If I didn't say, the tool should
recreate the xpi with the same structure as the original xpi, but being
able to choose the exported language(s).
I still wonder what happened last year when Henrik Lyngaard (sorry if I
misspell it) created a thread about MT improvements.
As I think can be seen, I'm just exposing what I (personally) think
should be basic guidelines to start a good collaboration, instead of
going back to the old method changing "just a little more info (?) and a
host, but still on your own".
Regards.
Martijn Ras
> My opinion is that mozilla.org should provide a separate package
> (ideally an en-US.xpi file) containing the _full_ strings (don't
> forget inspector or whatever can be inside the UI) that had the proper
> structure so any localization team doesn't have to investigate how to
> build it
[MR]
I'd also prefer a single point under which to find all strings, as
checking multiple places risks overseeing chances ...
[/MR]
[snip]
> Localizers who still want to use the "raw method" (uncompress and edit
> by hand), it's up to themselves, but I personally find it a pain.
[/snip]
[MR]
I'm one of those, last time i checked i still didn't like the ouput by
MT as is doesn't generate a one to one copies of the original (en-US)
files. I think translated files ought to be one to one copies of the
original files so one can use diff to see if everything has been translated.
Editing by hadn in your favorite editor shouldn't be a pain, email me in
case you're interested in receiving my single script to filter the diffs.
[/MR]
leaf
> Axel Hecht wrote:
>
>> mozilla.org should probably handle branch management for l10n teams.
>> That is one of the more involved problems. How about getting the
>> branches done together with the en tree (that might just happen
>> naturally), and announce in the newsgroup how to pull that branch.
The locales will be tagged along with the rest of the tree for release
branches, and ideally there will be a mechanism for pulling just the
locale you wish to work on (in addition to the en-US base locale).
>
> Even cvs modules would be useful for this ... an alias for each language
> that gets all of the l10n files for that language would be fantastic (so
> you can do stuff without getting any of the main source code etc).
> I presume there could be a .mozconfig switch for people using that
> system, something like
> ac_add_options --enable-languages=en-US,af-ZA,zu-ZA,nso-ZA
>
CVS modules get unwieldy fast. This will probably be better handled in
the pull scripts, keyed as you suggest from configure options. (though,
i'd use "locales" instead of "langauges")
>
> It would be great to have multi-language builds (Western Europe, Eastern
> Europe, Africa, All Languages) with this extension included... think of
> internet cafes etc.
>
The idea, ultimately, is to make two binaries available: One that is
just en-US, and one that is built with all available localizations
included, which is keyed on the locale of the system it installs/runs on.
>>
>
> I'm pretty convinced that actually the extension manager needs to
> understand localization packages as a special category, not try and
> handle them with dependencies. Likewise for update.mozdev.org. If you
> look at the discussions they've had on the debian lists about apt-get
> doing this, and think that apt-get is a bit more powerful than the
> extensions manager, it should make sense.
>
I think this is a tough sell to the developers of the extension manager.
You're trying to compare a commandline utility with extremely savvy
users to a UI that is meant to be as simple as possible. It's not a fair
comparison. Why does locale need special extension handling, exactly?
It's just a modification of the current installation, right? Like every
other extension.
--
cvs winter / files are no more, but once were / can build no longer
x s
>> Eastern Europe, Africa, All Languages) with this extension included...
>> think of internet cafes etc.
>>
>
> The idea, ultimately, is to make two binaries available: One that is
> just en-US, and one that is built with all available localizations
> included, which is keyed on the locale of the system it installs/runs on.
>
languages, and some of us use an English OS and a localized Mozilla
build. I would prefer a build that starts installing by "asking you"
which locale do you prefer. And the only part to be keyed to the locale
of the OS is that initial window.
leaf
You'll have to convince the project owner to do this, and it might be a
tough sell. The only reason we got the second localized binary put on
the table is that it doesn't add anything to the UI. He might not care,
of course, if the installer change is present only in the localized binary.
Axel Hecht
> David Fraser wrote:
>
>> Axel Hecht wrote:
>>
<...>
>>
>> I'm pretty convinced that actually the extension manager needs to
>> understand localization packages as a special category, not try and
>> handle them with dependencies. Likewise for update.mozdev.org. If you
>> look at the discussions they've had on the debian lists about apt-get
>> doing this, and think that apt-get is a bit more powerful than the
>> extensions manager, it should make sense.
>>
>
> I think this is a tough sell to the developers of the extension manager.
> You're trying to compare a commandline utility with extremely savvy
> users to a UI that is meant to be as simple as possible. It's not a fair
> comparison. Why does locale need special extension handling, exactly?
> It's just a modification of the current installation, right? Like every
> other extension.
The problem with extensions and localisation is to have that work with
extensions that do not provide the locale that is currently used. There
is hardly any chance to get mozdev authors to localize to all those
african languages. At the same time, nobody will want those builds to be
crippleware without basically any extensions available.
Another issue is that localisations of both FF and extensions drop in as
time goes by, and it's gonna be bad if one has to release an extension
from scratch (and maybe even users of that extension being asked to
update) when just another localisation popped up.
Regarding the unified localisation build, I'm not really fond of the
idea that download size is only valuable to US citizens, with the rest
of the world eating bloat. That one is going to be hard to sell. Not to
Ben, but to users.
Axel
Zbigniew Braniecki
> The idea, ultimately, is to make two binaries available: One that is
> just en-US, and one that is built with all available localizations
> included, which is keyed on the locale of the system it installs/runs on.
You must be kidding. All avaible localizations? So I will give to Polish
users useless additional megabytes of not needed data?
I'm starting to be very afraid about futur of localization.
> Why does locale need special extension handling, exactly?
> It's just a modification of the current installation, right? Like every
> other extension.
Meaby because gives user some additional funcationality, and language
pack gives user ability to understand the application.
Greetings
Zbigniew Braniecki
Axel Hecht
This should actually be sold the other way around. Ben should sell his
scheme to the users, not vice versa.
Axel
Axel Hecht
<...>
> As I mentioned in the bug, I can't understand what stops mozilla.org
> from providing a high-level tool for managing the translations, and give
> the results to mozilla.org (and we can make our custom builds, of
> course).
Let me cut here. The answer is simple, lack of manpower. And of course,
lack of expertise.
Those folks that write the mozilla.org applications are not the ones
that do the localisation, and thus, they're the wrong folks to provide
the definition of such an application. And as there are tools like MT,
there's no need for them to do so.
(Of course, breaking such tools is a bad idea.)
Axel
Oscar Manuel Gómez Senovilla
> Oscar Manuel Gómez Senovilla wrote:
> <...>
>
>> As I mentioned in the bug, I can't understand what stops mozilla.org
>> from providing a high-level tool for managing the translations, and
>> give the results to mozilla.org (and we can make our custom builds, of
>> course).
>
>
> Let me cut here. The answer is simple, lack of manpower. And of course,
> lack of expertise.
If that's true, what are we doing here then? Are we asking for help to
who has no manpower, expertise, etc?
> Those folks that write the mozilla.org applications are not the ones
> that do the localisation, and thus, they're the wrong folks to provide
> the definition of such an application. And as there are tools like MT,
> there's no need for them to do so.
> (Of course, breaking such tools is a bad idea.)
I can't agree. They decide the way the en-US files are handled and
generated from the source code, so they should do a similar thing with
the files provided with the rest to produce similar effect. And since
they have the algorithm, it shouldn't be a problem adapt it to a locale
apart from en-US.
What I want from mozilla.org is _compromise_ to make localizers dedicate
time _only_ to localization without having to hack any code from them. I
don't want patchs, but real done good work. I'm sure they want to
enhance the translations, but providing hosting and good words is not
the way, because the problem will still be the same.
Regards.
Oscar Manuel Gómez Senovilla
> [snip]
>
>> Localizers who still want to use the "raw method" (uncompress and edit
>> by hand), it's up to themselves, but I personally find it a pain.
>
> [/snip]
> [MR]
> I'm one of those, last time i checked i still didn't like the ouput by
> MT as is doesn't generate a one to one copies of the original (en-US)
> files. I think translated files ought to be one to one copies of the
> original files so one can use diff to see if everything has been
> translated.
>
> Editing by hadn in your favorite editor shouldn't be a pain, email me in
> case you're interested in receiving my single script to filter the diffs.
> [/MR]
I didn't say that.
My point is that the role of a localizer is take _the_ english file,
translate the necessary strings and save the work. Tbat's all. Nobody
can ask him/her to know xul, rdf, javascript or whatever is inside the
file, and doing so will only lead to repeat the actual situation, and
will never fix it. That's the reason why we've got to the actual
situation, and not facing it like this, will not be solutions, maybe
temporary patches.
If you think you have the solution for the situation, then put it in
mozilla.org's hands and encourage them to work around it to provide a
_proper_ solution for all teams (i.e. without asking localizators to
have other knowledge than translating from english to their own language).
Regards.
Henrik Lynggaard
> Dear localizers:
> Providing an ongoing and sustainable localization mechanism for the
> new-toolkit apps is one of our top priorities heading into Firefox 1.0.
great
> This message outlines the planned localization system:
>
> LOCALIZING THE MAIN FIREFOX/THUNDERBIRD APP:
>
> * All language-sepcific files will exist in CVS in centralized
> locations:
>
> toolkit/locale/ab-CD/...
> browser/locale/ab-CD/...
> mail/locale/ab-CD/...
As someone suggested I think you might want to reconsider this. While it
seems nice now please consider how alternative localized content fit
into this. I'm thinking of stuff like spellchecking directories,
localized default bookmarks or localized search plugins etc..
Personally I like the idea of having everything under a l10n toplevel
directory..
> * The en-US language will continue to be the "development" language.
> This means that when toolkit/browser developers make changes that
> require localization, they must commit changes to the en-US language.
> Other languages may update as often as necessary to stay current with
> the en-US directory structure.
>
> * Localizers who are comfortable using automated tools
> such as the Mozilla translator will still be able to use them. You can
> JAR the en-US directory, edit it using the Mozilla Translator, and
> un-JAR your results to commit into CVS.
Great :-), please keep us informed of decisions, so that we can see (and
hopefully prevent)if these tools break. Possible even make them
integrate well with the cvs stuff.
>
> * Localization changes will not require review/superreview. Each
> language will have an owner, who may make changes as appropriate. If
> others wish to make changes, they must obtain the approval of that
> owner.
Thanx...
Hopefully we wont be needed pull script and such things in order to
checkin/checkout the relevant files. It would be easier for localizators
if they could use a nice gui client like smartCVS
(http://www.smartcvs.com) to their cvs stuff.
> mozilla.org will be responsible for producing official localized
> firefox/thunderbird builds.
Will you be providing only full builds or will you also be providing
language pack ?
I think you should provide language packs too, since I think a lot of
people will want it in more than one locale, and it is better to be able
to add them later. Think if families with different backgrounds,
internet cafes, instituitions or anywhere where more than one person
might be using the computer.
>
> It is also possible, but shouldn't normally be necessary, to ship a
> firefox/thunderbird langpack as an extension. Firefox will not be
> providing locale-switching UI.
Language packs are not extensions, they are more like themes. If you
have several extensions you can enable/disable them idividually like
checkboxes, whereas with themes you can only activate one at the time
like radiobuttons.
Language pack should also only be activateable one at the time like
radiobuttons with the possible exception of fallback rutines. I think
there should be a third package type in update.mozilla.org
>
> LOCALIZING EXTENSIONS:
>
> Extension are localized differently than major apps. Every extension
> should ship at least one locale with its content package (I expect that
> would normally be English, but that is up to the extension developer).
> The extension *may* choose to ship multiple locales by default. Extra
> locale-packs for that extension will also be installed as extensions.
> (So you would install the "Foopy" extension which came with English;
> then you would also install "Foopy Deutche langpack").
again language packs are not extensions,they are like themes.
>
> UPDATE.MOZILLA.ORG:
>
> update.mozilla.org will be gradually improved to offer more localization
> features. By firefox1.0, the auto-update feature will be locale-aware,
> at least for the main app (localization support for extensions will take
> some significant backend work in the chrome registry and extension
> manager, which may not be ready for Firefox 1.0).
If you need help with the java server backend let me know, I'll throw
some hours at it.
I'll try and give it some thought as some things should work on the surface.
Best Regards
Henrik Lynggaard
Danish locale / MozillaTranslator
leaf
> Axel Hecht escribió:
>
>>
>> Let me cut here. The answer is simple, lack of manpower. And of
>> course, lack of expertise.
>
>
>
> If that's true, what are we doing here then? Are we asking for help to
> who has no manpower, expertise, etc?
You're here to lend *your* expertise. "We're all in it together." We do
the best with what we have.
>
>> Those folks that write the mozilla.org applications are not the ones
>> that do the localisation, and thus, they're the wrong folks to provide
>> the definition of such an application. And as there are tools like MT,
>> there's no need for them to do so.
>> (Of course, breaking such tools is a bad idea.)
>
>
>
> I can't agree. They decide the way the en-US files are handled and
> generated from the source code, so they should do a similar thing with
> the files provided with the rest to produce similar effect. And since
> they have the algorithm, it shouldn't be a problem adapt it to a locale
> apart from en-US.
en-US files aren't generated from source... they *are* source.
>
>
> What I want from mozilla.org is _compromise_ to make localizers dedicate
> time _only_ to localization without having to hack any code from them. I
> don't want patchs, but real done good work. I'm sure they want to
> enhance the translations, but providing hosting and good words is not
> the way, because the problem will still be the same.
>
>
The compromise is that we're spending effort making localization options
more supported, rather than forcing localizers to download release
builds and localize applications for repackaging. I'm not sure if you
have a good idea of the current plan, so let me restate:
browser/locale/en-US
mail/locale/en-US
toolkit/locale/en-US
will house the "default" development locale. To localize, copy to
browser/locale/ab-CD
mail/locale/ab-CD
toolkit/locale/ab-CD
then... translate the localizable strings (vi? emacs? notepad? whatever
you like!). Commit. Done.
Bonsai queries can easily show any changes that have been made to
locale-affecting strings for any given time interval.
Henrik Lynggaard
>
> The idea, ultimately, is to make two binaries available: One that is
> just en-US, and one that is built with all available localizations
> included, which is keyed on the locale of the system it installs/runs on.
I think that is a very bad approch for several reasons:
* The OS locale is very uncertain way of deterniming the desired locale,
bacause many people have it running in another locale than they really
desire their software in. Where I work (a worldwide corp), the windows
is standardized to english to ensure easier support and ease of use when
traveling to another country.
* the download will be very bloated with all those locales if firefox
takes off like the suite. A suite langpack is about 500kb plus,
(taken from
ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/l10n/lang/moz1.7/ )
and multiply that with 20 locales (again taken from suite 1.7 packages)
thats at least 10 mb. Even if we squeeze that number down to an extra
5mb it is still unacceptable.
>> I'm pretty convinced that actually the extension manager needs to
>> understand localization packages as a special category, not try and
>> handle them with dependencies. Likewise for update.mozdev.org. If you
>> look at the discussions they've had on the debian lists about apt-get
>> doing this, and think that apt-get is a bit more powerful than the
>> extensions manager, it should make sense.
>>
>
> I think this is a tough sell to the developers of the extension manager.
I agree that language pack should be treated as a third package type. I
donøt think that part should be tough to sell, as several people have
pointed to valid technical reasons.
It is more a matter of ben convincing us that all the technical issues
can be solved more elegantly and with just as easy a userinterface, if
it is not a third package type.
Best regards
henrik lynggaard
leaf
Pull scripts won't be necessary. But there probably will not be cvs
modules added for each locale. This is negotiable depending on how often
the locale dirs change in the first months of existence.
Be advised that we will be requiring some kind of encryption of cvs in
the very-near future. Either ssh or an ssl tunnel. This may interfere
with some of the nicer-to-use cvs interfaces.
>> mozilla.org will be responsible for producing official localized
>> firefox/thunderbird builds.
>
>
> Will you be providing only full builds or will you also be providing
> language pack ?
>
> I think you should provide language packs too, since I think a lot of
> people will want it in more than one locale, and it is better to be able
> to add them later. Think if families with different backgrounds,
> internet cafes, instituitions or anywhere where more than one person
> might be using the computer.
>
Operating systems determine the locale; i'm fairly certain that every
modern OS has a mechanism for changing the system locale... *this*
should be the UI that changes the locale for applications. That is the
current plan, not to add more UI to firefox to allow it to change its
locale. Do any other projects provide UI like that?
The plan now is to include all locales in one l10n build. I'm hoping (if
the size difference isn't much) to have it be the one and only binary we
provide, and have it switch locales depending on the system settings.
>>
>> It is also possible, but shouldn't normally be necessary, to ship a
>> firefox/thunderbird langpack as an extension. Firefox will not be
>> providing locale-switching UI.
>
>
> Language packs are not extensions, they are more like themes. If you
> have several extensions you can enable/disable them idividually like
> checkboxes, whereas with themes you can only activate one at the time
> like radiobuttons.
>
> Language pack should also only be activateable one at the time like
> radiobuttons with the possible exception of fallback rutines. I think
> there should be a third package type in update.mozilla.org
>
leaf
> leaf napisał(a):
>
>> The idea, ultimately, is to make two binaries available: One that is
>> just en-US, and one that is built with all available localizations
>> included, which is keyed on the locale of the system it installs/runs on.
>
>
> You must be kidding. All avaible localizations? So I will give to Polish
> users useless additional megabytes of not needed data?
>
> I'm starting to be very afraid about futur of localization.
>
Don't be so dramatic. It's possible that with quite a bit of work we can
produce a separate build for each localization in the tree. Is that
feasible for our ftp mirrors? Maybe. Is it worth adding that to the
cycle times on our tinderbox machines for release cycles? It depends on
who you ask. If it's *truly* a problem not to have full builds for
every locale, i'm sure there are solutions that don't involve giving you
nightmares.
Considering that current seamonkey users are already downloading much
more than what an all-locales firefox would look like, is paying a few
megabytes for an application that works on all locales we support really
that bad?
Another solution is to provide a localized installer for the base app
(en-US only for everything but the installer), which would then use
update.mozilla.org to install an "extension" for the appropriate locale.
>> Why does locale need special extension handling, exactly? It's just a
>> modification of the current installation, right? Like every other
>> extension.
>
>
> Meaby because gives user some additional funcationality, and language
> pack gives user ability to understand the application.
>
If the app asks the system what locale to use, and the "extension" for
the locale is installed, the app can use that locale. Why is this a
problem? Do other apps give in-app UI for locale switching? Are any of
them widely used?
Abdulkadir Topal
>
> Considering that current seamonkey users are already downloading much
> more than what an all-locales firefox would look like, is paying a few
> megabytes for an application that works on all locales we support really
> that bad?
You must really be kidding or you don't know, what you are talking
about. We have almost 50 loacales for Firefox at the moment (even though
is not even 1.0 and things change very much). That's almost 5 MB for
localisation of Firefox only. Now consider the help files which will
make another 5 MB. As you can see, we would have a zip file of 16 MB
size. Do you know, why mozilla was never as successful as Fierfox is? At
least here in Germany 2/3 of the people use dialup connections with
56k/64k. Downloading a 16MB file will take more than an hour on such
lines. We had 500.000 localised Firefox downloads from our own server so
far. It's impossible to reach this number with high file sizes.
On one hand people try to move help images to the web, to save some kilo
byte ( news://news.mozilla.org:119/cb1glr$d3...@ripley.netscape.com )
and on the other hand you find it absolutely okay that people have to
download some extra megabyte they very likely will never ever need?
Maybe I got something terribly wrong, but I found that comment very much
insulting.
Regards
Abdulkadir Topal
Ben Goodger
>> You'll have to convince the project owner to do this, and it might be
>> a tough sell. The only reason we got the second localized binary put
>> on the table is that it doesn't add anything to the UI. He might not
>> care, of course, if the installer change is present only in the
>> localized binary.
>>
>
> This should actually be sold the other way around. Ben should sell his
> scheme to the users, not vice versa.
Average user wants to get a browser. Average user does not care about
multiple languages, just wants a browser. Installs. Auto-detects most
likely language or some other sniffing scheme that does not involve
bloating the binary. Sold.
-Ben
Ben Goodger
> Auto-detects most likely language or some other sniffing scheme
(Or a selection of default language settings configured via the download
link from the website - we have an intelligent installer).
-Ben
Hasse
said...
> Considering that current seamonkey users are already downloading much
> more than what an all-locales firefox would look like, is paying a few
> megabytes for an application that works on all locales we support really
> that bad?
Why not offer only one binary then, built with all locales, including
en-US? Is forcing en-US users to download a couple of megabytes of
unused files really that bad?
--
Hasse
leaf
Touché. Clearly my bias for the single largest online demographic is
showing. This was, perhaps ironically, my first suggestion, but was shot
down as being harmful to adoption by aforementioned single largest
online demographic.
I think some other alternatives are being discussed, such as smart
installers to install the locale set on the user's system, which will
get around this issue.
leaf
>
> You must really be kidding or you don't know, what you are talking
> about. We have almost 50 loacales for Firefox at the moment (even though
> is not even 1.0 and things change very much). That's almost 5 MB for
> localisation of Firefox only. Now consider the help files which will
> make another 5 MB. As you can see, we would have a zip file of 16 MB
> size. Do you know, why mozilla was never as successful as Fierfox is? At
> least here in Germany 2/3 of the people use dialup connections with
> 56k/64k. Downloading a 16MB file will take more than an hour on such
> lines. We had 500.000 localised Firefox downloads from our own server so
> far. It's impossible to reach this number with high file sizes.
>
Put this way, i understand the motivation for a small file size. Perhaps
we can work out a way for users to get sent to a specific mirror for
their locale; When you say your server, you're not referring to
something in the ftp.mozilla.org mirror dns round robin, right? My
desire to limit the amount of full-localized builds is driven by
constrained resources: build machine time, ftp space, and complexity of
binary distribution.
> On one hand people try to move help images to the web, to save some kilo
> byte ( news://news.mozilla.org:119/cb1glr$d3...@ripley.netscape.com )
> and on the other hand you find it absolutely okay that people have to
> download some extra megabyte they very likely will never ever need?
>
> Maybe I got something terribly wrong, but I found that comment very much
> insulting.
You can feel insulted, or you can pity my ignorance. Or you can read
another message i sent to this list today, about a fully-localized
installer that xpinstalls whatever locale extension the user's system
specifies at install time. It's an idea about how to get users the
localizations they need, but i'm pretty sure i don't have time to
implement it. I'm not sure who does, and in the mean time i'm going to
implement the ideas that are feasible now.
Oscar Manuel Gómez Senovilla
> Oscar Manuel Gómez Senovilla wrote:
>
>> Axel Hecht escribió:
>>
>>> Let me cut here. The answer is simple, lack of manpower. And of
>>> course, lack of expertise.
>>
>> If that's true, what are we doing here then? Are we asking for help to
>> who has no manpower, expertise, etc?
>
> You're here to lend *your* expertise. "We're all in it together." We do
> the best with what we have.
Wow! My expertise with firefox 0.9 is failure and too much manual work.
I think we're all together here trying to find a *solution*, because the
problems were already exposed in the bug.
>> I can't agree. They decide the way the en-US files are handled and
>> generated from the source code, so they should do a similar thing with
>> the files provided with the rest to produce similar effect. And since
>> they have the algorithm, it shouldn't be a problem adapt it to a
>> locale apart from en-US.
>
>
> en-US files aren't generated from source... they *are* source.
Vow! Let's work with source code, as real programmers, then. Good solution.
>> What I want from mozilla.org is _compromise_ to make localizers
>> dedicate time _only_ to localization without having to hack any code
>> from them. I don't want patchs, but real done good work. I'm sure they
>> want to enhance the translations, but providing hosting and good words
>> is not the way, because the problem will still be the same.
>>
>>
>
> The compromise is that we're spending effort making localization options
> more supported, rather than forcing localizers to download release
> builds and localize applications for repackaging. I'm not sure if you
> have a good idea of the current plan, so let me restate:
>
> browser/locale/en-US
> mail/locale/en-US
> toolkit/locale/en-US
>
> will house the "default" development locale. To localize, copy to
>
> browser/locale/ab-CD
> mail/locale/ab-CD
> toolkit/locale/ab-CD
>
> then... translate the localizable strings (vi? emacs? notepad? whatever
> you like!). Commit. Done.
Wow! Let's put MT in the trash. Long life to dirty and non-automatized
work for non-english users, and start studying single source code
directory structure.
> Bonsai queries can easily show any changes that have been made to
> locale-affecting strings for any given time interval.
Wow! I'll enjoy a lot learning a lot of new things I never needed before
for building langpacks and installers, and never thought should ever be
necessary.
I'm sorry for having to be so ironical. It seems that MF will never
supply what I find basically necessary to do a good work, and we'll have
to go on hacking, just as now. If I have to take the methods (the
proposed new and the actual), I think that reinventing the wheel for
getting _nothing_ is a waste of time, unless MF just wants to "wash
their faces".
In the email I've replied, there isn't any information I didn't know.
I'll try to reply to the original mail, as a last resource of the work
to be done.
Regards.
Oscar Manuel Gómez Senovilla
Hello, Henrik. Glad to have news from you again.
> Benjamin D. Smedberg wrote:
>
>> * Localizers who are comfortable using automated tools
>> such as the Mozilla translator will still be able to use them. You can
>> JAR the en-US directory, edit it using the Mozilla Translator, and
>> un-JAR your results to commit into CVS.
>
>
> Great :-), please keep us informed of decisions, so that we can see (and
> hopefully prevent)if these tools break. Possible even make them
> integrate well with the cvs stuff.
It would be great if that was true. Here's the spanish Glossary.zip:
http://nave.hispalinux.es/productos/firebird/0.9/descargas/Glossary.zip
For whoever is able to generate a langpack without hacking elsewhere.
Regards
Oscar Manuel Gómez Senovilla
> Dear localizers:
>
> regarding the difficulty of localizing Firefox 0.9. I apologize for any
> lack of communication that made it more difficult to localize the
> Firefox release. It is true that features and bugfixes in the extension
> manager caused many other priorities to be dropped during the 0.9
> release cycle.
Maybe I never understood the purpose of this post (and even the bug), so
I'm not sure if MF wants to find a solution or just patch the actual
situation, so I need to know some basic things:
- Will it still be necessary that a simple localizator keeps hacking
away from just what a localizator is supposed to do? If so (heh), how
long do you think this situation will last? Forever? I want you to
remember that a localizator is only supposed to know how to translate,
click some gui options, and try his translation, and that anything out
of this is not a solution. We are not supposed to be developers not even
programmers (though some can be).
I'm aware that there can be lack of resources, etc, but I'd like to hear
that from somebody from MF itself, and so the real role to be clear to me.
I'd also like to be able to test my own translations, which I've been
unable to get with firefox 0.9. Also, have in mind that a localization
is not "do once and finished", what is a mistake. There are second
stages of debugging (just before the langpack release!) because of
typos, out of context strings, accesskeys..., and after some tests (that
is, regenerating several times the packages to try the results), build a
langpack. I don't care if MF wants to build at their site one english
pack or a multipack or whatever, it's their choice, but I want to be
able to do that at least in the same way I've been doing for the last
two years for several mozilla products. While things have been working
(with more or less hack on my side) and have been able to survive,
there's no major problem. But once MF comes into scene, they must do
something to improve localizers' work, and what I understand from the
post, the suggested method doesn't get that target at all. Maybe
everyone's Glossary.zip can be given to generate an xpi, installer or
multilanguageinstaller or multiplatform installer, but that isn't a
solution in an open source world, since everyone shuld be able to do it
himself (not to mention quality or just freedom, as I explained in the
beginning of the paragraph).
Just take a look at the results: How many languages are available at
this time comparing with any other release of any product? MF needs to
do an effort for this to be solved, and even has to take a decision
about what's more important, if taking temporarily resources from
somewhere else to really solve this, or just keep having this load forever.
Regards.
Pavel Franc
> Average user wants to get a browser. Average user does not care about
> multiple languages, just wants a browser.
This is the key point.
Average user wants his browser with downloading size as small as
possible and being completely in his language.
At the present time, the Czech users get their browser completely in
Czech language (installers, UI, bookmarks, rdf files, chrome examples)
together with the support from our CZilla.cz team, all for free and all
in our free time.
If you guys at Mozilla.org think that put our work in your CVS tree and
do the installers automatically is the right way to go, it is your
choice, and then you should do the best to manage the task to produce
the same quality browser for all non-English users as we do manually.
Otherwise, it could be our choice to continue to produce the installers
manually in order to deliver the same quality (in terms of downloading
size and translation) browser, because the quality of browser is the
main reason why we are doing all this. Moreover, some of us might be so
disappointed that could give up to spend his/her free time to produce
something that is no more perfect.
The original post was about top priorities of localization mechanism.
From some posts in this thread I have got a feeling that the new
mechanism is mainly introduced not to produce perfect browser for
non-English users but only to gather the locales in Mozilla.org CVS and
prevent localizers to do what they think is the best for users.
I hope this is just a feeling and you guys at Mozilla.org concern about
non-English users the same as we do.
Sincerely,
Pavel Franc
Henrik Lynggaard
> Henrik Lynggaard wrote:
>> Thanx...
>>
>> Hopefully we wont be needed pull script and such things in order to
>> checkin/checkout the relevant files. It would be easier for
>> localizators if they could use a nice gui client like smartCVS
>> (http://www.smartcvs.com) to their cvs stuff.
>>
>
> Pull scripts won't be necessary. But there probably will not be cvs
> modules added for each locale. This is negotiable depending on how often
> the locale dirs change in the first months of existence.
Well you could simply add empty modules for all the locales registered
on MLP pages, after that I think you will only need to add a few now and
then.
>
> Be advised that we will be requiring some kind of encryption of cvs in
> the very-near future. Either ssh or an ssl tunnel. This may interfere
> with some of the nicer-to-use cvs interfaces.
SmartCvs work very nice with ssh :-) I'm using it for sourceforge.net
CVS access.
>> I think you should provide language packs too, since I think a lot of
>> people will want it in more than one locale, and it is better to be
>> able to add them later. Think if families with different backgrounds,
>> internet cafes, instituitions or anywhere where more than one person
>> might be using the computer.
>>
>
> Operating systems determine the locale; i'm fairly certain that every
> modern OS has a mechanism for changing the system locale... *this*
> should be the UI that changes the locale for applications. That is the
> current plan, not to add more UI to firefox to allow it to change its
> locale. Do any other projects provide UI like that?
> The plan now is to include all locales in one l10n build. I'm hoping (if
> the size difference isn't much) to have it be the one and only binary we
> provide, and have it switch locales depending on the system settings.
I think relying on the OS is a very bad idea...allow me to restate the
reasons why not
* The OS locale is very uncertain way of deterniming the desired locale,
bacause many people have it running in another locale than they really
desire their software in. Where I work (a worldwide corp), the windows
is standardized to english to ensure easier support and ease of use when
traveling to another country.
* the download will be very bloated with all those locales if firefox
takes off like the suite. A suite langpack is about 500kb plus,
(taken from
ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/l10n/lang/moz1.7/ )
and multiply that with 20 locales (again taken from suite 1.7 packages)
thats at least 10 mb. Even if we squeeze that number down to an extra
5mb it is still unacceptable.
I do believe many projects as a minimum lets the user choose at install
time, some even after install.
Best Regards
Henrik Lynggaard
mpco...@rogers.com
> - Will it still be necessary that a simple localizator keeps hacking
> away from just what a localizator is supposed to do? If so (heh), how
> long do you think this situation will last? Forever? I want you to
> remember that a localizator is only supposed to know how to translate,
> click some gui options, and try his translation, and that anything out
> of this is not a solution. We are not supposed to be developers not even
> programmers (though some can be).
I've read like four posts from you in the last five minutes and I'm
still unsure what your complaint is. Is it that there isn't a tool for
easy translation? Making something that requires *NO* interaction with
the source is probably unrealistic. Sorry, that's the way it is right
now. We do what we can with what we have.
If someone wanted to fund the creation of some sort of setup whereby we
have a magical, wonderful translation tool, I'm sure we could do that
easily. I would envision something like this:
1) some sort of master file that not only has string info, but tells
where each string is used. This would have to be updated whenever
localization-breaking changes were checked in.
2) an app that reads that file format and presents the option to
translate based on location (i.e. Translate [Options [\/])
3) the app could then transparently edit the actual source files, and
generate the ab-CD.jar, saving in the appropriate directory to allow
testing. If you wanted to get really fancy, you could even invoke cvs
to commit changes once testing was complete.
This would be great I'm sure, but the problem is that a) someone has to
write it and b) someone has to maintain that localization file. Neither
is trivial in terms of time, and I don't envision someone investing that
time unless they're getting paid to. There's bigger issues in making
stuff work right in different locales, without even addressing lowering
the bar to translation. Which is ultimately all you're talking about,
and why this is unlikely to get funding.
I'm sure it'd be possible for someone to write a page/script to track
changes to localization files and identify new/changed/removed strings,
so you'd just have to go to the files in question and make the needed
edits. I don't think anyone would say that the file format for .dtd and
.properties formats is too complicated to understand. If you can't cope
with the format, you're probably not the best candidate to translate a
browser.
-- Mike
Peter Van der Beken
> then... translate the localizable strings (vi? emacs? notepad? whatever
> you like!). Commit. Done.
You forgot "Test." :-), and that is where the trouble could start. You
can't expect localizers to build a complete Firefox tree just to test a
localization.
Peter
Zbigniew Braniecki
> I think some other alternatives are being discussed, such as smart
> installers to install the locale set on the user's system, which will
> get around this issue.
The deal is not to make thing worse that it's now. At now we
(localizers) have to make very much work, but in result we have
_totally_ localized product, without almost ANY word in foregin language
which is the target of all professional localizations.
I never heard about profesionall project which builds two versions:
english and non-english containing all other locales. It's clear
ignorance. You're pointing a situation as "america" and "rest of the
world". Meaby Firefox Team just forgot that world is little bit bigger
than north-america. Or meaby You want to create product just for
us-people. Tell us about it! We're living without this knowledge and
we're trying to provide builds and support on high level for customers.
But we simply can't do this without your help.
Basing on ideas i read about i'm afraid that this "smart installer" will
be in english which of course makes whole localization process useless.
How can You say about being afraid about ftp.mozilla.org capacity
problem, if at the moment it contains all localized builds?
My idea is to build a system which would create localized versions for a
few days before release date, to give localizers ability to check if
everything is ok, and after that in the day of release all versions
would be built.
Please, tell me what is the problem with such idea.
Greetings
Zbigniew Braniecki
Oscar Manuel Gómez Senovilla
> Oscar Manuel Gómez Senovilla wrote:
>
>> - Will it still be necessary that a simple localizator keeps hacking
>> away from just what a localizator is supposed to do? If so (heh), how
>> long do you think this situation will last? Forever? I want you to
>> remember that a localizator is only supposed to know how to translate,
>> click some gui options, and try his translation, and that anything out
>> of this is not a solution. We are not supposed to be developers not
>> even programmers (though some can be).
>
>
> I've read like four posts from you in the last five minutes and I'm
> still unsure what your complaint is. Is it that there isn't a tool for
> easy translation? Making something that requires *NO* interaction with
> the source is probably unrealistic. Sorry, that's the way it is right
> now. We do what we can with what we have.
I think MT does the 90% of the work. I'm just asking for the remaining
10%. Is that so difficult?
Regards.
Peter Van der Beken
> I've read like four posts from you in the last five minutes and I'm
> still unsure what your complaint is. Is it that there isn't a tool
> for easy translation? Making something that requires *NO*
> interaction with the source is probably unrealistic. Sorry, that's
> the way it is right now. We do what we can with what we have.
You are aware of how easy it is to use MozillaTranslator to translate
the suite I hope? I'm sure there's a reason why Firefox can't have the
same localization infrastructure as Mozilla, but it also means we might
lose a good, easy tool for localizers. Dismissing the difficulties that
they are now facing by telling them they'll just have to cope is not the
way to go. Not many people know right now what it takes to localize
Firefox, so even if someone wanted to adapt MT to Firefox it's not
certain that (s)he has the information to do it.
> There's bigger issues in making stuff work right in different
> locales, without even addressing lowering the bar to translation.
> Which is ultimately all you're talking about, and why this is
> unlikely to get funding.
I think the fear is mostly that the bar to translation will be raised.
Adding cvs to the required skill set is raising the bar. Adding building
a complete Firefox tree just to test a localization is raising the bar.
It's something to keep in mind while looking for solutions.
> I don't think anyone would say that the file format for .dtd and
> .properties formats is too complicated to understand.
It never was in the suite either, but I'm fairly certain that
MozillaTranslator caused us to have much more localizations than if it
didn't exist. Localization is essential if we want this product to
succeed, and we need more localizers, not less, so anything that lowers
the bar is better.
Peter
Carlos Rodrigues
> leaf napisał(a):
>
>> I think some other alternatives are being discussed, such as smart
>> installers to install the locale set on the user's system, which will
>> get around this issue.
>
>
> The deal is not to make thing worse that it's now. At now we
> (localizers) have to make very much work, but in result we have
> _totally_ localized product, without almost ANY word in foregin
> language which is the target of all professional localizations.
>
> I never heard about profesionall project which builds two versions:
> english and non-english containing all other locales. It's clear
> ignorance. You're pointing a situation as "america" and "rest of the
> world". Meaby Firefox Team just forgot that world is little bit bigger
> than north-america. Or meaby You want to create product just for
> us-people. Tell us about it! We're living without this knowledge and
> we're trying to provide builds and support on high level for
> customers. But we simply can't do this without your help.
They probably don't realise how important it is to have Firefox
localized in some european countries. Non-localization means it is no
good for use in schools, public administration, many companies and most
domestic users. And this doesn't mean that they don't understand
english, it means that it isn't in their language and IE and Outlook
are! This is most important in the big countries, where they protect
their language more aggressively that the little countries (which, by
now know that their culture isn't that easy to corrupt by foreign
influence, if it was nobody would speak portuguese by now :) ).
Carlos - pt-PT
Ben Goodger
> If you guys at Mozilla.org think that put our work in your CVS tree and
> do the installers automatically is the right way to go, it is your
> choice, and then you should do the best to manage the task to produce
> the same quality browser for all non-English users as we do manually.
I'm sure we can come up with a good solution for the builds and
distribution.
The key point to leaf/bsmedberg's proposal is to get localizations
acting as a peer in the build process, as a better means of allowing for
synchronized localizations for releases (see
http://www.mozilla.org/projects/firefox/roadmap.html for rough timelines
for future releases), easier identification, testing and debugging of
problems specific to localized builds by developers like myself, and
more of a sense of connection between the two communities.
-Ben
Tsahi Asher
> Henrik Lynggaard wrote:
>
>> Benjamin D. Smedberg wrote:
>>
> Operating systems determine the locale; i'm fairly certain that every
> modern OS has a mechanism for changing the system locale... *this*
> should be the UI that changes the locale for applications. That is the
> current plan, not to add more UI to firefox to allow it to change its
> locale. Do any other projects provide UI like that?
>
let's see, i know of one little project called Microsoft Office. it's
really a small app, just under half a gigabyte. it has (or at least,
Office97 had. i haven't put my hands on a localized newer version yet)
an option to switch UI language from its options menu.
there's also another software maker called Adoby, you may have heard
about. they have this reader called Acrobat Reader. it has localized
versions for download, that you select on their site.
and finally, Skype, the new VoIP software, has a menu to switch UI
language. addmitably, it's hebrew translation is horrible, but it's not
my doing.
when we released firefox 0.8 in hebrew, someone wrote in a talkback in
one of the sites that wrote about that, something like "what are these
command line parameters? is this a DOS program? get back to me when you
are back in the Windows world", or something to this extend. without
locale switching UI, you might as well not have a localization feature
at all.
--
Tsahi Asher
Hebrew L10n Team
http://www.mozilla.org.il
mpco...@rogers.com
who said they had to? The goal is that unjarring the ab-CD.jar will
create the same tree structure as CVS has, so its just a matter of unjar
and commit.
mpco...@rogers.com
> mpco...@rogers.com wrote:
> > I've read like four posts from you in the last five minutes and I'm
> > still unsure what your complaint is. Is it that there isn't a tool
> > for easy translation? Making something that requires *NO*
> > interaction with the source is probably unrealistic. Sorry, that's
> > the way it is right now. We do what we can with what we have.
>
> You are aware of how easy it is to use MozillaTranslator to translate
> the suite I hope? I'm sure there's a reason why Firefox can't have the
> same localization infrastructure as Mozilla, but it also means we might
> lose a good, easy tool for localizers. Dismissing the difficulties that
> they are now facing by telling them they'll just have to cope is not the
> way to go. Not many people know right now what it takes to localize
> Firefox, so even if someone wanted to adapt MT to Firefox it's not
> certain that (s)he has the information to do it.
>
As far as I'm aware there is no reason that MT can't be adapted. No one
has done so, though. As for raising the bar, there's no need to build,
the tree structure should allow for unjar and commit, as was indicated
at the beginning. The number of CVS commands needed is very limited,
and could be done via a simple perl script/batch file.
-- Mike
Zbigniew Braniecki
> without locale switching UI, you might as well not have a localization feature
> at all.
I can almost 100% agree. The only way we can avoid adding locale
switching UI to Firefox and give non-english users a taste of Firefox is
to release fully localizated versions.
But nobody will play with command-line in todays world, and nobody will
give Firefox a try if first strings he'll see are in english.
Greetings
Zbigniew Braniecki
--
Firefox.pl (http://www.firefox.pl)
Oscar Manuel Gómez Senovilla
That's not needed to say. Do you want a quality work? If so, it needs to
be tested by the translation team. It's that simple. CVS or any external
upload (if finally carried out) is a kind of final stage for us, maybe
you don't realize.
Regards.
Peter Van der Beken
> be tested by the translation team. It's that simple.
I think that's not what Mike meant. Presumably you'll be able to a)
download a Firefox nightly, b) checkout your language files from CVS, c)
complete the localization using those files, d) JAR them up and e) drop
them into your Firefox nightly to test. At least that's how I understand
things. Step b, c and d can be done differently when using MT I think,
but the basic idea remains.
Peter
Zbigniew Braniecki
Yes. Of course that langpacks will be tested during creation locally,
but in your plan there is no spac for "those strange things that happens
quite often without any logical explanation". We cannot know what could
happen, but i'd like to see a test built made by this system a few days
before official release. Just to check and make sure "it's ok. works fine".
greetings
Zbigniew Braniecki
Tsahi Asher
english. at least in israel, there are relatively very few localized
programs, and most software people use, aside from windows/IE/MS-Office,
is in english. however, if we do intend to give users the option to use
a localized version, we might as well give them the means to use it.
Oscar Manuel Gómez Senovilla
Nope. Lang files are exclusive for their versions, so the files for a
previous version won't work in any later version. And for that, it's
necessary an english realease first. So, the cycle is: a) download the
build, b) Extract the files, c) Update the localization, d) JAR, e) with
the mentioned improvements and or self hacking, _try_ to make it work
(this is actually the failing point we're mostly stuck in) and going
back to c) whenever there's something to fix (it happens often, believe
me), f) Generate an xpi file, g) Test xpi, h) when the xpi works, give
to the community (included MF). That's the way I think it should work,
as we did in MEl10n.
There might be questions like "Why do you take the work to make xpi and
test it instead of leaving that task to MF?". It's simple: freedom and
quality. The spanish (and open source) community expects that from us,
and if any day we're removed such freedom, I'll give up and won't
collaborate anymore.
Regards.
Zbigniew Braniecki
> i can't agree with you that nobody will give firefox a try if it's in
> english. at least in israel, there are relatively very few localized
> programs, and most software people use, aside from windows/IE/MS-Office,
> is in english.
Remember that we're competing with IE. If IE _is_ in Hebrew, and Firefox
is not it starts from the loosy position.
In Poland almost everything is localized since we have very active group
of localizers and many proffesional translators use Open-source projects
as a training playgroud, and to be honest i'm not using any
not-localized application. Ok, one - Eclipse.
And as somebody mentioned. It's not a problem with people knowledge of
english. It's simple a matter that IE has localization, and Firefox has
extensions that i have to install, restart browser with some options in
cmd line and meaby it'll work.
Greetings
Zbigniew Braniecki
Peter Van der Beken
If this plan works out it could very well lead to localized nightlies of
the applications. MF might not have the resources to provide them but
someone else could donate the machines/time to do them. Having localized
nightlies will make quality control easier, especially if there's a
localization freeze before releases.
I don't know why you insist on having an xpi, having a localized
installer that installs the right localization from the start sounds
like a much better solution. Having one method of building those
localized installers will lead to better quality in the long run, it's
the reason why Mozilla Europe started working on the project to build
localized installers of the suite. You have been arguing to have
localizers be able to concentrate on one thing: translating, how can not
having to bother with building the xpi be a bad thing then?
If you want to produce your localized version of Firefox completely
independently from MF you can do so (even though you might not be able
to name it Firefox), but you shouldn't expect MF to spend resources on it.
Peter
Oscar Manuel Gómez Senovilla
>
> independently from MF you can do so (even though you might not be able
> to name it Firefox), but you shouldn't expect MF to spend resources on it.
I just want to keep producing builds and give them back to the community
the same way I've been producing them for long time, that's all. Since I
want to promote mozilla products among the spanish community, I try to
give them what they expect, and taking that mostly nobody wants english
interface and resources but spanish ones, we have our own sites (and
mirrors) for this. Of course, we always try to announce here what's
going on so MF can do what finds appropiate with the packages. I don't
demand from MF more than they consider necessary from promoting mozilla
products, but I do demand help when they take technical decissions that
force us to dedicate much more time than the necessary for doing the
work, what is bad for both.
Regards.
Javier SOLA
Thank you for all this work, it is necessary, but I would like to give
here the point of view of a simple translator in a remote country, which
does not always agree with what you have proposed.
The localization process, up to now, has been an off-line process.
Here in Cambodia, where bandwidth is an expensive commodity, we love to
work off-line.
We get hold of an XPI package, take it appart and turn it to PO files
with the Translate tools, translate it off-line, put it back together,
integrate it and test it.
As the Khmer scripts takes huge amounts of space, we do need a lot of
testing, which - with the present process - is more or less simple.
I don't know if somebody goes around translating nighlty builds, but we
are simple people and only give a try to stable releases... and stay
away from CVS... (unnecessary technitian's stuff to us). We want
langenus packages that can be translated, *to know what else needs to be
modified* (yes, a manual that we can print), and an easy way to put it
back together (such as a lovely IU control).
Once we have our stable localized version, we will be very happy to
share it with anybody who wants to put in that thing that you call
CVS... and would love to receive a localized installable package, but
otherwise we will be happy to distribute locally our localized pack.
And we do not need Polish or Hebrew... just Khmer and possibly
English... when you pay 14 cents for each megabyte... 10 megabytes more
amounts to about two or three beers.
Keeping things as they were, and writing a manual on how to build the
new language packs would be more than enough for us, it would put us
back to where we were with Thunderbird 0.5
The process of internationalization in theory tries to make localization
easy and independent from development, and Mozilla has got to a very
good internationalization point, much better than many other
applications. The language pack made us independent from all the word of
development... and - if I undertand correctly - you are pulling us back
into that world... and we (I can only speak for me and my team) don't
want it, it brings completely unnecessary complexity to our work... and
I believe is a step back in the internacionalization process.
Please let us not step back in the name of "better technology". Take a
close look at the present localization process, specially the part that
takes place outside of the Open Source technical world, and adapt
yourselves to this working process... it really works, and you don't
know if what you are trying to change will work or not.
The traditional warning comes back to my mind: if it ain't broken...
don't fix it.
I hate to disagree with the people who do all this work... but we just
want a good old XPI file (and the beers that we can buy with the
bandwitdth that we saved).
Javier Solá
Khmer Software Project.
Benjamin D. Smedberg wrote:
> Dear localizers:
>
> There have been many complaints on this newsgroup and elsewhere
> regarding the difficulty of localizing Firefox 0.9. I apologize for any
> lack of communication that made it more difficult to localize the
> Firefox release. It is true that features and bugfixes in the extension
> manager caused many other priorities to be dropped during the 0.9
> release cycle.
>
> Providing an ongoing and sustainable localization mechanism for the
> new-toolkit apps is one of our top priorities heading into Firefox 1.0.
> This message outlines the planned localization system:
>
> LOCALIZING THE MAIN FIREFOX/THUNDERBIRD APP:
>
> * All language-sepcific files will exist in CVS in centralized
> locations:
>
> toolkit/locale/ab-CD/...
> browser/locale/ab-CD/...
> mail/locale/ab-CD/...
>
> This includes files packaged as browser chrome, as well as
> miscellaneous other files such as installer scripts and
> profile defaults.
>
> This *includes* the en-US language files. I will be working on
> reorganizing the current English files into their new location over
> the next few days. I will send out an email when this process is
> complete, so that other languages can follow the pattern specified.
>
> * The en-US language will continue to be the "development" language.
> This means that when toolkit/browser developers make changes that
> require localization, they must commit changes to the en-US language.
> Other languages may update as often as necessary to stay current with
> the en-US directory structure.
>
> * Localizers who are comfortable using automated tools
> such as the Mozilla translator will still be able to use them. You can
> JAR the en-US directory, edit it using the Mozilla Translator, and
> un-JAR your results to commit into CVS.
>
> * Localization changes will not require review/superreview. Each
> language will have an owner, who may make changes as appropriate. If
> others wish to make changes, they must obtain the approval of that
> owner.
>
> If you wish to be owner of a localization, or wish to nominate someone
> else, please email me (bsme...@covad.net).
>
> mozilla.org will be responsible for producing official localized
> firefox/thunderbird builds.
>
> It is also possible, but shouldn't normally be necessary, to ship a
> firefox/thunderbird langpack as an extension. Firefox will not be
> providing locale-switching UI.
>
> LOCALIZING EXTENSIONS:
>
> Extension are localized differently than major apps. Every extension
> should ship at least one locale with its content package (I expect that
> would normally be English, but that is up to the extension developer).
> The extension *may* choose to ship multiple locales by default. Extra
> locale-packs for that extension will also be installed as extensions.
> (So you would install the "Foopy" extension which came with English;
> then you would also install "Foopy Deutche langpack").
>
> UPDATE.MOZILLA.ORG:
>
> update.mozilla.org will be gradually improved to offer more localization
> features. By firefox1.0, the auto-update feature will be locale-aware,
> at least for the main app (localization support for extensions will take
> some significant backend work in the chrome registry and extension
> manager, which may not be ready for Firefox 1.0).
>
> I welcome constructive comments on this localization plan; please post
> comment here at npm.l10n (I do not read mozillazine forums, please don't
> post comments for me there). I know that there have been disagreements
> with regard to putting localizations in the CVS tree, but Ben Goodger
> and I agree that this is the best solution for long-term management of
> the tree.
>
> Sincerely,
> Benjamin Smedberg
Hung-Te Lin
After reading the entire long thread, I have something to say..
(1) Maybe localization is not important in some countries but it IS
very important in others, especially in Asian. I'd bet that more
than 60% people in CJK (Chinese, Japanese, Korean) will stop
using Firefox if they can't find a localized one. You can't promote
this software in educational (what about elementary schools? they
still have to use the internet. tell them you must learn English
well first?) and many other places if it's in only English.
(2) I agree that locale is more like a theme than an extension. Actually,
maybe all what we need is just a duplication of entire theme control
system to manage locales.
It's rare to see one firefox installed with many locales. Usually
when someone installs a language pack, he wants it to be his new
default locale. This is seen in theme installer, a check box to
indicate that "this will be my new theme". Can we have this in
Firefox?
(3) Problems not mentioned in original proposal of this thead:
A. Currently we don't have locale 'fallback'.
When a user installs en-US extension with overlay referring to
standard locale resource in en-US.jar, firefox will get XUL error.
B. To overcome (a), the original en-US.jar must be installed and
registered for a localized build. But if a user installed an English
build of Firefox with a English profile created, then both
installing laguage pack or localized build will result in English
interface. What to do if we don't have a locale switching UI?
(4) Currently Mozilla is shipped in pure English while you can latter
go install a language pack. This really works fine. But it is not
enough for some people I mentioned in (1). That's why we have
"localized build" and ability to specify/change default locale.
Here I want to explain something. I know firefox team wants to keep
its branding. So firefox team does not want we localizers to "build
another build from source" because that may leads to some error like
crash or whatever. Yes. But currently "localized build" is just a
name. Most of us made localized build with official binary. We just
add our locale resources into the binary and then repackage it.
Although sometimes we may still cause XUL errors, but that's the
response of the one who didn't tested it. Maybe you can examine the
quality of localized build even kicking out a bad localizer but
please do not make Firefox unfriendly to non-English people just for
keeping branding. You'll lose the market.
In last IRC meeting I saw restrctions in localized builds/langpacks
and during discussion of this thread I see more and more.
It's mentioned again that "If you want to produce your localized
version of Firefox completely independently from MF you can do so
(even though you might not be able to name it Firefox)"
Most localizers tried hard to do their best to help people all over
the world using Firefox. But too much restrictions will only result
in a bad product. If we can't keep quality and giving people what
they want, at least I'll stop it. And I don't want to see Qute event
again.
Being the first one to make localized Phoenix builds, I hope that I
won't be the first one to stop localizing Firefox.
All the best,
--
Hung-Te Lin <Hun...@gmail.com> <pi...@csie.ntu.edu.tw>
Traditional Chinese Localization for Mozilla (zh-TW)
Zbigniew Braniecki
> In last IRC meeting I saw restrctions in localized builds/langpacks
> and during discussion of this thread I see more and more.
> It's mentioned again that "If you want to produce your localized
> version of Firefox completely independently from MF you can do so
> (even though you might not be able to name it Firefox)"
>
> Most localizers tried hard to do their best to help people all over
> the world using Firefox. But too much restrictions will only result
> in a bad product. If we can't keep quality and giving people what
> they want, at least I'll stop it. And I don't want to see Qute event
> again.
Totally agree with You. That's really very good that people from FX team
start planning Localization for firefox, but it simply can't base on
restrictions and it has to give ability o have result of our work as
good as we can make it now.
So for example if I wouldn't be able to localize MPL for Windows
installer (we of course add official MPL at the bottom and there is a
note that what you're reading is only a translation and has no law
power) or installer will start with "Extracting" it will be clear that
we're moving in bad direction.
With full support for Firefox i'm at the same point as Hung. If you wont
give us ability to produce best quality product, you will loose
localizers - not only Hung and me.
You must remember, that in this issue (localization) You simply can't
work like with other things - basing on "non-community driven project"
and just publicing Your decisions. You simply can't do that because
you're not making any of those localizations by yourself, and we are the
ones who make.
I'm looking forward for meeting Benjamin was talking about. I hope it
will clarify the situation.
x s
the discussions in this thread.
First thing, in multiple users systems you will have to install a
different FireFox build for each user? If they want to use different
locales and FireFox lacks the ability of Mozilla or OpenOffice to have
different locales, that will be the only way, and I don't know even if
it will be possible for several users to install on the same machine
different FireFox binaries. That applies to libraries, academic
institutions, internet cafes,...
Second, we (localizers) were asking for a simple method to include our
localizations into FireFox, because you have changed so much everything
that now we cannot produce .xpis or installables. I think that including
locales into CVS can be good to produce official localized builds, but
the ideas you are suggesting are kind of ... The advantage of xpis are
that you have one .xpi file for win32, unix and mac. I still don't see
the advantage of producing a 6MB binary for win32, another one for unix
and a third one for mac. Now I see why you are concerned about space in
servers and maybe traffic, the idea of not having the UI for switching
locales is not a smart one.
I hope you can think a little bit about this necessary feature.
Channy
> Dear localizers:
and Benjamin, etc...
This is Channy Yun, a korean l10n volunteer from Mozilla 0.9.
I have made localization versions since 2000. In my experience,
there are somethings to comment in this thread.
1. Must give a proper tools to translate.
Many localizaers are good at using Mozilla Translator.
I had to make a translation tools including perl sciript, encoding
library and databases in early. But, MT is very easy now.
If you want to offer something system (as like cvs), it must be
easier than MT.
2. Must give a stable and formal language pack (en-XX) in time.
There are many developement stage, alpha, beta, RC and releases.
Most localizaers have a l10n rols of several products. In my case,
Mozilla suite, firefox, thunderbird and many stage.
I cannot predict your correct release time. Sometimes you were
over in date of roadmap.
In your CVS system, this problem is still here.
3. Must give a correct region pack guide line.
There is no guideline to give a regional informations.
Startpage, search engine and help start page.
May localizaers have had a hard work to make a localization builds.
And there are many of testers about localized builds.
I suggest: (if above 3 things is possible,)
1.If someone want to use your (cvs) translation and build system,
you can allow to use it by them. But, you'd better enforce to use it.
2. You can get only ab-xx.jar files in your CVS from localizers in
time and make a stable versions.
You must bear in mind that "Transtation is not program but culture".
Consistent choosing of terms, expression and user's feedback...
These thing cannot be made by automatic system. Localization is
very hard and cultural works. So MF must help them carefully.
Thanks,
Channy
--------------------------------
Mozilla Korean Project
http://www.mozilla.or.kr
Ben Goodger
> Here in Cambodia, where bandwidth is an expensive commodity, we love to
> work off-line.
I think this might be a reasonable compromise:
- languages that want to be able to ship on relatively short notice and
get more eyeballs on a regular basis should be in CVS (Tier 1)
- languages that supplied only at major releases could continue to
localize the way they have been localized, by using the new packaging
instructions that I linked to in another post (
http://www.mozilla.org/projects/firefox/l10n/ ) (Tier 2)
Having at least *one* other language in CVS is IMO a good idea because
it allows us to easily test and debug problems that may only affect
other languages. It makes it more likely that Tier 2 language packs will
work since basic "language-other-than-en-US" bugs may be addressed sooner.
What we would like to encourage I think is that as many languages as
possible get into CVS (especially the top 5-10) so that we can take
advantage of the automated build and release system and have
synchronized international releases with very little effort. However,
for the smaller localizers in remote locations if using CVS is difficult
for you, you should still be able to use the old process, providing we
keep localization information documentation up to date. Alternatively,
you could find someone in another location who is more CVS savvy to
help. There are many possibilities.
-Ben
Javier SOLA
Thank you very much! This is exactly what we need. We will be testing it
soon.
Has anybody written anything about the structure of the new
XPI/config.ini and what needs to be localized? I will be happy to do it
if somebody can give me the info.
Javier
Marcelo Poli
spanish, but Windows (sorry for mention it) is manufactured in Mexico
and there are lots of people who doesn't change the local settings. And
some pre-installed Windows (again) come with MX locale.
In that case if MF choose the localization, my work is useless in a
great number of machines where mexican localization is used instead of
es-AR.
---
If you want to download the localization at install time, think of dial
up users that install programs that came on a magazine CD to minimize
conection time.
Even worst, if you download one copy and begin installing over a
network, you need to wait the download on every machine.
I always hated Netscape 6 (and it's one of the causes I hate IE) for the
little installer that downloads the rest of the files.
--
Zbigniew Braniecki
> Has anybody written anything about the structure of the new
> XPI/config.ini and what needs to be localized? I will be happy to do it
> if somebody can give me the info.
You can test ready to work XPI's made by other people - most of them are
mentioned on this newsgroup.
Zbigniew Braniecki
> What we would like to encourage I think is that as many languages as
> possible get into CVS (especially the top 5-10) so that we can take
> advantage of the automated build and release system and have
> synchronized international releases with very little effort. However,
> for the smaller localizers in remote locations if using CVS is difficult
> for you, you should still be able to use the old process, providing we
> keep localization information documentation up to date. Alternatively,
> you could find someone in another location who is more CVS savvy to
> help. There are many possibilities.
It's great! Are there any ETA for this CVS system so we could test it
asap and provide feedback?
Greetings
Zbigniew Braniecki
P.S. Why only 2 files are in contrib-localized for 0.9? Is this system
still in work? Shall we send here info about 0.9.1 and 0.7.1?
dynamis
========================================================================
Hi, all. I'm dynamis, a staff of Japanese localization team.
At first I apologize for posting this late.
I will write three things in this post. That will be:
1. What users need and what we should do.
2. What localization contributers need and what mozilla.org should do.
3. What we japanese localization team think/want.
1. What users need and what we should do.
As Ben said, average user just want to get a browser. And they want
a browser which is completly localized and as small size as possible.
Some have not enough network bandwidth, some hate english if it is only
first time, some need to use language different from OS...
General choices of multilanguage software are:
A: One build package with all languages.
B: Complete build packages for each locale.
C: English only and International package.
It's clear which choice is the best for users, especially for beginners.
They should want only their own language. I think this is very important
at the point of marketing too.
You may say that complete builds for each locale takes huge server space.
That's true but which is more important server costs or user demands?
In addition, I guess if you provide only build with all package, that
finally costs more. Build with all locales is twice or more(?) larger
than one with single locale, then all time when users download it costs
more bandwidth and total cost will be expensive isn't it?
# We thank always for your ftp server mirroring. ;)
2. What localization contributers need and what mozilla.org should do.
Including language resources into CVS may be natural decision to get
more flexible build environment. There are many possibilities.
But on the other hand, there are things to care about. You mozilla.org
should take account of localization costs. If you want localization
contributers to use cvs, you should show the advantage.
Faster build or automated build are advantage for you but not for
contributers. Fastest/easyest way of build is local build, automated
build can be also done in local machine. Bonsai is good tool but not the
best tool for get diff of language resources.
# we just use diff script or sometime we use diff output tool, lpdiff
# lpdiff: http://www.mozilla.gr.jp/jlp/lpdiff/
# lpdiff can load locale foler and output all diff into one/each html...
The only advantage I know now is saving communication cost: we'll need
not tell new version infomation manually with cvs.
Cost of cmmitting cvs is not so small. To keep motivation of
contributers, you should prepare some tools to save our cost.
Making complete tool greater than MozillaTranslator is not easy work and
in fact it may be impossible in regard of manpower.
But for example, you may be able to prepare auto CVS commiting script for
contributers who mainly work in locale machines.
It's very tired to commit to cvs though we already prepared complete
localized package in locale machine.
# We don't commit before the test.
If we can commit just running one script with xpi file, we can use it
but if we need to commit all files manually, we may going to do the task in
free time, not just after change/release.
Maybe you say that it's free we use cvs or keep old way. So, I don't
against start using cvs. Please keep in mind there are some localization
teams working without cvs and you must not make difficult to localize
without cvs.
3. What we japanese localization team think/want.
At last, I write about our position/opinion.
Many of Japanese localization team are against at cvs system. The reason
is it's additional cost without advantage. If you can reduce committing
cost and show concreat advantage of cvs, they agree with cvs. But at the
point of now, they aren't.
We respect user demand very much. In japan users espesically beginners
hate english. Users and developers want to make as small size as
possible. We need complete localized build without other locale.
So, if you make only build with all locale, we maybe prepare only ja-JP
build by ourselves. If then we have no reason of using cvs. :(
So far, there was not only one or two releases which have problem with
muiltibyte languages. We don't want to release non-stable products. We
always inform new localization package to you after test, not soon after
localize. We want to control if release localized build or not.
# Moz 1.6 breaks files attached to mail if it's path include multibyte.
# We decided not to release thunderbird 0.8/0.9 for MacOSX because of
# it's lack of stability.
When we can fix problem about multibyte languages will small workaround,
we want to include it and release fixed version.
That is...
+ we think users should want simple build
+ we need build with single locale
+ we need simple and easy system to localize
+ we need detailed manual about installer/localization
+ we need tools which help using cvs
+ we need concreat advantage of cvs for us
+ we maybe commit cvs only after release or without cvs
+ we want to take control of localized release
- I prefer locale change UI (personal opinion)
Thanks.
- dynamis <dyn...@skillup.jp>
Mozilla-gumi : http://www.mozilla.gr.jp/
Mozilla-gumi JLP: http://www.mozilla.gr.jp/jlp/
JLP Forum : http://moz.skillup.jp/jlp/
Mozilla-gumi JTP: http://www.mozilla.gr.jp/jt/
mozilla.org in J: http://jt.mozilla.gr.jp/
JTP Forum : http://moz.skillup.jp/jtp/
my personal site: http://skillup.jp/
Venkman-JP : http://skillup.jp/venkman/
KaiRo - Robert Kaiser
> different FireFox build for each user? If they want to use different
> locales and FireFox lacks the ability of Mozilla or OpenOffice to have
> different locales, that will be the only way, and I don't know even if
> it will be possible for several users to install on the same machine
> different FireFox binaries. That applies to libraries, academic
> institutions, internet cafes,...
Ah, those specialized uses are just a piece of shit to the Firefox team,
and we in L10n are just a load of waste of which they (or is it he?)
want to get rid of. At least it seams to me that way at times.
> Second, we (localizers) were asking for a simple method to include our
> localizations into FireFox, because you have changed so much everything
> that now we cannot produce .xpis or installables. I think that including
> locales into CVS can be good to produce official localized builds, but
> the ideas you are suggesting are kind of ... The advantage of xpis are
> that you have one .xpi file for win32, unix and mac. I still don't see
> the advantage of producing a 6MB binary for win32, another one for unix
> and a third one for mac. Now I see why you are concerned about space in
> servers and maybe traffic, the idea of not having the UI for switching
> locales is not a smart one.
Well, what comes out of this is that noone on Solaris, *BSD, OS/2 or
even Mac will have localized builds, as we can't afford to do binaries
for all those, and there are no installable XPI packs for them to apply.
But wait, I'm comparing a good product like Seamonkey, where this works
now the way it should, to that waste they call Firefox where it has
never worked for those awkward platforms that noone uses anyways.
That's what Oss is about, right? Making it difficult for those minorties
to achieve what they want. Right. Let's do it all for the masses and not
care about anyone else. And BTW, call us Microsoft. We're already acting
that way.
Just my 2c.
Robert Kaiser
SeaMonkey German localizer
KaiRo - Robert Kaiser
> more than what an all-locales firefox would look like, is paying a few
> megabytes for an application that works on all locales we support really
> that bad?
Considering that Seamonkey is a product which is much, much more than
"just a browser", and that your imagination of an all-locales Firefox
must have been messed up when writing this post (see further posts
here), it almost looks as you're not seriously speaking here.
I know you better than to really believe your being unserious, so I'm
really getting intersted of the plot that is behind all that. Sometimes
the new Aviary team decisions look much less understandable to outsiders
than those made by Netscape martekting years ago...
Robert Kaiser
KaiRo - Robert Kaiser
Absolutely true. I know that opinion is more widespread in
mozilla-europe than in mozilla.org, and I'd like to thank you for that.
But I never saw any developer caring about if his changes that might
affect L10n, sometimes even quite a lot, might eventually even break MT
or similar tools. Frankly I never heard of a developer asking if it did.
And lots of changes happened that broke especially MT.
Robert Kaiser
KaiRo - Robert Kaiser
> you like!). Commit. Done.
And have no comfort of any good tools whatsoever. Thanks, if it's that
way, I'd rather think to do my own project and never commit to CVS than
do it that way.
But, as I do only localize that trash of Seamonkey, it looks as my work
is doomed anyways, so why should I care anyhow?
Robert Kaiser