"Ibañez Palomar Juan David" wrote:
Hi all,
Note: I cc this message to zope-dev because I want to be sure that the DC folks get aware of this, since I think internazionalization support should be a standard Zope feature, so their opinion is *very* important.
First, I've just uploaded the vocabulary product to Zope.org, download from "http://www.zope.org/Members/jdavid/vocabulary".
Everything here in your email looks very good. I just want to point out one thing, in the CVS version of Zope there allready exists a standard Catalog component called 'Vocabulary'. This is a top level addable object, and is very aparent to Zope users. I suspect that naming your product 'Vocabulary' will cause great confusion. I'm not sure if 'vocabulary' is even a good word for your product (no offense, I know one name is often as good as another), a standard Zope vocabulary is the collection of atomic 'words' that a catalog catalogs. In this way, it is the total sum of words that is known to a set of catalogs, so Vocabulary is pretty apropriate. In your case, your product apears to map a series of words to their transations, so although it contains a vocabulary, its main purpose apears to be to map that vocabulary to other words. For the purposes of this next paragraph, I'm going to call your product 'Translator' and the standard Zope component 'Vocabulary'. Really the best solution, I think, is to subclass Vocabulary and make your own kind of Vocabulary object. Vocabulary object have a very, very similar purpose to your product, they contain a vocabulary. In this case however, you can take adavantage of the fact that we have done a lot of vocabulary managment and catalog integration work for you. With a little subclass magic, you can roll the Translator into your own kind of Vocabulary that can be queried to return translations instead of the original words (following your algorithm). This, in fact, would be quite powerful, because then you could type the word 'house' in a Catalog, and have it return all the documents that contain 'casa'! Vocabulary objects, like your Transaltor, are querieable from DTML and are useful in non-catalog contexts. Also, Vocabulary objects contain wildcard searching, something I think your Translator could really benefit from. I'm sorry I haven't been able to document this better for you guys on zip, in fact, I'm not even on the ZIP list, although I should be. There is some exciting work going on in the whole Vocabulary front; I'm currently working with some folks to get a Japanese Vocabulary. Very exciting stuff. Let me know what you think about my proposal, I can help you subclass your own kind of vocabulary object and merge your Translator into it. -Michel
Now a brief description of the vocabulary python product.
It is really simple, the data structure is a dictionary indexed by strings which contains another dictionary indexed by language which contains the translations, example:
{'window': {'en': 'window', 'es': 'ventana', 'ca': 'finestra'}, 'house': {'es': 'casa'}, ... }
It also provides a web interface to edit the entries and translations, visit "http://estce.act.uji.es/zope-edu/LLEU/V/manage_workspace" to see it.
And more, it has XML support, you can export/import its contents to/from XML files. Just click in the "XML" tab to see it.
It's used in this way (if the product instance is called "V"):
<dtml-var "V('window')">
The language is determined by the variable "languages" which must be a sequence of languages, for instance it could be a Folder property of type tokens with value "en es ca".
First the translation is searched for the first language ('en' in our example), if it's found that translation is returned, if no it tries with the next language, if no translation is found it returns the original string.
Hi Shane,
First, please excuse me because my yesterday comments were so short, writing good english messages takes time for me.
Your proposal is a different approach to the problem, and I think both solutions complement each other.
The vocabulary product is more flexible because you can use it from any place (not just DTML Documents) and it also allows to share common translations.
The solution you propose is specially useful to translate long texts which are unlikely to be found in more than one place. And since the contents between the "dtml-str" tag could be very dynamic it also opens the door to automatic translators.
Hi folks! I would like to propose an idea that may help to push forward Zope internationalization. This idea sprang from the conversation on the zope-edu-user list.
I don't have a solution for charsets nor date formats, but I do have an idea that would make language translation much more feasible.
I suggest the addition of a tag called <dtml-str>. "str" refers to "string", the term often used when dealing with translation in Windows applications. In DTML documents, we currently have something like:
<dtml-var name>, you have <dtml-var days> days of service remaining.
We could add a <dtml-str> tag to it as follows:
<dtml-str DAYSREMAIN><dtml-var name>, you have <dtml-var days> days of service remaining.</dtml-str>
If the user wants translation, the string would be substituted with something from a small repository. The repository could be stored in the DTML document itself. Somewhere in the document (it doesn't matter where, but the bottom would be preferable) there would be something like the following:
<dtml-translation languages="br; brazil; brasil; port"> <dtml-str DAYSREMAIN><dtml-var name>, deixam <dtml-var days> dias de servico.</dtml-str> </dtml-translation>
When users request translation either through the HTTP_ACCEPT_LANGUAGE header, a cookie, or a part of the URL, the DTML processing mechanism looks through the available languages and, if one of the specified languages is available, replaces the text of <dtml-str> blocks with the corresponding translation.
The management interface for DTML documents would be modified as follows:
- A "default language" text box would be added to the "Edit" page.
No really need for that, if the translation is not found the text returned is the one untranslated, so if you write it in english, then english is the default language.
- A new tab would be added called "translations". Translators would be presented with an easy translation interface that lists all of the <dtml-str> tags and provides a text area for entry of the translation.
Original DTML authors would only need to add <dtml-str> tags in strategic places. Translations would often survive between versions of the original document. The tags would even work in the DTML portion of Zope's management interface.
What's best about it is that it is not a significant change to Zope and might take a week at most for someone to implement.
What do you think?
Shane Hathaway
_______________________________________________ ZIP maillist - ZIP@eevolute.com http://www.eevolute.com/mailman/listinfo/zip
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )