Re: Internationalization: best practices?

sadie wrote:
>
>
> Landei wrote:
>>
>> By the way, I hate having different files which get soon out of sync, so
>> I wrote my own resource bundle class
>>
>
> The reason for bundles to be separated into different files for each
> language/target is so to make it extensible - so for example, a new
> language can be supported just by adding a file to the already-compiled
> program. It's not so relevant for a small, fast-moving program or web app,
> but makes a lot of sense in the old, slow industries that spawned it.
>
> You could get the best of both worlds, though. How about making your
> resource bundle default to the old method if the requested language isn't
> in its xml list?
>

I understand that my XML solution is only good for smaller apps. But I think
is makes no big difference if you add another file or edit an existing one.
However, my real question was how to *use* resource bundles in Scala without
too much friction.

I had recently the idea is to (ab-)use Symbol literals and implicit
conversions, so I can write
new JLabel('helloWorld)
--> Hallo Welt //if you are German
--> konnichi ha, sekai //if you are Japanese
If this works as expected, and nobody tells me that it's seriously
misguided, I'll go for it. I probably won't get it shorter.

Take care!
Daniel

The advantage of sepeate files is that it is easier to "outsource" the translation work. You just give a bunch of people the original (let's say English) file and each translates it into their own language. They might take different amounts of time, they might need several revisions and new languages might get added in the future. If you have a dozen or more languages your language resource file is going to take a LOT of effort to maintain.

If it was code and you could give each of your translators access to your code repository and do merges of changes it would probably work, but from experience I can say that many people who offer to do translations (for FLOSS projects) or do translations for a living have little technical background so it is likely that you will have to do the work of merging translations, typos, style and grammar fixes etc. Also from experience I can say that the first version of a translation into a language is almost never the last ;)

So knowing that I can tell you it's definitely easier if you can just copy a new language resource file to a directory and let the app handle it automatically. In code there is hardly any difference but it will make your life a lot easier.

But that just IMHO :)

On Sun, Dec 21, 2008 at 20:13, Landei <Daniel.Gronau@gmx.de> wrote:

sadie wrote:
>
>
> Landei wrote:
>>
>> By the way, I hate having different files which get soon out of sync, so
>> I wrote my own resource bundle class
>>
>
> The reason for bundles to be separated into different files for each
> language/target is so to make it extensible - so for example, a new
> language can be supported just by adding a file to the already-compiled
> program. It's not so relevant for a small, fast-moving program or web app,
> but makes a lot of sense in the old, slow industries that spawned it.
>
> You could get the best of both worlds, though. How about making your
> resource bundle default to the old method if the requested language isn't
> in its xml list?
>

I understand that my XML solution is only good for smaller apps. But I think
is makes no big difference if you add another file or edit an existing one.
However, my real question was how to *use* resource bundles in Scala without
too much friction.

I had recently the idea is to (ab-)use Symbol literals and implicit
conversions, so I can write
new JLabel('helloWorld)
--> Hallo Welt    //if you are German
--> konnichi ha, sekai    //if you are Japanese
If this works as expected, and nobody tells me that it's seriously
misguided, I'll go for it. I probably won't get it shorter.

Take care!
Daniel

--
View this message in context: http://www.nabble.com/Internationalization%3A-best-practices--tp20991566p21118127.html
Sent from the Scala - User mailing list archive at Nabble.com.

On 12/22/08, Tako Schotanus wrote:
> The advantage of sepeate files is that it is easier to "outsource" the
> translation work. You just give a bunch of people the original (let's say
> English) file and each translates it into their own language. They might
> take different amounts of time, they might need several revisions and new
> languages might get added in the future. If you have a dozen or more
> languages your language resource file is going to take a LOT of effort to
> maintain.
>
> If it was code and you could give each of your translators access to your
> code repository and do merges of changes it would probably work, but from
> experience I can say that many people who offer to do translations (for
> FLOSS projects) or do translations for a living have little technical
> background so it is likely that you will have to do the work of merging
> translations, typos, style and grammar fixes etc. Also from experience I can
> say that the first version of a translation into a language is almost never
> the last ;)
>
> So knowing that I can tell you it's definitely easier if you can just copy a
> new language resource file to a directory and let the app handle it
> automatically. In code there is hardly any difference but it will make your
> life a lot easier.
>
> But that just IMHO :)

mine also, it was my understanding that this was best practice for the
reasons of easier and more flexible management of the translations
themselves. Also adding new "language packs" does not require a
complete redeploy of the localisation files.

