[Zope-dev] Re: [ZIP] Translator 0.1 released

Federico Di Gregorio fog@mixadlive.com
Fri, 24 Mar 2000 12:24:25 +0100


hi *,

	some comments about the translator product and L10NFolder. first
of all i don't like very much the translator approach of translating every
single word in a string. it is almost impossible to have a computer do a
good automated translation and i think the right place for such a project
is a separated program, not zope. our zopes are dealing with high load
localized sites: we need to access the right versions of strings, images 
and external files fast. that's all. but read on...

Scavenging the mail folder uncovered Ibaņez Palomar Juan David's letter:
> 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>"
                                       ^^^^^^^
shouldn't it be </dtml-translate>?

> So now we have a good way to translate "static" strings:
> 
>  <dtml-var "translator('manage main')">

mmm... i'd better like a separated tag, something like <dtml-tvar>
(translated var) or your <dtml-translate>.

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

no. it won't break any code (bugs in l10nfolder apart) because it first
tries the default acquisition, and only if nothing is found, it goes to
the localization part.

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

i agree. and the l10nfolder is enough too. the filosophy behind my product
is "do it the most transparent way." that's why i modified the acquisition
inside the l10nfolder.
 
>  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.

that's right.

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

i like the idea of having a translator object inside the folders i
want to translate. but i definitely don't like the necessity of having
"translator" in the url. here's what i think about merging the two 
projects...

lets add two different dtml tags:

dtml-translate - translates every single word. i don't think is a good
  idea to put such a beast inside zope, but somebody can need it, so why 
  not? we just need to arrange think so that the other tag doesn't need
  this stuff.

dtml-localize - this is a localized variable. normal acquisition does not work
  with it. just the url transversal. and even the transversal is limited to
  iso names. dtml-lvar looks for localized variables on the translator object
  it has access to (default acquisition to find them) and inside folders
  with iso names (as l10nfolder does at now.)

this should bring to the product the best of both worlds.
what do you think about? 

federico

-- 
Federico Di Gregorio
MIXAD LIVE System Programmer                           fog@mixadlive.com
Debian GNU/Linux Developer & Italian Press Contact        fog@debian.org
  99.99999999999999999999% still isn't 100% but sometimes suffice. -- Me