[TransWarp] internationalization

[Phillip J. Eby]

At 10:52 AM 6/26/03 +0200, Radek Kanovsky wrote:
>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).

AFAIK, it's just zope.interface and zope.component.  PEAK will be using 
also zope.publisher for web applications, and it imports zope.interface and 
zope.component also, so I'm largely resigned to this.  Although, I do think 
at some point I may write a 'peak.web.zlite' package that will put in stubs 
for zope.interface, zope.component, zope.proxy, etc. so as to minimize 
these imports.  Importing 'peak.web.zlite' before importing a Zope 3 
package would then prevent it from importing unwanted extras.



>  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

Although Python doesn't (currently) support it, the underlying gettext 
format *does* support these extended plural forms, using a 'Plural-Forms' 
header, and a function that takes a number.  See:

http://www.gnu.org/manual/gettext/html_chapter/gettext_10.html#SEC150

For the way this is used in the catalog format, see:

http://www.gnu.org/manual/gettext/html_chapter/gettext_2.html#SEC9

Again, I'm not sure that Python or Zope's gettext tools support any of this.


> > 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.

My understanding is that this is what Zope's "domains" are for - to ensure 
that the context of interpretation is meaningful.  With zope.i18n, '_' is a 
"message ID factory" for a specific domain.  Calling it on strings or 
unicode objects returns a "message ID" object that knows its domain.  So, 
the translation service then does not need a separate domain argument.

The downside to the Zope approach is that it's not really suited for 
non-web applications.  Zope assumes that message IDs will be explicitly 
passed through a translation service.  This doesn't work quite as well for 
say, GUI or console apps, although there's no reason we couldn't have 
something like:

class SomeButton(gui.button):
      buttonLabel = i18n.bindToTranslation(_("$n records found"))

Which would lookup the translation service in the appropriate context.  Of 
course, if one is dynamically switching locales (as web apps effectively 
must), then this isn't really the right thing either; translation should be 
done when the label is actually passed to the GUI level, or else there 
needs to be a LocaleEvent service that locale-dependent components can 
subscribe to when the locale changes.

These, however, are relatively minor issues, with technical solutions.  A 
much harder problem to solve is translation of dynamically-assembled 
sentences.  For example, one app I've worked on has a search criteria 
screen that is designed so the field titles and the field contents can be 
read as a single sentence.  A variation of that same sentence is then used 
as the title of the resulting report.  I'm not aware of any good way to do 
this with simple message catalogs.