From 50 to 100 locales

classic Classic list List threaded Threaded
141 messages Options
1234 ... 8
Reply | Threaded
Open this post in threaded view
|

From 50 to 100 locales

Axel Hecht-2
Hi all,

we'd like to collect some data and idea on how to get from the 50
locales and releasing 40 to a hundred.

Clearly, everybody feels the load of releasing a Mozilla product in 40
languages, and while we got the job done, it's about time to look ahead
and point at the places where going further leads to trouble.

So to start the discussion, it'd be a good idea to collect how much one
locale of the 40 currently 'costs'. How much time is spent on a locale
day-to-day (tinderbox build times come to mind), and how much man power
and computing resources do we need for a release? How much for an
update, how much for a major new release? I would hope to get
guestimates or number from folks like localizers, drivers, build, QA, BD
and product.

In parallel, we should collect ideas on how to make l10n easier, and
improve the quality over all. I have some, but I'll keep those for a
follow up.

This discussion should include options on the goal and expectations to
be set on the beast at large, too.

Axel
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: From 50 to 100 locales

Cédric Corazza
Axel Hecht a écrit :
> Hi all,
>
> we'd like to collect some data and idea on how to get from the 50
> locales and releasing 40 to a hundred.

Ambitious goal :)

> So to start the discussion, it'd be a good idea to collect how much one
> locale of the 40 currently 'costs'. How much time is spent on a locale
> day-to-day (tinderbox build times come to mind), and how much man power
> and computing resources do we need for a release? How much for an
> update, how much for a major new release? I would hope to get
> guestimates or number from folks like localizers, drivers, build, QA, BD
> and product.

 From a localizer point of view:
Minor releases don't impact us as this is only about stability and
security matters, not localized strings.
 From a day-to-day point of view (I guess you are only talking about
Firefox), I would say it's a matter of 30 mn a day: watching for new
check-ins, comments from our community, ... Well, this is an average
time, on cruise time (I mean not just before or after a major release),
the spent time can be twice or thrice more before a release, especially
when watching [hidden email]; because watching your address can help
to avoid to other locales to experience the same problems as other ones.

> In parallel, we should collect ideas on how to make l10n easier, and
> improve the quality over all. I have some, but I'll keep those for a
> follow up.
No idea

> This discussion should include options on the goal and expectations to
> be set on the beast at large, too.

Yes, most of us handle several products translation

Regards
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: From 50 to 100 locales

Channy Yun-2
In reply to this post by Axel Hecht-2
On 11/3/06, Axel Hecht <[hidden email]> wrote:
> Hi all,
>
> we'd like to collect some data and idea on how to get from the 50
> locales and releasing 40 to a hundred.

Good! Cause we're world based software.

> So to start the discussion, it'd be a good idea to collect how much one
> locale of the 40 currently 'costs'. How much time is spent on a locale
> day-to-day (tinderbox build times come to mind), and how much man power
> and computing resources do we need for a release? How much for an
> update, how much for a major new release? I would hope to get
> guestimates or number from folks like localizers, drivers, build, QA, BD
> and product.

I have 30min.~one hour per day to follow up check-in. But, I must
confirm tinberbox builds after doing. It takes about half hour. Also I
need to read l10n mailing list and follow up bug related to my locale.
I cannot do them everyday, so my peer helps me and I share jobs with
him per a week.

In fact, string changes is not a problem. Not to fix strings to end is
real problem. It impact help files. If I miss it after BETA period, it
takes more times to make a bug and follow-up it as you know. I guess
most of translators is not a code developer, maybe it's not good at
that proccess.

> In parallel, we should collect ideas on how to make l10n easier, and
> improve the quality over all. I have some, but I'll keep those for a
> follow up.

My suggestion is to divide two locale groups. One is groups that have
an afford to follow-up process. The other is not to do that. For them,
we offers en-US locale files to be translated and the guideline and
deadline to them after major release. If locale files are submmited,
files make automatic converting to cvs and goes to release
periodcally. (In case of IE7, other locale will be released after
several week except major languages.) It will be helpful to novice
translators for Mozilla products. They will cost much time to be good
at all proccess.

