Internationalization (Language Translation) of CPRS

[kdt...@gmail.com]

I would like to post here some interesting finds I have encountered
today while researching the issue of translating CPRS into other
languages (Internationalization). It turns out that words are not all
that needs to be translated. Dates and numbers are also handled
differently in different countries. Fortunately the OS (in this case,
Windows) can keep track of those differences.

David Fonseca Sánchez has been working to translate his CPRS into
spanish. I initially thought that one had to manually go into the
program and change each label etc on each form and translate them one
by one. What a lot of work!

But it turns out that there are many programs on the market aimed at
helping people do just what we are interested in: making a program
available to people in many countries.

I was having a discussion offline with Peter and Nancy about this and
have decided to summarize here:
-----
First I found this page that has some components that one can add into
a Delphi program to help with internationalization.

http://www.torry.net/pages.php?id=273

I would have to study these to decide which one is best, but they look
interesting.

--LangINISupport sounds like just what I was thinking about.
--AdvancedLocalizer looks like a more professional component. We'd
have
to check on the licensing agreements for that one.
--Localizer looks very promising
--TLanguage and TLocalize look OK, but skimpy.

They look quite exciting. Looks like we are not the only people to
have a
big Delphi project that someone decides late in the game to
internationalize. Someone may have already done the hard work for us.

Then, even better, I found that there is an entire message board
dedicated to
issues of internationalization with Delphi:

http://groups.google.com/group/borland.public.delphi.internationalization.general/topics?lnk=srg

Then:
This looks interesting.
http://www.lingobit.com/solutions/delphi/index.html
Apparently it doesn't require source code (i.e. no recompilation?)
A link from this page describes how to ship CPRS with resource DLL
files. Then when the program is run, apparently Delphi code has the
application check with Windows for the correct locale, and loads the
correct DLL. So CPRS could be shipped with multiple language resource
DLL files, and it would self-select the correct language based on
their windows settings.

Very slick!

Then:
Look, Delphi has built-in internationalization!
http://delphi.about.com/library/weekly/aa102400a.htm
I am going through some demo's about how to use it.
---------

Another top-rated converter tool is:
http://www.tsilang.com/

And some others:
http://www.multilizer.com/index.shtml
http://www.lingoport.com/product/

I will add here that one of the cool features made available by a few
of the projects is the ability to let users themselves do the
translation as they go. Kind of like "crowd-sourcing" or the
wikipedia effect.
http://devtools.korzh.com/localizer/
does this (and I think tsilang does as well).

I think using the built-in Delpi functionality is the most
straightforward way to start out (no extra cost).
I would enjoy hearing other's thoughts about how to establish a
translation project for CPRS.

Kevin

[Jaska]

Hi Kevin,

> I think using the built-in Delpi functionality is the most
> straightforward way to start out (no extra cost).
> I would enjoy hearing other's thoughts about how to establish a
> translation project for CPRS.

ITE is straightforward from the programmer point of view but you will
face serious problem then it is time to traslate, update the project
for next version of your application (e.g. 2.0) and hwo to send
translations to translator and back.

- ITE lacks visual translation capatibilies outside Delphi (e.g. ETM).
- ITE can not propely syncronize your existing translation when you
original form and units change.

Use the localziation tools that you mentioned above make life easier.
However you forget a very easy and poverful localization tool,
Sisulizer
http://www.sisulizer.com

It pretty much as all the feature that above tool together plus much
more. It is higly optimized for Delphi localization becuase the tool
itself is written in Delphi and translated to 10 different languages
including Japanese and both Chinese langages. Sisulizer does not need
you to add any component or you don't even have to modify your source
at all (assuming you have written code for ITE). You just select the
EXE, Sisulizer scans it and create project. This project sen easily be
sent to your translator (they use free Sisulzier translation edition)
and they get 100% visual view of your application. if you have any
existing translations (e.g. resource DLL made by ITE) Sisulizer can
import them automatically.

By adding just one line of code you can add runtime language switch to
your application.

The tool cost some money but it will pay back much more because your
localiation cost will reduce a lot.

Finally, Sisulizer has great free support!
http://www.sisulizer.net

Best regards,
Jaska

[Nancy Anthracite]

Could you point me at a list of the lanuages it supports, please? I have folks
from all over the world asking about translating CPRS, so I would like to
know.

Best regards,
Jaska

--
Nancy Anthracite

[kdt...@gmail.com]

