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