After major release, there is almost no thing to do for tier-1
localizers including me. So they help such tier-2 localizers.

Channy
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: From 50 to 100 locales

jneves
In reply to this post by Axel Hecht-2
Qui, 2006-11-02 às 17:36 +0100, Axel Hecht escreveu:
> So to start the discussion, it'd be a good idea to collect how much one
> locale of the 40 currently 'costs'. How much time is spent on a locale
> day-to-day (tinderbox build times come to mind), and how much man power
> and computing resources do we need for a release? How much for an
> update, how much for a major new release? I would hope to get
> guestimates or number from folks like localizers, drivers, build, QA, BD
> and product.
>
I'll get back to you on this. I want to check with a couple of people
just to get you better numbers.

> In parallel, we should collect ideas on how to make l10n easier, and
> improve the quality over all. I have some, but I'll keep those for a
> follow up.

Here's my wishlist:

1) If you want to go from 40 to 100 locales, more attention must be paid
to registration bugs. For a localizer, waiting for a registration bug to
get through is painful: you've already done a ton of work to get that
localization going, and then everything suddenly stops for weeks. 60
more locales will mean something like 180 such bugs (thinking only of
Firefox, Thunderbird and Calendar). If you're heading a team, the team
loses interest.

2) Simplify localization (a "localization package" is the set of files
that should be localized):

  a) There should be a en-US localization package that would serve as
the basis for a localization.

  b) Localization packages should be localizable: no fixed content that
isn't supposed to be translated because of trademarks or MoCo agreements
or any other issue. No control keys, if they really are supposed to be
standard throughout all versions (there was some discussion against
this). These localizations that shouldn't happen were the most difficult
to learn, communicate and resulted in a lot of repeated checking on my
part before commiting.

  c) Separate "content packs" that need a separate authorization process
(searchplugins, region.properties changes, feeds, feed readers).

  d) Use a single format. Right now we three argument formats like:
&brandShortName; on DTDs, %s on properties, $Version$ in installer.inc.
The same applies to newlines and access keys. This is a barrier to entry
and makes the localization job a lot harder, because you need always to
remember where you are to check if a change. One possibility would be to
generate the "real" localization from localization packages.

  e) Separate interface issues (window sizing) from the flow of
localization. I don't know how many times I had to un-translate width
and height.

3) Keep a schedule updated and only one. For Firefox 2.0 I was told to
follow a ics file. Then the file changed and I didn't know (I was
following the old one). then it was the schedule at Planet Mozilla. Even
so, that was just a schedule for Firefox. There should be somewhere
where a localization team can go to know the answer to questions like:
how much time do we have? what's the next product to be release? when is
the string freeze? These questions are critical to answer: where should
we work? With 5/6 people per locale, this means 500/600 asking these
questions... And keep the schedule updated. Any change or delay should
be there first. To deal with the current situation we tend to not
believe dates and delay starting working on something (if you recall,
freezes haven't happened on schedule except for RC2/RC3 - with work done
in the first few days being wasted).

I think this is all of it.

Best regards,
                                                João Miguel Neves

_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n