On Jun 3, 1:37 am, Jaska <jaakko.salmen...@gmail.com> wrote:
...

>
> The tool cost some money but it will pay back much more because your
> localiation cost will reduce a lot.
>
> Finally, Sisulizer has great free support!http://www.sisulizer.net
>
> Best regards,
> Jaska

Thanks for pointing out this product.
I presume you are with the company, so let me ask about allowed uses.
I had a hard time telling from the web page of this product (and
others) regarding whether there was any royalty charges. I.e. we plan
on giving away the product and would not want any restrictions on
circulation.
So am I correct that we pay for a developer license, but then there is
no further charges?

Kevin

[kdt...@gmail.com]

On Jun 3, 7:43 am, Nancy Anthracite <nanthrac...@verizon.net> wrote:
> Could you point me at a list of the lanuages it supports, please? I have folks
> from all over the world asking about translating CPRS, so I would like to
> know.
>

Nancy,
We will see how he replies, but from what I saw of these translation
programs, there is no limitation. It is just about string
substitution. So whatever characters can be display are allowed. I
saw one program that was using oriental characters. I'm not sure
about languages that are written from write to left, though.

Kevin

[Nancy Anthracite]

I thought there was some sort of automatic first pass translation and then
your personal experts took over. Maybe I misinterpreted.

If it is string translations, it is probably very similar to what Chris
Richardson and Marcus Werner are trying to do for VistA. As I understand it,
it is pull out the words and give each phrase a variable name, put them in a
table, make one column for each language and them stuff them back in on the
fly if need be. That is a bit simplistic, I know. However, with the number
of things there are to translate, 300,000 I think he said, even if it were
that "simple", it would not be easy!

Kevin

--
Nancy Anthracite

[kdt...@gmail.com]

Yes, what you describe is very similar to what I saw when going
through the programs. The advantage is that there are not quite as
many things to translate as would be in VistA server.

But it does argue for using one of the methods that lets users do
their own translation, then circulate their translation files.

Kevin

[kdt...@gmail.com]

On Jun 1, 11:47 pm, "kdt...@gmail.com" <kdt...@gmail.com> wrote:
...
>
> Then:
> Look, Delphi has built-in internationalization!http://delphi.about.com/library/weekly/aa102400a.htm

> I am going through some demo's about how to use it.
> ---------

...

> I think using the built-in Delpi functionality is the most
> straightforward way to start out (no extra cost).
> I would enjoy hearing other's thoughts about how to establish a
> translation project for CPRS.
>

I have found that the translation tools seem to come with Delphi 7
ENTERPRISE (which I have on my system), but not PROFESSIONAL (which
Nancy has on her system).

Delphi 7 Pro has documentation about view|translation manager, but I
can't seem to find it in the menu tree, and I suspect it really is
available only in the Enterprise version.

Enterprise costs quite a bit more than Pro I believe. So maybe using
third-party tools would be about the same cost overall.

Kevin

[kdt...@gmail.com]

I have been playing with DKLang, downloaded here:
http://www.torry.net/authorsmore.php?id=5792

It is open source!

It requires a package called tntUniCode that was originally available
from tntware or something. It was developed for missionaries. It has
been taken over and commercialized by TMS software, but the older
(still free) controls can be downloaded from here:
http://pivotcube.com/cgi-bin/index.cgi?page=downloads

The demo code that I compiled looks very cool.
Its a very simple form with one line "This is sample text". It then
has a drop down box with about 50 languages. Just selecting effect a
translation of the form to the selected language. Most of this is
coming from the control. All the translations are not stored in this
simple demo app. I need to look into this further.

Kevin

[kdt...@gmail.com]

OK, just 7 languages, not 50. And the translation is supplied from a
small text file in the directory with the program (*.lng)

Examples of translation files below.

Kevin

On Jun 3, 8:52 pm, "kdt...@gmail.com" <kdt...@gmail.com> wrote:
...

> The demo code that I compiled looks very cool.
> Its a very simple form with one line "This is sample text". It then
> has a drop down box with about 50 languages. Just selecting effect a
> translation of the form to the selected language. Most of this is
> coming from the control. All the translations are not stored in this
> simple demo app. I need to look into this further.
>
> Kevin

***********************************************************************************************************************
; $Id: French.lng,v 1.3 2006/08/08 13:57:59 dale Exp $
;-----------------------------------------------------------------------------------------------------------------------
; DKLang Localization Package
; Copyright 2002-2006 DK Software, http://www.dk-soft.org
;***********************************************************************************************************************

