[TransWarp] internationalization

Radek Kanovsky rk at dat.cz
Thu Jun 26 04:52:19 EDT 2003

On Tue, Jun 24, 2003 at 08:49:01AM -0400, Phillip J. Eby wrote:

Sorry for delay.

> >I have searched through the web for some smart solution but haven't found
> >anything.
> Have you looked at Zope 3's 'zope.i18n' package?

Never seen before but studying now. It seems that they extracted some
data from IBM's ICU library and re-implemented some parts of it. They
use gettext for message catalogs and with "interpolation" solved
problem with positional parameters. zope.i18n imports from other zope.*
packages so it would be difficult to use it independently (I don't
know zope much). I like very the idea of explicit translation with
ITranslationService that is important for component architecture. While
gettext itself translates messages immediately/implicitly during _(...)
calls and there is almost no possibility to adapt this process.

My previous mail was probably fuzzy. I wanted to say that gettext
or gettext backed solution is not sufficient for me. Sometimes many
percent of source code occupies 'if-else' constructs that deal with
plural-singular, gender and other possibilities. Source could be more
cleaner if we would have support from some smart active message catalog.

I have started to write a prototype. Message catalog format is now
simulated by raw python module. Catalog should be able to solve
things like this (in pseudocode) :

    encoding: iso-8859-2
    language: cz

    hello: "Ahoj!"

    hello(name): "Ahoj %s!" % name

    records_found(num) :
        if num == 1 : "Nalezen 1 zaznam"
        elif num in [2,3,4] : "Nalezeny %n zaznamy" % num
        else : "Nalezeno %n zaznamu" % num

Now usage is simpler:
    _ = some_active_catalog_factory(domain, default_catalog_near_this_module)

    greeting1 = _.hello
    greeting2 = _.hello('Alice')
    found = _.records_found(len(result))

"_" has redefined __getattr__ method so it is able to catch message
ids and emit MessageId instances. I can create more rich context in
__getattr__ (module name, function name, line number, etc) and this
context can be available to active catalog during translation.

> Also, I believe GNU gettext has support for declaring different
> translations of the same string based on a numeric value formula.

I am not aware of such support. But there are many other problems with
localization: There is often very hard to find one general translation
of simple english sentence that fits in all occurrences. This translation
may vary according to context.


More information about the PEAK mailing list