signature.asc (198 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: From 50 to 100 locales

Ahmet Serkan Tıratacı-2
In reply to this post by Axel Hecht-2
Axel Hecht yazmış:

> In parallel, we should collect ideas on how to make l10n easier, and
> improve the quality over all. I have some, but I'll keep those for a
> follow up.

A few suggestions:

- Remove help from Firefox, make it online. (I know this issue is open
to discussion for a long time.) Maybe wiki based. This would make it
easier for anyone to contribute and ease localisers' pain. Currently,
only a few locales have up-to-date help. It's too hard to syncronise
en-US help with another locale, especially for small l10n groups, as
there are plently of late-l10n changes and difference between two
milestones is BIG.

- Make dates clearer and try not to change them unless there's a major
reason.

- A l10n blog or more effective use of wiki.mozilla.org might help us to
follow dates, updates and so forth.

- Devote more people from MoCo for l10n litmus testing.

That's all for the moment.

Serkan

--
------------------------
Mozilla Türkiye
http://mozilla.org.tr
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: From 50 to 100 locales

victory-4
#I have no relation to any of l10n teams, though ;-)

I think now it's hard to start to do l10n work.

People must find which file in l10n repos correspond to which file in
main repos because the structure has some difference.

The procedure to create language package is too complex,
so people needs to read many many pages.

so I believe you're forcing them to waste their precious time to do it :-)

--
victory
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: From 50 to 100 locales

Novica Nakov
In reply to this post by Axel Hecht-2

> we'd like to collect some data and idea on how to get from the 50
> locales and releasing 40 to a hundred.

Well, it might be better to ask the l10n groups on other (major) FLOSS
projects. They already have more than 40 locales.

http://l10n.kde.org/teams-list.php - around 110
http://developer.gnome.org/projects/gtp/teams.html - around 125
http://projects.openoffice.org/native-lang.html#star - around 70.

> So to start the discussion, it'd be a good idea to collect how much one
> locale of the 40 currently 'costs'.

It costs a lot I think and since we are creating an official product of
the Mozilla Corporation, maybe we should start asking for a fee.

> In parallel, we should collect ideas on how to make l10n easier,

This is an easy one. Provide official POT files.


--
Novica
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: From 50 to 100 locales

Ognyan Kulev
Novica Nakov wrote:
>> In parallel, we should collect ideas on how to make l10n easier,
>
> This is an easy one. Provide official POT files.

I would stress on the same thing. It's great that MT is actively
developed, but IMHO it's a waste of time and energy to rewrite already
great PO editors like KBabel or Emacs+gettext.el. Some parts of the l10n
are a bit weird but they can be solved - like multi-line entry for
search engine list (.1, .2, ...) and http://po4a.alioth.debian.org/ for
XHTML files.  Please provide familiar and all-loved framework (SCM+PO)
for translating. Debian-installer l10n, led by Christian Perrier, is an
excellent example for success in providing very comfortable "atmosphere"
for translating.

Regards,
ogi
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: From 50 to 100 locales

Ognyan Kulev
Ognyan Kulev wrote:
> Debian-installer l10n, led by Christian Perrier, is an
> excellent example for success in providing very comfortable "atmosphere"
> for translating.

Interesting pages in this regard are
http://d-i.alioth.debian.org/l10n-stats/translation-status.html and
http://d-i.alioth.debian.org/i18n-doc/

Regards,
ogi
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: From 50 to 100 locales

Robert Kaiser
In reply to this post by Novica Nakov
Ognyan Kulev schrieb:
> Please provide familiar and all-loved framework (SCM+PO)
> for translating.

Who says that everyone loves that framework? In fact, I know multiple
people (including myself) that hate it and would always prefer the
current Mozilla model to it if they could choose.

Robert Kaiser
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: From 50 to 100 locales

Ricardo Palomares Martí­nez
In reply to this post by Novica Nakov
Ognyan Kulev escribió:
> Novica Nakov wrote:
>>> In parallel, we should collect ideas on how to make l10n easier,
>>
>> This is an easy one. Provide official POT files.
>
> I would stress on the same thing. It's great that MT is actively
> developed, but IMHO it's a waste of time and energy to rewrite already
> great PO editors like KBabel or Emacs+gettext.el. (...)


What many of PO fans don't seem to acknowledge (I've had this same
discussion with some es-ES team members) is that PO is NOT *the*
standard; in fact, I don't think that there is such thing as a l10n
standard. Why PO is better than XUL model? Why is it better than just
Java Properties i18n model?

I'm pretty sure most localizers will agree to switch to a single tool
when either a single standard appears and get really "the single" one
used, or that tool will able to nicely deal with _any_ l10n file
format without needing a conversion process.

