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
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
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
<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.
right. but this is exactly what you want. if not don't put this code in an l10nfolder.
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?
ok. real example from the site we are building now. we put all the images in an image folder (actually more than one because we have 300+ png, but let's simplificate), the translator object is called translator and the page i want to display is in a folder named foo. comment after # images/ translator head.png # this images are not localized logo.png ... menu.png # this image need to be localized, this is the default it/ # the iso named folders contain the localized menu.png # versions of the images en/ menu.png foo/ translator bar.html # DTML document with the page i want to display inside bar.html i can put some code like this: <dtml-with images> <dtml-var logo.png><dtml-var head.png> ... <dtml-localize menu.png> # this includes the localized version of # menu.png or the default version if the # requested version is not available </dtml-with> ... The text you required in <dtml-var language> is: <dtml-localize text1>. text1 is defined on the translator object inside the foo folder. the right menu.png can be accessed through the dtml-localize tag because dtml-localize looks for translator objects with the default acquisition rules and ask them about the wanted object. the translator object in images knows about the iso-named folders and returns the object translated in the right language or the default. i think i can implement it by merging translator and l10nfolder. can i go on? ciao, federico -- Federico Di Gregorio MIXAD LIVE System Programmer fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org Don't dream it. Be it. -- Dr. Frank'n'further
participants (2)
-
al028823＠alumail.uji.es -
fog＠mixadlive.com