[Zope3-dev] Translation question

[Jim Fulton]

I'm trying to move the initial Zope 3 translation interfaces forward.

These include:

 - ITranslationService, which is the interface that application code
   calls to translate text,

 - IMessageCatalog, which is the interface that the translation service 
   calls to do translations. The notion is that an implementation of 
   the translation service could have multiple catalogs plugged into it.
   The translation service selects the right message catalog(s) to use for 
   translation requests based on translation parameters provided by
   the application call and on the capabilities of the message catalogs
   plugged into the service.

   It's worth noting that message catalogs are an artifact of a particular
   implementation ideas and are, therefore not very core. *only* a particular
   translation service implementation depends on message catalogs.

Here are a few concepts to be aware of:

  - Language tags, as defined by 1766 (e.g. en-US), are used to identify
    languages.

  - A translation may be defined by a source language and a destination
    language. For example, "hello world" is text is a source language, 
    English, that could be translated into a number of different destination
    languages, by making a call like::

      translate("hello world", destination_language="fr")

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

    The two models are usually mixed up by using ids that are actually 
    phrases in some implicit source language, like English. Translation of
    these ids to the source language is accomplished by simply returning
    the id.

    Note that the destination language will commonly be picked through
    language negotiation.

  - Translations can be specific to problem domains. For example, the word 
    'Sun' may be a day of the week, an astronomical body, or a company name.
    To guide the translation, we might provide a domain in the translation call:

      translate("Sun", destination_language="fr", domains="astronomy")

    I wonder if applications will commonly define their own domains.

  - Because of gramatical differences among languages, translations need to
    be aware of variable interpolation. Variable interpolation is indicated with
    a common string interpolation language. For example, in::

      You have purchased $count ${item}s.

    The text includes two interpolated values. Translations of the text may
    need to move the placeholders around in the text or even exchange the positions
    of the placeholders.

    When application code translates the text above, it has to provide data for
    the placeholders, or perform the interpolations itself.

Questions? Comments?

OK, here's my question. :)

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

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, or whether translations
will be performed for individual applications or subsystems. I's really like
some input on this.

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.

Comments? Questions?

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