OTOH, AFAIK there is nothing to prevent you from using PO files to
translate Mozilla products. Translate toolkit is honoured as a great
solution by many people here, so you should give it a try.

What I'm sure about is that if [your favourite PO l10n tool] can't
manage Mozilla i18n model, is not Mozilla the one to switch to PO: we
need a i18n model neutral l10n tool, or if that's not possible, one
that works with Mozilla i18n model.

Ricardo.

--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: From 50 to 100 locales

Erdal Ronahi
> What many of PO fans don't seem to acknowledge (I've had this same
> discussion with some es-ES team members) is that PO is NOT *the*
> standard; in fact, I don't think that there is such thing as a l10n
> standard. Why PO is better than XUL model? Why is it better than just
> Java Properties i18n model?

Depends on how you define a standard. Noone said PO is *better* than
XUL model, but from a translator's point of view it's standard,
because it's much more widespread.

I am heading a team that translates a complete Linux roundup including
GNOME, KDE, XFCE and other applications. 98% use PO. Only the Mozilla
products and OpenOffice.org are different.

There sure is a reason that the translation-toolkit provides moz2po,
ooo2po and vice versa and not, say, "mozilla to openoffice" or
"mozilla to Java Properties".

All the team knows how to handle PO files, but for a different model
like mozilla one has to learn a few things from scratch. That has
nothing to do with "PO is *better*". It is just more familiar because
there are hundreds of applications in the Linux world using PO.

Regards,
Erdal
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: From 50 to 100 locales

Axel Hecht
In reply to this post by Ricardo Palomares Martí­nez
Erdal Ronahi wrote:

>> What many of PO fans don't seem to acknowledge (I've had this same
>> discussion with some es-ES team members) is that PO is NOT *the*
>> standard; in fact, I don't think that there is such thing as a l10n
>> standard. Why PO is better than XUL model? Why is it better than just
>> Java Properties i18n model?
>
> Depends on how you define a standard. Noone said PO is *better* than
> XUL model, but from a translator's point of view it's standard,
> because it's much more widespread.
>
> I am heading a team that translates a complete Linux roundup including
> GNOME, KDE, XFCE and other applications. 98% use PO. Only the Mozilla
> products and OpenOffice.org are different.
>
> There sure is a reason that the translation-toolkit provides moz2po,
> ooo2po and vice versa and not, say, "mozilla to openoffice" or
> "mozilla to Java Properties".
>
> All the team knows how to handle PO files, but for a different model
> like mozilla one has to learn a few things from scratch. That has
> nothing to do with "PO is *better*". It is just more familiar because
> there are hundreds of applications in the Linux world using PO.

I think it's fair to acknowledge that people localizing Mozilla
applications have quite a few new things to learn, independent of the
actual file format.
And I'm pretty confident that we want it to stay that way, there are
just a few things to an successful web-faced application that don't go
straight out of the box. Quite a few product decisions need compromises
that should be somewhat equivalent across locales, and those need a
significant amount of communication back and forth.

In addition, I'm not sure that the translate toolkit is currently
bugfree or at least pitfall-free.

And you may insert my standard rant about l10n tools supposed to be good
editors. Think source format preserving, being RCS-friendly etc.

Axel
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: From 50 to 100 locales

jneves
Seg, 2006-11-13 às 20:20 -0800, Axel Hecht escreveu:
> I think it's fair to acknowledge that people localizing Mozilla
> applications have quite a few new things to learn, independent of the
> actual file format.

Agreed. But there are a lot of unneeded details that need to be learned.
Those are the problems that should be solved. Making it easy doesn't
mean making it stupid. It means avoiding errors by design. Different
file formats is just one of issues.

> And I'm pretty confident that we want it to stay that way, there are
> just a few things to an successful web-faced application that don't go
> straight out of the box. Quite a few product decisions need compromises
> that should be somewhat equivalent across locales, and those need a
> significant amount of communication back and forth.
>
> In addition, I'm not sure that the translate toolkit is currently
> bugfree or at least pitfall-free.

