Thank you for the note.
I urge anyone looking at internationalization of a zope product to look at
the Localizer tool that uses the standard gettext tool can help a lot.
As far as I know, Localizer is one of the tool that is considered by Zope
Corp. to help to internationalize zope right from the beginning.
It also helps in the way that the original program must only be adapted ONCE
for all languages. The translations are thereafter very easily managed
through .po files that can either me delat with though a zope/web interface
or with other tools (like kbabel)
I'll have a look as soon as I can at the source of freepm, but we could pool
the efforts, and the original authors of freepm could help putting localizer
in use in the original code (nearly just a matter of adding "MC(' ')" from
place to place), letting us do the translation afterwards.
Best regards,
Nicolas
Le Mardi 5 F�vrier 2002 07:07, [EMAIL PROTECTED] a �crit :
> Hello List & Ignacio
>
> On Mon, Feb 04, 2002 at 09:17:18AM +0100, Nicolas Pettiaux wrote:
> > I would like to know if Freepm has been "internationalized" (ie.
> > translated)
> >
> > If not, what are the current prospect ?
>
> ...
>
> On Mon, Feb 04, 2002 at 06:38:33PM -0600, Ignacio Valdes wrote:
> > Hello Jorge, I understand from Tim Cook that you are working on a
> > Spanish translation of FreePM. If so, how is it coming?
>
> ...
>
> Actually I am adapting FreePM for a customer: a Policlinica in
> Nicaragua.
>
> The doctors will not (yet) introduce the data themselves and my
> primary goal is just registration of medical service yielded to the
> pacients and control of the inhouse lab.
>
> For this I had to find a quick hack to translate the main entrance
> pages to spanish, and as I "do not know" HTML and Zope a very crude
> method which I will discuss later is used.
>
> Until now there are about 80% of the "Administration" Menus translated
> to spanish, the EMR-search page and the EMR-page, and also Lab-orders
> entry and Lab-orders ticker and results page.
>
> This means, that principally an instructive spanish demo-site could be
> created yet.
>
> About Internationalization:
>
> I used the following dummy aproach:
>
> * Duplicate each (translatable) DTML Document or Method,
> * anex "_es" and "_en" to the name, and
> * create a dummy method with the original name which just calls the
> (spanish) version.
>
> This approach waits for the refinement to create the anex out of the
> REQUEST.LANG variable or whatever this beast is called where the
> prefered locale of the visiting browser can be found, so that the
> pages are automatically translated into the "right" language.
>
> There are more or less three basic aproaches to Zope
> internationalization, as far as I checked (superficially) out.
>
> gettext method: each string is looked up in a translation table,
> indexed by the locale.
>
> This aproach seems unbearable for Zope and FreePM to me, because
> DTML is text at all and "strings" are created in a highly dynamic
> manner. Theres a *lot* of variable substitution, which as the
> mere horror of each programm-translator.
>
> We yet have text, marked up with HTML, marked up with DTML and
> Python, and would burden up this monstrouos "programming" mixture
> still more with a "internationlization" markup.
>
> Some ad-hoc translation I did would almost NOT fit into a
> reasonable one-file translation scheme.
>
> subdirectory method: for each locale, a subdirectory is created, where
> translated copies of the original files are held. A special kind
> of folder manages to fool the browser into loading the
> "locale-right"-document.
>
> While this aproach does not clutter up the working directory,
> there could be an issue with some of our special DTML Class/Method
> constructs, don't nail me down on this though.
>
> What's more about a problem is, that translation seems a lot more
> dificult, as your files are "somewhere" else, for almost all of
> the cases, and you have to surf around to find the correct
> references. What happens if the "original"-(english?) version is
> changed in substance? How do you keep track of divergation?
>
> my method but more elegant: Zope itself is patched, so when it loads
> a document it tries first a localized version. I think it
> pre-pends, rather then anexes the locale string.
>
> This method is not accepted by the Zope-masters, I think for
> security reasons, but supplied as a patch.
>
> It allows a simple add-on aproach, without the "original"
> programmer worrying about nothing, and the translator just copies
> the original file and starts working.
>
> Of course we have the same problem as the former method:
> translations will tend to deviate from the original more and more
> through time.
>
> The best, at my opinion is, to mix the two aproaches, and then, to use
> rigidly a programming style in the original sources, which encourages
> substitution of visible text for internal objects.
>
> If you use for example the variable ID (as is very common in Zope) for
> display inside a page, then you will get untranslateable pages.
>
> If you loop over a set of objects, then they would have to have an
> access function to their "visible" representation, so you can
> encapsulate internationalization inside this access function.
>
> This is of course not a matter with user created objects, as users
> tend to give them names they understand, but with things like lists of
> property names, fixed or almost fixed choice and validation lists,
> etc. e.g. I could easily change "Male/Female" to
> "Masculino/Femenino", but not "Married, Divorced, ..." which are
> "hardcoded" (I'm a potty mouth, haven't even looked where to find
> them yet).
>
> Ok, gimme feedback people! ;-)
>
> Ciao,
>
> Jorge-Le�n
>
> _______________________________________________
> FreePM Support List
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/freepm-discuss
--
Nicolas Pettiaux
Avenue du P�rou 29
B-1000 Brussels
_______________________________________________
FreePM Support List
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freepm-discuss
