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