TargetApplication=DKLang_Simple_Demo
Author=Dmitry Kann
SourceLANGID=1033
LANGID=1036
Generator=DKLang Translation Editor v2.1
LastModified=2004-09-08 18:26:51

[fMain]
00000001=Forme témoin
00000003=Annuler
00000004=C'est un message témoin.

[$CONSTANTS]

;***********************************************************************************************************************
; $Id: German.lng,v 1.8 2006/08/08 13:57:59 dale Exp $
;-----------------------------------------------------------------------------------------------------------------------
; DKLang Localization Package
; Copyright 2002-2006 DK Software, http://www.dk-soft.org
;***********************************************************************************************************************

TargetApplication=DKLang_Simple_Demo
Author=Dmitry Kann
SourceLANGID=1033
LANGID=1031
Generator=DKLang Translation Editor v2.1
LastModified=2004-09-08 18:26:51

[fMain]
00000001=Beispielform
00000003=Abbrechen
00000004=Das ist eine Beispielmitteilung.

[$CONSTANTS]

[isiticov]

Hi Kevin,

On 2 июн, 07:47, "kdt...@gmail.com" <kdt...@gmail.com> wrote:
> I will add here that one of the cool features made available by a few
> of the projects is the ability to let users themselves do the
> translation as they go. Kind of like "crowd-sourcing" or the

> wikipedia effect.http://devtools.korzh.com/localizer/

> does this (and I think tsilang does as well).
>

Yes, TsiLang does this as well and you can see the article describing
this at http://www.tsilang.com/press/en/creating_multilanguage_applications_translated_by_users.html.
Feel free to ask me any questions you about TsiLang. :)

Best regards,
Igor Siticov.

[Jaska]

> So am I correct that we pay for a developer license, but then there is
> no further charges?

Yes. You are right. No further charges.

Jaakko

[Jaska]

> Could you point me at a list of the lanuages it supports, please? I have folks
> from all over the world asking about translating CPRS, so I would like to
> know.

Sisulizer supports all the languages that Windows supports. Currently
there are over 200 language and locales support by Windows. All of
them are also supported by Sisulizer.

In addition you can add your own languages. You just define the name,
ISO code, Windoes language code, and script the language uses.

Best regards,
Jaakko

[j...@resulture.com]

Quote: "If it is string translations, it is probably very similar to what Chris

Richardson and Marcus Werner are trying to do for VistA

.  As I understand it,

it is pull out the words and give each phrase a variable name, put them in a
table, make one column for each language and them stuff them back in on the
fly if need be.  That is a bit simplistic, I know.  However, with the number
of things there are to translate, 300,000 I think he said, even if it were

that "simple", it would not be easy!" NA

- would it be possible to have an estimate on the various parts of VistA with regard to translation.
[I guess the estimate of 300.000 'things' to be translated goes for the complete FOIA version of VistA].

What's the round estimate for VOE/WEHR (if any) and the different parts - especially CPRS. And what are we talking about in terms of 'man-years' of translation?
Has WorldVistA decided (alternatively: is going to decide soon) on a strategy in common - or is this the state of affairs - and is the above mentioned project by CR an MW funded in any way.

Thanks in Advance.

Jan Blauenfeldt

NB: I am of course aware of the the BEA Logic solution for Mexico and the Sanchez general Spanish translation thanks to the kind information previously provided by Nancy and Joseph.

[Chris Richardson]

More like 160K for the routines.  We need to do the same for the tables as well.  We were using the DIALOG file and had quite a lot done on this.

[Nancy Anthracite]

No funding. I can tell you that.

Man years,I have no idea, but I would talk to David Fonseca Sanchez, tell him
about these new tools and ask him what he thinks. He did it the hard way.

Thanks in Advance.

Jan Blauenfeldt

--
Nancy Anthracite

[K.S. Bhaskar]

Nancy Anthracite wrote, On 06/03/2007 10:18 AM:
>
> I thought there was some sort of automatic first pass translation and then
> your personal experts took over. Maybe I misinterpreted.
>
> If it is string translations, it is probably very similar to what Chris
> Richardson and Marcus Werner are trying to do for VistA. As I
> understand it,
> it is pull out the words and give each phrase a variable name, put them in a
> table, make one column for each language and them stuff them back in on the
> fly if need be. That is a bit simplistic, I know. However, with the number
> of things there are to translate, 300,000 I think he said, even if it were
> that "simple", it would not be easy!