It isn't. Worst, it can't be bugfree or pitfall-free. For the simple
reason that mozilla file-formats are: 1) not documented and 2)
ever-changing. They tried to use the same code for Firefox 2.0 and 1.5
for instance, until they realised the encoding differences and other
details. My experience is that their support is great. Usually you get a
bug fixed in minutes or hours if you go through their irc channel.

As far as I've noted so far, there 4 different file formats for mozilla
(dtd, general properties, shellservice.properties and installation
properties). These differ in argument formats for strings, formatting
rules and in the case of the installer, encoding. You'll know that the
translate-toolkit is more pitfall-free the day they have special code
for each of the file formats.

Mozilla localization doesn't seem to me like a localization. It feels
more like a part part of the interface was taken from the project, given
to localizers and said: translate this. One of my biggest difficulties
is all the filtering needed on top of documenting to my team. But I've
said this before and pointed out what I'd like to see done. So no point
repeating.

Best regards,
                                                João Miguel Neves

_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n

signature.asc (198 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: From 50 to 100 locales

Marek Stępień-3
In reply to this post by Axel Hecht
João Miguel Neves napisał:
> It isn't. Worst, it can't be bugfree or pitfall-free. For the simple
> reason that mozilla file-formats are: 1) not documented

The standard SGML/XML DTD is documented, so are the Java *.properties
files (the only difference between Java and Mozilla properties is that
we allow unescaped Unicode characters).

> As far as I've noted so far, there 4 different file formats for mozilla
> (dtd, general properties, shellservice.properties and installation
> properties). These differ in argument formats for strings,

This applies to .po files as well, the argument formats are different
depending on the language the program was written in. For example, while
localizing Novell's gnome-patch.po for SLED 10 I found many different
formats (from C/C++, C#, Perl etc.).

> formatting rules and in the case of the installer, encoding.

NSIS installer.properties use UTF-8, just like any other .properties file.

--
Marek Stępień <[hidden email]>
AviaryPL - polski zespół lokalizacyjny Mozilli
http://www.firefox.pl/ | http://www.mozilla.org.pl/
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: From 50 to 100 locales

jneves
Ter, 2006-11-14 às 14:17 +0100, Marek Stępień escreveu:
> João Miguel Neves napisał:
> > It isn't. Worst, it can't be bugfree or pitfall-free. For the simple
> > reason that mozilla file-formats are: 1) not documented
>
> The standard SGML/XML DTD is documented, so are the Java *.properties
> files (the only difference between Java and Mozilla properties is that
> we allow unescaped Unicode characters).

Both those are just the base formats, not the localization formats. If
you just use that, you lose critical information, like "don't translate"
comments or the meaning of the arguments. You also lose all the
conventions for accelerators (.key vs .accesskey vs .commandKey). This
information is critical to create a working conversion of a
localization.

> > As far as I've noted so far, there 4 different file formats for mozilla
> > (dtd, general properties, shellservice.properties and installation
> > properties). These differ in argument formats for strings,
>
> This applies to .po files as well, the argument formats are different
> depending on the language the program was written in. For example, while
> localizing Novell's gnome-patch.po for SLED 10 I found many different
> formats (from C/C++, C#, Perl etc.).
>
Correct, po doesn't solve it. And I never claimed it did (I'm pointing
out problems with the current state of the localization, I'm not
defending that po will solve all the problems - you'll notice that I
haven't even refered to po in my initial participation on this thread).

I just wonder why firefox, using 2 languages (XUL for the interface,
that uses the DTDs) and C++ (if this is wrong, please correct - I don't
remember what the language is), has to have different types of
arguments.

> > formatting rules and in the case of the installer, encoding.
>
> NSIS installer.properties use UTF-8, just like any other .properties file.
>
I was refering to: toolkit/installer/windows/install.it, not
installer.properties.

Still in CP1252, and AFAIK, is going to remain that way. This is the
only example, but it's the fact that we have these little differences
that I'm complaining about. Converting from UTF-8 to CP1252 on the build
isn't that hard, and would mean that localizers only have an encoding to
work with. Some conversions would fail, it's true. At the moment the
builds fail if you have this file's encoding wrong, so it would not make
that much of a difference.

I just want the work to be simplified. People can deal with incredible
amounts of complexity. But they work better with the complexity taken
away. And this thread is about getting more people to do the work
without getting Axel in a sanatorium, right?

Simplifying the little things I pointed out in

http://groups.google.com/group/mozilla.dev.l10n/browse_thread/thread/5c6d1913b319c6c9/51ff133d45e4a494?lnk=raot#44bf50f7f9260793

means:
 * Less documentation needed.
 * Less questions to get a localization up to speed.
 * Less bugs in the localizations.

It won't make the localization something doable by a five year-old. It
won't make someone who says "I'd like to translate Camino to elvish",
able to do it in 5 minutes. But it will avoid work for those integrating
the work. It will avoid bugs that took hours of our time just to
identify (and I've seen I bunch of them in the work done by my team and
some of them were even corrected by others in this list - my sincere
thanks).

Best regards,
                                                João Miguel Neves

_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n

signature.asc (198 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: From 50 to 100 locales

Novica Nakov
In reply to this post by Axel Hecht
> I think it's fair to acknowledge that people localizing Mozilla
> applications have quite a few new things to learn, independent of the
> actual file format.


We can acknowledge that - no problem. However you are asking (or the
topic is) hot to get from 50 to 100 locales. So, really how do you do that?

Have you ever considered why GNOME has 3 times more locales then Firefox?

1. GNOME is an older project. Can this be a good explanation? Maybe, to
some extent. But Firefox has much bigger user base, it makes sense to
have it localized no matter of the operating system one uses. And
Firefox has just a handful of strings compared to GNOME.

2. GNOME uses gettext. Can this be a good explanation? Maybe. But it's
more important to note that GNOME provides a tool to localize things.
The tool (it's called GTranslator I think) is part of the GNOME project.
  And since Ubuntu (and Rosetta), all the translator needs to know is
how to click on a web page and fill in empty fields (so, she/he doesn't
have to know how to work with gettext at all). I would say that this
projects have l10n up in their priorities list. Where is Firefox?
Mozilla doesn't use gettext, so people can't use existing localization
tools. Mozilla doesn't provide other official tools for doing the job.
And, AFAIK, Mozilla doesn't help the development of other
Mozilla-specific tools such as MT. Moreover localizers should learn CVS
and follow way to many mozilla web pages with different info and... Huh,
if I feel like contributing to FLOSS, I'll probably choose Ubuntu.


3. Contributing to GNOME gives much more satisfaction than contributing
to Mozilla. Can this be a good explanation? Maybe. GNOME doesn't wave
the corporate flag and volunteers doing l10n work feel much more at
home. Mozilla is quite a different story. And after all, no one is
contributing localization to the Microsoft Corporation web browser, and
even if it is possible I would bet that no one will.


I could probably add few more but I think this gives the general picture.

Now a true story:
I'm doing l10n work on mozilla stuff for quite some time now, and I'm
getting a bit tired and I don't really have as much time as I used to.
So, I decided to ask some people to step in and replace me. And I'm
talking to this guy - an experienced Linux user, familiar with l10n
stuff, and with cvs and all the other things one must know to do this
job and he understands everything I tell him. His answer? - No way I'm
doing this.
And I'm still doing it because I don't want to see my past efforts go to
waste - but sooner or later I will have to call it a day (like I said I
don't have as much time as I used to), and than probably no one will
replace me. At the same time the GNOME l10n team has changed leaders and
few more people joined in and they are working at full speed.


So, you want to get to 100 locales? Maybe gettext can help, but it is
not mandatory right? I mean, what the hell, .pot, .properties, .java or
.whatever. Who cares? Rosetta users don't. Why should mozilla
translators do? If you want more locales you should make people feel at
home. Provide tools, help them, make things easier, send T-shirts, give
them honorary positions, put more effort in the whole process.

Or, simple, pay people to do it and tell them to shut up and use notepad
for translating.


--
Novica
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: From 50 to 100 locales

Marek Stępień-3
In reply to this post by Marek Stępień-3
João Miguel Neves napisał:
> Both those are just the base formats, not the localization formats. If
> you just use that, you lose critical information, like "don't translate"
> comments or the meaning of the arguments.

Right.

> I just wonder why firefox, using 2 languages (XUL for the interface,
> that uses the DTDs) and C++ (if this is wrong, please correct - I don't
> remember what the language is), has to have different types of
> arguments.

It's not only C++, it's also JS. Also, some parts, like the installer
files, are actually not for Mozilla, but for different software that
needs to be bundled, like the NSIS installer.


>>> formatting rules and in the case of the installer, encoding.
>> NSIS installer.properties use UTF-8, just like any other .properties file.
> I was refering to: toolkit/installer/windows/install.it, not
> installer.properties.

This file is from the old installer, which was replaced with NSIS
for Fx/Tb 2. I don't know why this wasn't removed from CVS, but nobody
needs to translate this file anymore. (Though it needs to be present,
so that the build doesn't fail)

You're right on shellservice.properties, though. The reason for using
"&" for accesskeys is that those strings are used for some native
Windows stuff, and not for XUL. These 2 *Label strings actually show up
in Windows dialogs, not in Firefox itself. (Though it should be possible
to break those two strings into the .label and .accesskey one, and
generate the Windows-friendly ones during build time or even runtime).

> means:
>  * Less documentation needed.
>  * Less questions to get a localization up to speed.
>  * Less bugs in the localizations.
>
> It won't make the localization something doable by a five year-old. It
> won't make someone who says "I'd like to translate Camino to elvish",
> able to do it in 5 minutes.

Camino is a different thing. Since it's a native app, and not a
XUL-based one, it uses the standard Mac OS X localization techniques
(for the most part of the app, at least). So, most of the things you
talk here about actually don't apply to this browser. :)

--
Marek Stępień <[hidden email]>
AviaryPL - polski zespół lokalizacyjny Mozilli
http://www.firefox.pl/ | http://www.mozilla.org.pl/
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: From 50 to 100 locales

Filip Miletic-4
In reply to this post by Ricardo Palomares Martí­nez
Ricardo Palomares Martinez wrote:
> standard. Why PO is better than XUL model? Why is it better than just
> Java Properties i18n model?
> [...] What I'm sure about is that if [your favourite PO l10n tool] can't
> manage Mozilla i18n model, is not Mozilla the one to switch to PO: we

My 0.02$ --- right now, PO handles issues like multiple plurals and
declinations, arising with some 'exotic' languages.  As far as I can
see, XUL does not; . I guess if you don't happen to need a l10n for such
a language, you don't get to appreciate the difference.  I am interested
in such a language though, so this PO feature is for me a significant plus.

f
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: From 50 to 100 locales

Robert Kaiser
Filip Miletic schrieb:
> My 0.02$ --- right now, PO handles issues like multiple plurals and
> declinations, arising with some 'exotic' languages.

No. gettext does to some extent. PO is just a file format, and it
doesn't handle that stuff by itself. The tools/code that apply and
integrate the localized content into the app need to support it. So
using PO format in Mozilla or converting Mozilla L10n files to PO format
doesn't help anything. And supporting such stuff inside XML (XUL) is
quite hard to do. In the JS/C/C++ code where we use stringbundles
(.properties files) that might be easier and doable, but where we're
using .dtd (i.e. in XML files) I don't see how it can be done easily.

So it's no question of the file format, it's a question of integrating
the L10n files into the code.

Robert Kaiser
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
1234 ... 8