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

[Ibaņez Palomar Juan David]

> 
> 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...
> 
Nobody is forced to use it, it's only a service.


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

yes 

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

Agree, using a tag is shorter a clearer.

Anyway both approaches could be supported, making the object callable
is only one line.

 __call__ = render

and allows a short way to call it from python code "self.translator(...)"
instead of "self.translator.render(...)"



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

<dtml-try>
 <dtml-var name>
 <dtml-except>default string
</dtml-try>

The user who writes this dtml expects the "default string" to be
displayed if the object "name" doesn't exists. But if it's called
from a L10NFolder that has an entry for "name" then its translation
is displayed instead.


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

Yes, it looks better. Please, could you illustrate its use with an example?

> 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
> 
> _______________________________________________
> ZIP maillist  -  ZIP@eevolute.com
> http://www.eevolute.com/mailman/listinfo/zip
>