[Zope-CMF] I18n

[Joachim Werner]

Hi!

> We certainly hope to leverage the work done by ZIP/EuroZope,
> including ZBabel.  I haven't yet had time to look at alternatives,
> but ZBabel is definitely at the top of my list.
>
> How does it handle content negotiation, BTW?  ZBabel is primarily
> for internationalization of the application / skin, rather than
> content, correct?  How are y'all dealing with the separate (but
> related) problem of serving alternative translations for content?

In the long term, ZBabel should be usable for all kind of translation/i18n
work, be it on the app/management interface level or on the content level.
But ZBabel is far from being "finished", though the current version is
already very stable and useful.

That's what we currently have:

1) Two tags:
  - the "babel" tag, a block tag to translate text blocks
  - the "fish" tag for shorter texts, like button labels etc.

With the tags you can translate virtually any application-style HTML and
things like the navigation of your website. As the "fish" tag can take
variables as labels, you can also do things like that: <dtml-fish
label="manage_tabs_message"> (which takes the manage_tabs_message and looks
up a translation; if there is none, the English message is returned)

You can also translate dates etc. like that:

<dtml-fish label="'date'" data="ZopeTime(lastChangeDate)">

You just put the translation strings "data.strftime('%d.%m.%Y')" for German
and "data.strftime('%m/%d/%Y')" for English into the ZBabel dictionary ...

The basic idea is that you do "late translation", that means that your
application just uses the English (or whatever other base language you
choose) names internally and then the output is translated phrase-by-phrase
at the very end.

The ZBabelTower, which is the dictionary, is available in an SQL
implementation and in a ZODB implementation. It has an export/import tab
feature so you can provide people with translation packages etc.

2) A so-called "ZBabel Object", which is an object that simulates being an
image, file or DTML Method, but is in fact a folder that contains the
language versions of the image/file/whatever.

The ZBabel Object works well if you don't have to pass variables to the
enclosed object (e.g. for images or HTML that contains no DTML variables),
but AFAIK there still seems to be some problem with passing the namespace.
When that is done, it would work completely transparent to the user. It's
basically a more elegant implementation of what Chris Withers talks about in
his posting.

We think that approach is much more useful than having two trees of objects
for the two languages, as you can just move, delete, export/import an object
with all existing language versions included, and also better than having
special content objects that hold language versions as attributes, as ZBabel
Object can basically contain any type content object (be it an image, a CMF
content object, or an MSWord file) and therefore is much more flexible and
compatible.

What is still missing:

- The ZBabel database is currently "flat", i.e. there are no
sub-namespaces -- which would be cool. E.g. one might want to have two
translations for "Sun", one being (examples in German) "Sonne" (the star),
the other being "Son" (abbr. for "Sunday"). So both a calendar tool and an
astronomy tool could bring their own namespaces with them. Currently you can
do things like that by choosing unique labels, but it would be more elegant
to have certain namespaces (and yes, you CAN have multiple ZBabelTowers,
i.e. dictionaries, and specifiy them in your tags ...).
It would also be cool to have something like translation hierarchies,
similar to the skins in CMF, so that one can change translations for a
customized system and still apply all the ZBabelTower updates the
application author provides ...)

- There is no syntax for using ZBabel from either Python/Scripts (Python) or
ZPT. It's really just the syntax that is missing, as the implementation is
not DTML-specific. I think ZPT integration would be rather cool, as it uses
tags very similar to ZBabel. Maybe we just need a new command, something
like:

<h1 tal:translate="...">This is a header</h1> or like this: <span
tal:replace="translate dateAndTime">2001/12/12</span> ...

- ZBabelObject needs to work with passed namespaces/variables, so that it
can be used with more complex content objects

- Probably some front ends for the translators that display more than one
language at once ...

- The export/import might be made compatible with existing standards like
the gettext file standard or .xls, so that people can translate strings
offline and import them later.

Content negotiation is done using the browser settings, but you can also use
other ways, like session variables, cookies, etc. -- I am not sure about the
details there, but that part is rather easy to customize in the code ...

Feel free to tell us (me or Stephan Richter) if you are missing any
important features ...

Cheers

Joachim