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

[Jim Fulton]

Lennart Regebro wrote:
> 
> 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,

This gets back to the discussion below. Typically, the "ids" people
use are text in some implicit source language. This works if the translation
is done for a project but not of translations are shared accross projects because
different programmers may use different (implicit) source languages.

...

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

Why?

> - different message storages and a possibility to select storage, or

Right, but how would they be selected? I don't think application code
should do this as it makes things too hard to change. I'm begining to see
the "domain" as a fairly abstract selector for a translation, which might
be very useful.

> - differing translation services for the different parts of the same Zope
> instance
>    (doesn't sound good either)

Again, why? One of the benefits of Zope 3 is that it lets site managers
override UI to meet specific needs. Don't you think site managers might
also want to override/customize translations?
 
> > 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. :-)

I suspected that this was the case.
 
> 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.

Well, there might be value in standard terminology for standard operations 
accross applications. 

...

> > 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
> > if translations are shared among multiple subsystems, but is acceptable when
> > dealing with subsystem-specific translations.
> 
> Hmm... Why that would make a difference?

Because different developers might use different "implicit" source
languages.

Jim

--
Jim Fulton           mailto:jim@zope.com       Python Powered!        
CTO                  (888) 344-4332            http://www.python.org  
Zope Corporation     http://www.zope.com       http://www.zope.org