Phillip J. Eby
pje at telecommunity.com
Thu Jun 26 11:58:05 EDT 2003
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:
For the way this is used in the catalog format, see:
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
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.
More information about the PEAK