[Zope3-dev] Re: [Zip] Translation question

[Lennart Regebro]

From: "Jim Fulton" <jim@zope.com>

>     An alternate view is that translation is from text ids to text values
>     in different languages. We might have an id like "greet" or "42",
which
>     has the English value, "hello world". To translate this to french,
we'd
>     make a call like::
>
>       translate("greet", destination_language="fr").

I think this is the way to go. Both because it's simpler, and because I
can't seen any situation where you suddenly don't know which the string is
that you are translating, except for when you are making text translation
applications like babelfish. And thats not what we have here, because a
message catalog would be utterly useless for that. :-)

> Are translations done on a product-by-product basis, or system wide?

I'm going to define a couple of different areas:
- Zope instance
- Python product
- Python product instance
- Website

And two different audiences for interfaces:
- Management interface (ZMI/ZopeTop)
- Visitor interface (what the website visitor sees)
Zope 3 will make the distinction between these blurrier than it is today,
but the distinction is still valid.


Translations for Python based products will be done on a product-by-product
basis. Translations need also to be distributable with the product
installations (so the message catalogs there need to be disk based, but
thats out of scope for this discussion). The translations are made *mainly*
of the management interfaces, but could also include translations of visitor
interfaces (
A Python product can have several instances, and each instance of the Python
product can have it's own language setting, but it won't have it's own
translation. Translations are, if you will, product wide.

Each Zope instance can have several websites, and each of these websites may
need differing translations of it's visitor interface. These can clash with
each other, so there needs to be a way to prevent that. This can be either
with
- different domains (I don't like that)
- different message storages and a possibility to select storage, or
- differing translation services for the different parts of the same Zope
instance
   (doesn't sound good either)

> We are defining a translation *service* that supports system-wide
translation,
> allowing translations to be shared among multiple applications. It's not
clear to
> me whether people will actually do translations that way

Probably not. If you are making your own product interface it would be very
unwise to use another products translation or even Zope cores translation of
the words you are using, since you have no control over these, so they can
suddenly change to mean something slightly weird. :-)

There is one part that should be system-wide, and that is the translation of
dates. In fact, there should be translations not only for days of the week
and months, but also date and numerical format translations. So that if you
do a translate(shortdatetimeformat, language='sv') you get the result
"%Y%M%D %H:%m" to use in date format strings.

There may be more system-wide stuff like this, but I can't think of any. It
can and should be system system-wide because it is not only system wide
beyond the Zope scope, but it is even system wide beyond the use of
languages, an as much as users may want dates in a local format even if they
are using english as the interface language.

> It seems to me that using text in an implicit source language as
translation
> identifiers, rather than using explicit source languages doesn't make
sense
> of translations are shared among multiple subsystems, but is acceptable
when
> dealing with subsystem-specific translations.

Hmm... Why that would make a difference?

Best Regards

Lennart Regebro
Torped Strategi och Kommunikation AB