[Zope-dev] Re: [ZIP] dtml-str idea

[Michel Pelletier]

"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 )