[KSB] Alex Diez can speak to this better than I can, but I understand
that one limitation IMSS ran into is that word order is different in
Spanish and English. Thus, a string translation approach would not work
on the server. Hence, they decided to leave the server as roll and
scroll VistA in English.and to translate in the middleware.

-- Bhaskar

[Chris]

Rambling comments...

Localization vs. Internationalization - http://www.w3.org/International/questions/qa-i18n

Good briefs... http://www.sisulizer.com/translation/vcl/Internationalization.html
and http://www.sisulizer.com/translation/vcl/Unicode.html

Also found LMD Innovative which sells a product called ElPack.
http://www.lmdinnovative.com/products/vcl/

Anyone notice how the screenshots of the demo [
http://delphi.about.com/library/weekly/aa102400b.htm ] have what looks
like a HardHat?

Chris

[Ben Mehling]

On 6/1/07, kdt...@gmail.com <kdt...@gmail.com> wrote:
>
> I would like to post here some interesting finds I have encountered
> today while researching the issue of translating CPRS into other
> languages (Internationalization).

Besides _ALL_ the normal I18N and L10N issues any piece of software
would face, here's a few other things we considered before embarking
on this path OpenVista:

1) Although translation on the server can be accomplished via the
DIALOG file, it still requires many, many changes to the application
routines. At that point, the server code would essentially be forked
from the VA -- or at the very least merging in VA patches would be
incredibly time consuming. (Yes, we've heard for many years that the
VA will be accepting patches back in from the community, but to accept
patches on this scale seems totally unlikely.)

2) Unfortunately, in many places, a simple $$EZBLD^DIALOG( ) call will
not work because the user output is built on the fly.

3) There are numerous places in the code where logic, unfortunately,
is based on literal strings -- meaning that a simple IF statement can
be thrown off, when you pass back the translated string. (This will
burn you just trying to change the English words in server-driven
labels and dialogs too!)

OpenVista CIS was written with the intention of internationalization.
The underlying toolkit (GTK+: http://www.gtk.org/) uses a text
rendering layer (Pango: http://www.pango.org/) designed with this in
mind. While this is only a small piece of the puzzle, I thought I'd
point out that CIS already "speaks" different languages. Included in
the open source release is a nearly complete Portuguese lang file and
partially complete Spanish lang file.

- Ben

[Chris Richardson]

Well, Ben, much of what you and Kevin say is kind of true. But there are
some mitigating circumstances to some of your assertions. My responses are
in square brackets, []. See below;

Best wishes; Chris

----- Original Message -----
From: "Ben Mehling" <ben.m...@medsphere.com>
To: <Hard...@googlegroups.com>

Sent: Monday, June 04, 2007 9:35 PM
Subject: [Hardhats] Internationalization (Language Translation) of CPRS

>
> On 6/1/07, kdt...@gmail.com <kdt...@gmail.com> wrote:
>>
>> I would like to post here some interesting finds I have encountered
>> today while researching the issue of translating CPRS into other
>> languages (Internationalization).
>
> Besides _ALL_ the normal I18N and L10N issues any piece of software
> would face, here's a few other things we considered before embarking
> on this path OpenVista:
>
> 1) Although translation on the server can be accomplished via the
> DIALOG file, it still requires many, many changes to the application
> routines. At that point, the server code would essentially be forked
> from the VA -- or at the very least merging in VA patches would be
> incredibly time consuming. (Yes, we've heard for many years that the
> VA will be accepting patches back in from the community, but to accept
> patches on this scale seems totally unlikely.)
>

[The changes required to the code are accomplished by my extractor code. As
I identify the literal strings and accession them into the DIALOG file, I
also re-instrument the code as well by building the new routines in a new
directory with the calls in place of the literals. Is this a complete fix,
of course not, but it is a good 85 to 90% fix for the whole set of routines.
The test bed I ran this code on was an 800 mhz Pentium 3 laptop and took
about 45 minutes to scan all of the VistA routines and generate the new
routines. Other demands and it seemed that no one was really interested, I
turned to other areas to help. This was demonstrated at the last WorldVistA
Community Meeting in Seattle a couple of years ago. It ran during one of
the sessions.

The code is also written to be able to run against just a single routine or
a namespace of routines so that local mods can be included in the
internationalization. I have another routine which breaks the 160,000 terms
out into about 500 sheets of 300 terms each so that the translations can be
begun in parallel making the most of sweat equity to get the translations
done and the translations reloaded into the DIALOG file. This can make
adding new phrasiology into the DIALOG file easy to do in a timely fashion.
Adding new languages should be a fairly parallel operation.]

>
> 2) Unfortunately, in many places, a simple $$EZBLD^DIALOG( ) call will
> not work because the user output is built on the fly.
>

