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". 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
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.
Ops! The url is wrong, the right one is "http://estce.act.uji.es:9673/zope-edu/LLEU/V/manage_workspace" sorry David
Scavenging the mail folder uncovered Ibañez Palomar Juan David's letter:
First, I've just uploaded the vocabulary product to Zope.org, download from "http://www.zope.org/Members/jdavid/vocabulary".
ok. you just beated me by some hours! i was about to release my first product today: L10NFolder. so there it is. note that i copied some of your code (dtml) because was much cleaner than mine. no XML at now. README follows... (emm... i created a product and then a release... how do i make it public? ah, the review process, ok... for now you can find the product at: http://www.zope.org/Members/fog/l10nfolder) L10Folder Zope Product ********************** This is a subclass of the standard folder with some added bonuses. First you can add localized properties, much like the Vocabulary product. When you access the property via a dtml-var tag, you get one of the different versions based on the contents of the HTTP_ACCEPT_LANGUAGE header, of a cookie selected by the Zope programmer and on the list of default languages. Then, the L10NFolder modifies a little bit how acquisition works inside it. If a attribute (property) name can't be resolved by the folder itself, it looks for folders and documents named as the languages in the list of accepted languages and the tries to resolve the name on them. This leaves space for things like: * different subfolders with different images per language * very complex pages can be written as dtml documents and then translated. after each translated copy is put in its own folder (named it, en, etc...), the L10NFolder gets and render the right one. TODO ---- Testing. Bug hunting. Better performance. Provide some examples. Add TRANSLATE permission? CREDITS ------- The dtml interface to add/modify/delete localized properties has been taken from the Vocabulary Zope product, by J. David Ibáñez and Andres Marzal (al028823@alumail.uji.es.) Their code was much cleaner than mine, so many kudos to them. AUTHOR ------ C-x i ~/.signature Federico Di Gregorio MIXAD LIVE System Programmer fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org Debian. The best software from the best people [see above] -- brought to you by One Line Spam -- Federico Di Gregorio MIXAD LIVE System Programmer fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org Quis custodiet ipsos custodes? -- Juvenal, Satires, VI, 347
"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 )
On Thu, 23 Mar 2000 06:25:09 -0800, Michel Pelletier <michel@digicool.com> wrote:
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.
I think this is one reason why it makes sense to keep Vocabulary and Translator objects distict. * Vocabulary objects manage atomic words. * Tranlator objects manage phrases. (Perhaps 'phrasebook' might be an even better name. Toby Dickenson tdickenson@geminidataloggers.com
participants (4)
-
al028823＠alumail.uji.es -
fog＠mixadlive.com -
Michel Pelletier -
Toby Dickenson