>
> On Sun, Dec 21, 2008 at 20:13, Landei wrote:
> >
> >
> >
> >
> > sadie wrote:
> > >
> > >
> > > Landei wrote:
> > >>
> > >> By the way, I hate having different files which get soon out of sync,
> so
> > >> I wrote my own resource bundle class
> > >>
> > >
> > > The reason for bundles to be separated into different files for each
> > > language/target is so to make it extensible - so for example, a new
> > > language can be supported just by adding a file to the already-compiled
> > > program. It's not so relevant for a small, fast-moving program or web
> app,
> > > but makes a lot of sense in the old, slow industries that spawned it.
> > >
> > > You could get the best of both worlds, though. How about making your
> > > resource bundle default to the old method if the requested language
> isn't
> > > in its xml list?
> > >
> >
> > I understand that my XML solution is only good for smaller apps. But I
> think
> > is makes no big difference if you add another file or edit an existing
> one.
> > However, my real question was how to *use* resource bundles in Scala
> without
> > too much friction.
> >
> > I had recently the idea is to (ab-)use Symbol literals and implicit
> > conversions, so I can write
> > new JLabel('helloWorld)
> > --> Hallo Welt //if you are German
> > --> konnichi ha, sekai //if you are Japanese
> > If this works as expected, and nobody tells me that it's seriously
> > misguided, I'll go for it. I probably won't get it shorter.
> >
> > Take care!
> > Daniel
> >
> > --
> > View this message in context:
> http://www.nabble.com/Internationalization%3A-best-practices--tp20991566...
> >
> >
> >
> > Sent from the Scala - User mailing list archive at Nabble.com.
> >
> >
>
>

On 12/21/08, Landei wrote:

> I had recently the idea is to (ab-)use Symbol literals and implicit
> conversions, so I can write
> new JLabel('helloWorld)
> --> Hallo Welt //if you are German
> --> konnichi ha, sekai //if you are Japanese
> If this works as expected, and nobody tells me that it's seriously
> misguided, I'll go for it. I probably won't get it shorter.
>
> Take care!
> Daniel
>

I really like this idea, perhaps a derivation of 'helloWorld( param1,
param2 ) is usable for adding parameters.

For language choice and resource bundle location I guess implicit
parameters in the implicit def are perfect.

There are two basic philosophies about i18n. One is two get all strings out
of the code, the other is to use a standard language (usually English), and
its strings become the lookup keys for finding the translated ones. This
latter style is the one described very well by the GNU project, for their
gettext() utility.

I prefer the former, there are some good "agileness" arguments for the
latter. I generally get the agileness for the former by rigging it up so
that if no message catalog/bundle/whatever is found, you get out some
intelligible English message no matter what, and that way I can defer the
real i18n, l11n (localization) work until it is really needed, yet be
prepared for it in the primary code base.

My usual principle is this: i18n must not "dilute" the code - adding i18n
must not add a bunch of lines to the code which dilute its intent and
purpose. So you need a set of abstractions that allow you to achieve this.

My i18n experience is mostly Java related - there's an absolutely wonderful
and awful book - Java internationalization - it's wonderful for showing you
the issues, lousy for the solutions in that interpreted naively, it will
blow up your code by a huge factor to achieve i18n.

Another other major issue is that languages don't work the same way w.r.t.
word order or pluralization. So what you really want is to take no position
on the order of the parameters to the translated string, and you need to
know when a parameter is a quantity. This is where the solution using
symbols you describe below starts to get into trouble.

E.g., in English zero is plural. E.g., "Zero files found", one is singular.
In French, zero is singular. In many languages there is a profound
difference between ordinal and cardinal numbers. E.g.,

1st 2nd 3rd, 4th...20th 21st, 22nd, 22rd, 24th...31st... is English
cardinals. In many other languages ordinals and cardinals both have varying
endings. The Slavic languages are particularly complex in this area, Asian
languages are particularly simple here.

The GNU gettext() article on this is

http://www.gnu.org/software/automake/manual/gettext/Plural-forms.html

which is a must-read for anyone thinking about i18n/l11n issues.

Best compromise I've seen is to have an Object per "module"

Msgs.fileNotFound(n)

or

Log.connectionLost(conn, status, code, etc)

As the only thing that appears in your primary code stream. All the i18n
stuff about resource bundles and such then lives entirely behind the scenes.
This is similar to the symbol trick you describe below, but a notch more
abstract by putting the function-call level in place.

Chris Twiner wrote:
>
> On 12/21/08, Landei wrote:
>
>
>> I had recently the idea is to (ab-)use Symbol literals and implicit
>> conversions, so I can write
>> new JLabel('helloWorld)
>> --> Hallo Welt //if you are German
>> --> konnichi ha, sekai //if you are Japanese
>> If this works as expected, and nobody tells me that it's seriously
>> misguided, I'll go for it. I probably won't get it shorter.
>>
>> Take care!
>> Daniel
>>
>
> I really like this idea, perhaps a derivation of 'helloWorld( param1,
> param2 ) is usable for adding parameters.
>
> For language choice and resource bundle location I guess implicit
> parameters in the implicit def are perfect.
>
>