[True, but thankfully these are not as prevalent as reported and are
actually few and far between. It can't be worse than the pathetic Spanish
Pharmacy Label approach that was done a few years ago which turned into a
support night-mare with the duplicate code that needs to be retained and
changed in parallel every associated single language routine each time the
base code needs modification for English.

The approach using the DIALOG File does have the advantage that multiple
languages can be accommodated on the same configuration making it an
end-user choice as to what language the end user will see. Choice is what
it is all about. As we become more and more of our applications get more
integrated into the direct care of the patient, being able to provide these
questionares in a familiar language will reduce the reluctance and confusion
that these interfaces can cause the patient. Mental Health is such a
package where the end user is the patient, and not the clinician.]

>
> 3) There are numerous places in the code where logic, unfortunately,
> is based on literal strings -- meaning that a simple IF statement can
> be thrown off, when you pass back the translated string. (This will
> burn you just trying to change the English words in server-driven
> labels and dialogs too!)
>

[True again, but again, this is part oif the last 10 to 15% that needs to be
completed. And this is not unsurmountable.]

>
> OpenVista CIS was written with the intention of internationalization.
> The underlying toolkit (GTK+: http://www.gtk.org/) uses a text
> rendering layer (Pango: http://www.pango.org/) designed with this in
> mind. While this is only a small piece of the puzzle, I thought I'd
> point out that CIS already "speaks" different languages. Included in
> the open source release is a nearly complete Portuguese lang file and
> partially complete Spanish lang file.
>

[This approach does generate some interesting translations and there are
regional differences that I am wondering if this will be able to arrange.
One of the trickiest is the use of cultural idoms and how they translate to
another language. Spanish is not just Spanish. There is Mexican Spanish,
and Cuban Spanish as well as the Spanish of Peurto Rico (where the Spanish
Pharmacy Labels were done), as well as the Castillion Spanish. More
variants exist which can be relatively confusing to each other. Culturally,
one does not "miss a bus", but "The bus runs away from you.". These are
solved by having native speakers do the translations and then having good
regression testing (much that can be automated).

Try converting one language to another and use that resultant phrase to
translate back into the original language. The result usually has little
correspondence with the original text. While this is a goal, the best
linguists are still a ways away from a meaningful representation. This
cannot be just dismissed. This automated translation is still from a
complete science. It is better than it was, but it is still a long way off
in a meaningful way.]
>
> - Ben
>
> >
>
>

[Brad Taylor]

Chris,

<snip>

> > OpenVista CIS was written with the intention of internationalization.
> > The underlying toolkit (GTK+: http://www.gtk.org/) uses a text
> > rendering layer (Pango: http://www.pango.org/) designed with this in
> > mind. While this is only a small piece of the puzzle, I thought I'd
> > point out that CIS already "speaks" different languages. Included in
> > the open source release is a nearly complete Portuguese lang file and
> > partially complete Spanish lang file.
> >
> [This approach does generate some interesting translations and there are
> regional differences that I am wondering if this will be able to arrange.
> One of the trickiest is the use of cultural idoms and how they translate to
> another language. Spanish is not just Spanish. There is Mexican Spanish,
> and Cuban Spanish as well as the Spanish of Peurto Rico (where the Spanish
> Pharmacy Labels were done), as well as the Castillion Spanish. More
> variants exist which can be relatively confusing to each other. Culturally,
> one does not "miss a bus", but "The bus runs away from you.". These are
> solved by having native speakers do the translations and then having good
> regression testing (much that can be automated).
>
> Try converting one language to another and use that resultant phrase to
> translate back into the original language. The result usually has little
> correspondence with the original text. While this is a goal, the best
> linguists are still a ways away from a meaningful representation. This
> cannot be just dismissed. This automated translation is still from a
> complete science. It is better than it was, but it is still a long way off
> in a meaningful way.]

I think you might be a bit confused about how CIS's translations work,
so let me explain its approach in further depth.

OpenVista CIS's internationalization system is built upon GNU
gettext[1], the defacto framework for translating text strings on Linux.
(Of course, it also works on Windows, Mac, and pretty much every
operating system under the sun, but that's besides the point.)

To put it simply, gettext operates by generating a "template" (called a
"pot") file from source code, containing all the translatable text
strings in the application.

A human translator will then be provided the template file, and he or
she will manually translate every string (there are about 3,047 in CIS)
to create a language file (called a "po"). Then, when CIS is run, it
will determine what language to use, and attempt to load up the
corresponding language file.

This language file is specific to both the language code (i.e: Spanish =
es) _and the region_ (i.e.: Argentina = AR), and must be generated by
real translators. What gettext provides is a simple interface for
translators to do their job without having to look at source code, and
to de-couple translations from the application to be translated.

We have two partial translations currently, Argentinean Spanish (es_AR)
and Brazilian Portuguese (pt_BR), but with gettext's flexibility, any
language can be represented.

If you're interested, I suggest you check out gettext's online manual[2]
for more information, or check out the po/ directory in CIS source[3].

Pango -- the text rendering layer Ben mentioned -- simply renders
Unicode strings to the screen, but it is an integral part of all of this
since it has the capability to render complicated scripts like Chinese,
Japanese, Thai, Urdu, Farsi, Arabic, Tamil, etc.

Hope this helps,

-Brad

--
[1] http://www.gnu.org/software/gettext/
[2] http://www.gnu.org/software/gettext/manual/gettext.html
[3]
http://downloads.sourceforge.net/openvista/openvistacis-0.9.1-source.zip

[kdt...@gmail.com]

Hey all,

I have been looking closely at the DKLang code found here:
http://www.dk-soft.org/products/dklang/

And I would like comments from group members about the advisability of
using it. I like it because it is explicitly freeware, yet seems up
to the job.

It is built on TntUniCode functionality, also freeware.

Here's how it would work.
Steps:
1. Install the DKLan component into my Delphi.
2. Drop the component onto all CPRS frames.
3. Add some brief code to allow run-time language switching.
4. Recompile, run, and exit.
5. Distribute CPRS world-wide
4. Individuals in various countries can use provided freeware language
editor to create language files (e.g. German.lng,
Spanish.lng,Russian.lng) This is where the actual translations will
occur.
5. Run CPRS. It scans for *.lng files and automatically allows user
to select the specified language, and changes strings to translation
provided in .lng file.

Anyone interested?

Kevin

[Chris Richardson]

Well, Brad; No I think that they are doing pretty much what the DIALOG file
was designed to do as well. Our seems easier to load new pharses and also
be able to incorporate database values using the DIALOG File. The phrases
are also context derived within the medical specialty so some of the phrases
may be slightly different than when taken out of context and translated.
The approach you described with gettext seems very much like the DIALOG
file, but is likely to be slower than using MUMPS globals to store the
translations

No, the UNICODE folks have been surprisingly culturally insensitive in the
past. As the Chinese proposal, ISO-10646, was a means of defusing the
cultural bias of the original UNICODE effort. Now it seems that UNICODE
realized that they couldn't steam-roll the international community, they
adopted much of the ISO-10646 proposal, got themselves a couple of planes in
the coding scheme and then put their name on the whole poject and declared
victory. Pretty typical of this Wester approach. Who cares, it looks like
it is still an ISO-10646 model with Unicode's label on it.

The DIALOG file was designed for I18N back in the early 90's. The idea
was pretty solid, and the mechanism of extracting the dialog phrases and
approach are still valid. The extraction of the terms out to spreadsheets
for medical transcriptionists is a great way to parallel the work that needs
to be done to add a new language. All of the variants can be accommodated
and a heirarchy established of other languages that a user could tolerate.
Not all translations get made at the same time. The word processing fields
will need additional work, but maybe not that much more. Who knows, maybe a
chimera of the two methods might be in order. The approach I am espousing
will work with future enhancements.

[Ben Mehling]

On 6/5/07, Chris Richardson <r...@rcresearch.us> wrote:
>
> Well, Brad; No I think that they are doing pretty much what the DIALOG file
> was designed to do as well. Our seems easier to load new pharses and also
> be able to incorporate database values using the DIALOG File.

I'm not sure I understand -- you plan to use the DIALOG file to hold
the various translations for labels, buttons, etc. on the client?
Brad is referring to the I18N and L10N technologies built into the CIS
client.

- Ben

[Chris Richardson]

No, server side. If you want to use it one the client side, good luck. It
will be interesting to see what you get.

----- Original Message -----
From: "Ben Mehling" <ben.m...@medsphere.com>
To: <Hard...@googlegroups.com>
Sent: Tuesday, June 05, 2007 9:46 PM
Subject: [Hardhats] Re: Internationalization (Language Translation) of CPRS

>

[kdt...@gmail.com]

Speaking of such, I am considering the client side. I have a way that
I can display UNICODE in CPRS, but I wonder if the RPC broker can pass
UNICODE strings? I'm not quite sure how they are encoded.

Would there be value in having the translation files for CPRS being
stored in the server?

Kevin

[Woodhouse, Gregory J.]

I don't think the Broker can be used reliably for 8-bit text, but you could use the same convention used in Java (and elsewhere) by escaping the numeric representation with \U.

In response to the broader question, Unicode is explicitly not an encoding, but an abstract system of code points. There are various encoding schemes likpe UTF-8, UTF-16, and UTF-32 (where UTF stands for Unicode Transformation Format).
--------------------------
Sent using BlackBerry

[K.S. Bhaskar]

If anyone wants to play with Unicode, please take a look at any GT.M
V5.2-000 release. The VistA Office EHR 2.3.1 bundles I made use GT.M
V5.2-000. Although VistA itself doesn't turn on or use Unicode (UTF-8
internally) support, it's there in the GT.M distribution. GT.M support
for Unicode / ISO/IEC-10646 (the standards track each other) is
described at
http://www.fidelityinfoservices.com/user_documentation/GTM-Unicode/GTM_Unicode_Support.html

Regards
-- Bhaskar

[kdt...@gmail.com]

I wonder if Cache' supports Unicode. If so, then I feel there should
be a kernel extension that allows VistA server code to start being
Unicode compliant. The DIALOG file could hold Unicode. But based on
Chris Richard's prior comments, perhaps it already is...

Kevin

On Jun 7, 7:18 am, "K.S. Bhaskar" <ks.bhas...@fnf.com> wrote:
> If anyone wants to play with Unicode, please take a look at any GT.M
> V5.2-000 release. The VistA Office EHR 2.3.1 bundles I made use GT.M
> V5.2-000. Although VistA itself doesn't turn on or use Unicode (UTF-8
> internally) support, it's there in the GT.M distribution. GT.M support
> for Unicode / ISO/IEC-10646 (the standards track each other) is

> described athttp://www.fidelityinfoservices.com/user_documentation/GTM-Unicode/GT...

[kdt...@gmail.com]

I haven't gotten any replies for my request for comments. I am going
to go forward with using DKLang code to try to get CPRS ready for
internationalization.

Kevin

[Woodhouse, Gregory J.]

It does, but I don't know what problems installing Unicode support might cause for VistA (as it is now). When setting up a Caché system (for development purposes) I've always chosen *not* to install Unicode support. That being said, I'd love to see a version of VistA that supports Unicode properly on both platforms. Right now, the biggest problem may be that no one's tried to do it!
--------------------------
Sent using BlackBerry

----- Original Message -----
From: Hard...@googlegroups.com <Hard...@googlegroups.com>
To: Hardhats <Hard...@googlegroups.com>
Sent: Thu Jun 07 09:22:17 2007
Subject: [Hardhats] Re: Internationalization (Language Translation) of CPRS

[Hellevi Ruonamaa]

RPCBroker works fine with 8-bit texts, we have used it for ten years
now.

On Jun 6, 5:04 pm, "Woodhouse, Gregory J." <Gregory.Woodho...@va.gov>
wrote:

[K.S. Bhaskar]

Since ASCII is a proper subset of UTF-8, a first step may be to try an
existing, unaltered, version of VistA with Uncode support turned on in
both MUMPS platforms, and verify that things still run correctly.

-- Bhaskar

Woodhouse, Gregory J. wrote, On 06/07/2007 10:56 AM:
> It does, but I don't know what problems installing Unicode support might

> cause for VistA (as it is now). When setting up a Cach� system (for

[kdt...@gmail.com]

Is 8-bit enough for Unicode? I don't know much about Unicode, but I
think that it is stored in 8-bit chunks. It just uses codes that
cause downstream bytes to be interpreted differently. At least that
is supposedly how Delphi stores them internally.

Kevin

[K.S. Bhaskar]

8 bits is not sufficient for Unicode / ISO/IEC-10646, but an 8-bit byte
(an octet to be precise) suffices for most European languages.

The encodings for Unicode include UTF-16, which is a pair of 2-byte
character encodings (one little endian and one big endian) and UTF-8,
which is a variable length encoding (and which GT.M uses internally for
Unicode support, although it is able to write UTF-8, UTF-16BE and UTF-16LE).

-- Bhaskar

[Woodhouse Gregory]

On Jun 13, 2007, at 6:49 AM, K.S. Bhaskar wrote:

8 bits is not sufficient for Unicode / ISO/IEC-10646, but an 8-bit byte 

(an octet to be precise) suffices for most European languages.

The encodings for Unicode include UTF-16, which is a pair of 2-byte 

character encodings (one little endian and one big endian) and UTF-8, 

which is a variable length encoding (and which GT.M uses internally for 

Unicode support, although it is able to write UTF-8, UTF-16BE and UTF-16LE).

-- Bhaskar

Right. UTF-8 is an 8-bit encoding with the property that the 7-bit ASCII characters are represented in their usual form. The first few bits of a document (from 2-4, I don't know the exact number) identify the encoding scheme. In any case, UTF-8 is indeed a variable length encoding, rather like a Hamming code. This means that some unicode characters will require more than 2 bytes to represent. For textual documents that are not primarily Roman, UTF-8 will not be the most economical encoding scheme, and an option like UTF-16 or UTF-32 will be preferable. I don't know if UTF-32 is used much. The most common schemes are UTF-8 and UTF-16. There's a Wikipedia article, Comparison of Unicode encodings that provides more details.

"Interaction is the mind-body problem

of computing." --Philip  L. Wadler

[Chris Richardson]

8 bits is not enough for all of Unicode. It may be for most of the European
languages, but Kanji and Katakana are both 16 bit codes already without
mapping them into Unicode. This is why ISO-10646 was such an advance of the
limitations of Unicode (professing 16 bits required/character). If we are
going to be a world-nation community, we need to look beyond 16
bit/character. 32 bit opens some real opportunities for specialized
character sets for math, science, and chemistry as well as the character
sets for the rest of the world..

----- Original Message -----
From: <kdt...@gmail.com>
To: "Hardhats" <Hard...@googlegroups.com>
Sent: Wednesday, June 13, 2007 6:06 AM
Subject: [Hardhats] Re: Internationalization (Language Translation) of CPRS

>

[Jim Self]

Although I agree with the substance of what everyone in this thread has
stated, I believe the answer to Kevin's original question is "Yes". The
UTF-8 encoding can be used to transmit and store Unicode characters of
any size. Kevin's mention of Delphi seems to be a reference to UTF-8.

As Gregory noted, UTF-8 is a variable length encoding that is generally
the most economical encoding for European languages because ASCII
characters can be represented with a single byte.

--

---------------------------------------
Jim Self
Systems Architect, Lead Developer
VMTH Information Technology Services, UC Davis
(http://www.vmth.ucdavis.edu/us/jaself)
---------------------------------------
M2Web Demonstration with VistA
(http://vista.vmth.ucdavis.edu/)
---------------------------------------

[kdt...@gmail.com]

Thanks Jim. My point was that Hellevi said that the RPC broker worked
with 8-bits, so I wanted to ensure that it would not be a bottleneck.
But it sounds like it can be used with UTF-8 (does UTF mean Unicode
Text Format?). So as we look at the pieces of the puzzle, does it
seem that the RPC broker is OK? Or will a need to use more than UTF-8
be needed? Would the RPC broker need to be revised?

Kevin

[Greg Woodhouse]

On 6/14/07, kdt...@gmail.com <kdt...@gmail.com> wrote:
>
> Thanks Jim. My point was that Hellevi said that the RPC broker worked
> with 8-bits, so I wanted to ensure that it would not be a bottleneck.
> But it sounds like it can be used with UTF-8 (does UTF mean Unicode
> Text Format?). So as we look at the pieces of the puzzle, does it
> seem that the RPC broker is OK? Or will a need to use more than UTF-8
> be needed? Would the RPC broker need to be revised?
>
> Kevin
>

UTF = Unicode Transformation Format

I would not assume that the RPC Broker would work properly with UTF-8
simply because with works properly with 8-bit character sets (like
ISO-8859-1). The problem is that there would be no way to recognize
embedded content as UTF-8. VistaLink should be safer because the
message payload is a CDATA section of an XML document. But it is
designed for Java, not Delphi.

--
Gregory Woodhouse
gregory....@gmail.com
"The whole of science is nothing more
than a refinement of everyday
thinking." -- Albert Einstein