Hello Federico, At 03:37 24/03/2000 -0800, you wrote:
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.
IMO you don't want a tag that translate strings based on word matching. The output won't be usable. (See my rantings in a previous email today). You might get nonsensical translations or partial translations. On the other hand I think "dtml-translate" is an interesting idea if translation is limited to full sentences or longer matches.
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.)
We may need to look again at the ZI18N product and similar ideas. What do we need ? - A way to offer language choice based on browser settings. - The choice needs to be overridable (eg. first check cookies, then browser settings, then a property, then whatever.) - The language-choice services need to be available for existing products and objects. How about base classes (available for ZClasses too) that affect which object is returned from an URL (eg. return "index_html_FR" or "/FR/index_html" instead of index_html based on browser settings or acquisition path or a language property). Do we really need to add localization tags? Isn't there a way we can handle these issues at object level instead? Or did I miss the point? Cheers. Alexandre