[Openinteract-dev] Re: I18N in OI2

[Teemu A. <te...@io...>]

Hello Chris,

sorry about not paying attention into this until now.

> I agree with your points, but my three main objections to using the
> base language as the key are:

>   * What do you do with long strings? (One or more sentences)

I thought about this and there are of course ups and downs of both
approaches. Maybe allowing both methods?

I mean, short sentences and system messages that usually contain something
dynamic like "Hello [_1]" are used as the key. Pros are:

  * self-documenting
  * easier to translate
  * works as gettext was originally designed to work

Very long sentences (context sensitive help for example) are usually
static and hard to maintain as short, so a key like "news.help1" could be
used instead.

>   * What happens when you change the base language text?

Well, you have a couple of options. One is that you just continue using
the "wrong" sentence as the key and just change the translation in the
english one to correct the typo. Obviously a better idea is to change all
the keys. For this purpose some scripts should be written to rewrite the
base key for all translations. I made one for my work in other projects.

>   * Many of the base language keys will be quite long.

Actually by my experience most sentences are short. Only in help texts,
static content and in some other special occassions you have very long
sentences at once in your code.

> For the first objection I guess you could just use the first part of it
> the long string. This kind of eliminates the benefit of using the base
> language as key, it"s not used as often.

Maybe my idea to use a short key like "news.help1" in case of long
sentences is better.

> The second objection seems like a big problem. How often does it
> happen? Not sure.

It happens mostly in an intence development process. I tend to write an
application almost into the first stable stage before adding any
translation. This way I avoid correcting the translation files all the
time. Things tend to get added and removed. Changes to strings happen
usually only to correct typos (more common if you are non-native english
speaker) and if your string contains dynamic data and you add or change
the way things are presented to the user.

While I write the first version, I use the english string as the base key.
When I'm ready with the application, I extract the base english .po file
with a script from the perl code I have written. Since I use english
strings as the key, I don't have to manually write the base english .po
file, I just use a script to extract the strings.

After this changes to base translation do not occur very often. It is more
common that new strings get added than things get changed or removed. For
this purpose I have a script that adds the same string for translation
into every .po file of the application, avoiding manual work.

> Okay, I think I could go along with this. I would like the option of
> putting a package"s keys in the global namespace for applications using
> multiple packages. But the default should be that when requesting a
> message key you only look in your package"s space and the global space
> if it"s not found there.

Good, this is especially useful if one uses english strings as base key.
Even if the english string could be universal all around the system, often
a translation is not. Many languages are very much dependant of the
context where the string occurs and an english string in two places could
have two different translations in one language.

> True, but I think most uses of the messages will be in templates where
> it"s much more difficult to parse groups of text out into individual
> entries.

In my applications I avoid adding strings into templates. Why? I think the
strings are part of the application business logic and should reside as
part of my code. I use templates only as widgets of the web interface I'm
about to generate. If I later want to use a different system other than
TemplateToolkit for web pages, I don't have to move the strings from
another interface code to another. For me, only help pages and other
static content resides somewhere else. This is simply a matter of taste, I
believe many programmers put most of the strings in their templates.

I also created an API for writing applications for OI in a simple manner.
This supports the idea of having strings as part of your code. See:

http://www.dicole.fi/docs/dicole_api_overview.html

I look forward to the I18N support for OI. I plan to port my API and
applications to OI2 once it becomes available, I'm not willing to write my
own I18N support for OI1.

-- 
Sincerely,

Teemu Arina

Ionstream Oy / Dicole
Komeetankuja 4 A
02210 Espoo
FINLAND
Tel: +358-(0)50 - 555 7636
http://www.dicole.org