[Zope-dev] Translator 0.1 released

[Ibaņez Palomar Juan David]

Hi again!

The dtml-str thread yesterday was very active and it continue.... :)

Yesterday I printed the email messages and the L10NFolder source code
and studied it before going to sleep. The result is the first release
of the Translator product and this message, an attempt to join our
until now dispersed work.

Download the translator from 

  http://www.zope.org/Members/jdavid/translator

The translator product is just the old vocabulary product renamed
following the Michell advices and with a new translate tag which
is a first implementation of the Shane's proposal.

Suppose the data contained by our Translator instance is:

 {'my': {'es': 'mi'},
  'house': {'es': 'casa'},
  'is': {'es': 'es'},
  'green': {'es: 'verde'}
 }

Then if you type:

  "<dtml-translate>my house is green</dtm-in>"

and "languages" is "['es']" then the result is "mi casa es verde"
(and it's right!!).

It does it by:

 - split the string
 - translate each word
 - join the string

Yes, this is only a bogus algorithm but it shows how it would be.
Future releases should allow to plug more intelligent translators.

So now we have a good way to translate "static" strings:

 <dtml-var "translator('manage main')">

and also a good way to translate dynamic texts with the
"dtml-translate" tag.


Now I'm going to comment the L10NFolder by Federico.

There're two things I don't like with it:

 1. The L10NFolder changes the default behaviour of the dtml-var tag,
    this could break lot of dtml code in an unexpected way.

    The translator product does it in a different longest way. But
    other solutions could be tried, for instance the "dtml-var" tag
    could be modified to accept a new argument called "translate",
    if present it would translate the string returned by the "var"
    tag. For now I think the translator product approach is enough.

 2. Say I have a University site which is an instance of my own
    product which subclasses Folder. Then I want to provide 
    internationalization support using the L10NFolder, I have
    to modify my product so it subclasses from L10NFolder instead
    of Folder. I think it's not a good way.


What I *really* like of the L10NFolder product is its url traversal
special feature. I propose to implement that feature in the translator
product but in a slight different way.

Say my site is:

  University/
   image
   Department/
     image

to transform it into a multilingual site I would add a translator object
and translate the objects (documents, images,...):

  University/
   translator
   image
   image_es
   Department/
     document
     document_es

Then the url "University/image" would return the "University/image"
object but the url "University/translator/image" would return the
"University/image_es" object. It could also be used deeper in the
hierarchy so "University/Department/translator/document" would
return "University/Department/translator/document_es".

In this way there is no need to modify the python code, just modify
the urls. What do you think about this Federico? If you think this
is a better approach feel free to add your url traversal magic to the
Translator product and your name to the copyright.



There're also a lot of other issues I haven't talked about in this
message because I think the first step is to join the work that has
already been done in a single product.


I think this translator thing can be a really powerfull feature,
think about an Squishdot with multilingual support, each user
sees the aricles and comments in their own language. Really a
killing feature for Zope :)


David