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