07010159.txt 01-Jul-00


Subject: Multilingual apps
From: "Will Chapman" <willchapman@dial.pipex.com>

I'm just about to emabrk on my first foreign language
  version fo a VO2.5 app.
I'm trying to locate Janno's vodefiner.exe (the link on
  KNowVO is broken) and have downloaded a couple of papers
  from past Technicons...
Any tools, techniques, advice...
Many thanks......

Will Chapman


Subject: Re: Multilingual apps
From: arg@mail.EUnet.pt (Adriano Rui Gominho)

Will,

I'm currently using the following techniques:
I have a VO App that mantains a "DataBase" of expressions as
  well as each one's translation into selected languages.
  This app has an option to generate two prg files.
One has the form:
~~~~~~~~~~
Defi is_procurar_entidade:=1
Defi is_nomes:=2
Defi is_procurar:=3
Defi is_nomes_completos:=4
...
~~~~~~~~~~~~
The define token is built using the expression on the native
  language, replacing "ilegal" characters - like spaces -
  with "_", and it assigns a numeric ID to each token.
The second file is dependent on the laguage choosen and is
  something like:
~~~~~~~~~~~~~~~~~~~~
Resource StringTable
  Begin
  1, "Search Entity"
  2, "Name"
  3, "&Search"
  4, "&Whole name"
  5, "All names"
...
  End
~~~~~~~~~~~~~~~~~~~~
These two files are externally linked into the international
  application.
Also, the "String Maintenance App" has two features named
  "FunctionIt" and "CaptionIt" which copies to the clipboard
  something like:
  LoadResString("",IS_MODELO1)
  <'',is_modelo1>
The first form - Functionized - can be pasted directly in
  the code where normally you would use just "modelo:"
The second form - Captionized - can be pasted inside any
  caption propriety on the WED. VO automatically generates
  'LoadResString("",IS_MODELO1)' from '<'',is_modelo1>'

Now, your code and forms are still readable on your native
  language and you can hapily stick to it.
Example:
  self:odcscVehicle:caption:=LoadResString("",IS_MODELO1)
Advanced features:
~~~~~~~~~~~~~~
You will need a function that takes a string like...
"Found %n records"
... and an array of token/string value pairs like
 {{"%n",ntrim(nrecs)}}
...and returns a formatted string like:
"Found 50 records"
This is necessary because you cannot guarantee how a string
  like that will be built on foreign languages. Remember,
  NEVER use concatenated strings!
The "String Maintenance APP" should be built in such a way
  that you can ship it to a translator who would use it to
  translate the expressions to another language and returns
  the work done in the form of a file backup.
A usefull feature would be to enable it to read your app's
  aefs directly reporting about unused strings.
With a litle tweak, the generated files could be externally
  linked on a DLL instead of the app itself, enabling you to
  maintain separate DLLs for each language.
Hard learned tips:
~~~~~~~~~~~~~~
Take in account that English is one of the languages that
  requires less screen real estate. German is on the oposite
  side<g>
Collation Sequences, and national characters: good luck<g>
Colors, and bitmaps: Make sure you understand how they will
  be interpreted on foreign countries...
Don't try to internationalize your String Maintenance App or
  else you can get yourself on a situation where you need
  to compile it but you need first to use it to generate the
  prgs, and you've just lost the executable. This is the
  only case I can imagine where the executable is as
  valuable as the sources<g>
My two euros<g>

regards
Adriano


Subject: Re: Multilingual apps
From: "Pavel Vetesnik" <Pavel.Vetesnik@podvodnik.cz>

Hi Will,

I create multilingual apps over 2 years. This topic and
  discussion about it can become very huge because it's
  complexity.
The basic internationalization of VO app is simple:
- put all texts used as screen output to separate DLL
- upon users request load that DLL using LoadLibrary()
  function
- the function you use to get strings from that DLL is
  called LoadResString()
- texts in editors (menu, window, fieldspec) you write using
  this syntax:

<"HelpAbout", HELPABOUT, cLangDLL>, which will be
  automatically preprocessed to LoadResString(""HelpAbout",
  HELPABOUT, cLangDLL)
But what I've written above works only in the best situation
  - when languages you want to use uses compatible
  codepages. If you want to use different languages - like
  English/Japanese then you also need to to switch to font
  which supports Japanese and use correct codepage. And if
  you want to make translation to right-to-left languages -
  like Arabic or Hebrew - then don't forget also to change
  appearance of windows. Everything what are you used to see
  on right (like scrollbar or close button) should be on
  left.
But I must say that I have no experience with this. I also
  don't know how to fill DBFs with double-byte characters
  (like Chinese).
Useful NG in help can be
  microsoft.public.win32.programmer.international.
If languages you want to use are using western charsets,
  you'll have no problems. I had problems with translating
  of Czech (Central European) to French (Western). I was
  only 98% succesfull and some French characters were not
  displayed correctly (like "e" with apostrophe for
  example).
Of course Unicode can be the solution. But in this case you
  must use font which uses Unicode (like Lucida Sans
  Unicode). And don't forget the different support of
  Unicode in W95 and WinNT!
The good news can be that Windows Resource Compiler always
  compiles in Unicode. But if you want to use Unicode
  character don't forget to put "L" before quotations marks
  to inform compiler to use Unicode ID:
====
RESOURCE LittleTest STRINGTABLE
Language LANG_CZECH, SUBLANG_DEFAULT
BEGIN
1, L"Theta (\x0298) embedded"
END
====
If you are interested I can prepare some simple example of
  technique I use.
I do it without Janno Hordijk's VODEFINER tool.
PS: I found that drunk people better understands each other.
  Maybe your users will be happier with whiskey <g>.

Greetings from
Pavel Vetesnik


Subject: Re: Multilingual apps
From: "Paul Piko" <paul@piko.com.au>

Will,

Try this:
http://home.wxs.nl/~hordi036/default.htm

Paul Piko


Subject: Re: Multilingual apps
From: F.Eggenberger <proficonNOprSPAM@bluewin.ch.invalid>

Hi Will

Didn't know that so many people are dealing with
  multilingual applications.
In addition to Adriano and Pavel:
1. LoadResString function and <"HelpAbout", HELPABOUT,
  cLangDLL>
There is no need to reference via DEFINE HELPABOUT := ...
  statement.
As the second parameter you can use a numeric value as well,
  IMO this makes your live easier. I do the following:
RESOURCE cText STRINGTABLE
BEGIN
   ....
   1000, "Yes"
   1001, "No"
   ...
END
In the WED I use <'T1000',1000,gcLangDll> to make the
  reference to "Yes". In case of a missing string I would
  see 'Txxxx' on the screen, and I know exactly where I
  haven't completed my homework.
Using this technique, I found that VO converts
<'Txxxx',xxxx,gcLangDll> to LoadResString(...) only for
  values<64K
In addition I have a function TextNo(nText) e.g. to set
  captions etc.... This function returns the requested
  string or if the string is not defined 'Txxxx'. This
  function isolates the LoadResString function from my code,
  so if I ever have to change the way of loading strings,
  it's will be easier to do. Beside of that, it's less
  typing work <g>.
2. Languages
As Adriano said, German takes a lot of screen space, but
  don't forget Italian!
To get around this problem, I use to put the field
  descriptions (7-8 point char size) on TOP of the control,
  thus using the space between the controls. It may be
  unusual, but there are additional ergonomic reasons too,
  to do it this way.
To achieve this, I have a method DisplayLabels() which scans
  through the aControls[]-array, takes the caption-property
  for each of the controls, creates a FixedText object and
  puts the FT on top of the control. By doing this, I can
  avoid quite a number of FT-objects in the window painter
  (and a lot of work).
If you are interested, I will be glad to send you some code
  and some screenshots.
3. Switching the language
Depending on your application and user's needs, you should
  think about the functionality of changing the language
  while running the program, including the implication to
  change search arrays (ComboBoxes...), code files etc.
4. different cultures
Don't underestimate this aspect! Think about the meaning of
  black and white in US, Australia, India ....
Did you ever hear from FORD having bad luck with their car

  models 'Pinto' and 'Nova' in Spanish speaking countries?
  Ask a Spanish speaking friend to explain the reasons.
5. Database codes
Don't use alpha codes (e.g. 'M' for male, or 'H' for Health
  insurance etc.), you might be tempted to use them for
  input/output and finally end up with a lot of work to
  translate these codes (This happened to me 10 years ago,
  when converting a CLIPPER app :-(( ).
Use numerics as '0', '1', '2' instead. This makes sure, that
  a sort order (e.g. ComboBox) doesn't change when you're
  changing the language.
If you have to deal with legacy data using alpha codes,
  NEVER let the user see them!
Example: Many people from US are scalding their hands when
  visiting the French-speaking part of Canada, simply
  because 'C' on a water faucet stands for CHAUD (=hot) and
  not for COLD ?!?
6. Charactersets
As Pavel said, charactersets can get really cumbersome, in
  German the so called 'Umlaute' may (will) change sort
  orders, may influence your search and select procedures. I
  would suggest to buy the local OS-versions to make sure,
  that your tests will find as many problems as possible,
  the users will find the rest ;-)
7. Fonts
Depending on the requested space and charactersets, you will
  have to chose the appropriate font. Your application
  should be able, to select different fonts for the controls
  (not only Sle's for descriptions, buttons, Listviews,
  browsers too) depending on the chosen language. I am using
  VoTools from Electric People to achieve this.
If you are using ReportPro, you should contact Larry Atkins
  for stringtables (I think there is a stringtable for
  German and Dutch available)
8. Translation
Be very careful when selecting a translating agency, many of
  them simply don't have the staff with enough knowlegde of
  the world where your application lives!
It may be better (and less expensive) to look for somebody
  having professional knowlegde of user's world and natively
  speaking the foreign language.
If there is anything I can do for you, let me know.

Florian Eggenberger


Subject: Re: Multilingual apps
From: Arena <arenainformaticaNOarSPAM@zaz.com.br.invalid>

Hello Will

I'm sure you'll get plenty of help here. This small group -
  more like a developers U.N. - is ver collaborative. Some
  hints:
1) Don't rely on your users' Control Panel International
  settings.
2) Use VO's international features: SetNatDLL(),
  SetInternational(), etc.
3) Be careful when using other tools to open DBF files, and
  also when sharing data with other apps.

4) If you use SQL Server or Oracle databases, configure them
  to the correct language.

HTH
Marcos Nogueira


Subject: Re: Multilingual apps
From: "Pavel Vetesnik" <Pavel.Vetesnik@podvodnik.cz>

I am just interested - what will happen in network
  application where people at each workstation has different
  international settings in control panel?
Corrupted indexes?

Pavel


Subject: Re: Multilingual apps
From: Arena <arenainformaticaNOarSPAM@zaz.com.br.invalid>

Hello Pavel

Yes, and also different results in ASort() and other similar
  methods and functions that depend on character sets and
  code pages.

HTH
Marcos


Subject: Re: Multilingual apps
From: Wolfgang Riedmann <wolfgang@riedmann.it>

Hi Pavel,

Yes.
Therefore is is highly recommended that anyone uses
  SetInternational( #CLIPPER ). In this manner the
  programmer has the control, and not the user.
There is one alternative: use a self defined function for
  string comaprisons with SetWinCompFunc() and
  SetClipCompFunc().

Wolfgang


Subject: Re: Multilingual apps
From: "Eric Hourant" <ehourant@echo-soft.com>

You should read the jean-Paul Bleau's papers about this
  subject. You can download his papers on
  www.ferlility.soft.
During the last CA-World, there was also a session of Jan
  Spaens. Check his papers on www.caworld.com, follow the
  ebusiness link.

HTH
Eric


Subject: Re: Multilingual apps
From: "Pavel Vetesnik" <Pavel.Vetesnik@podvodnik.cz>

Eric,

the www.ferlility.soft doesn't exist, don't you know the
  correct URL?

Pavel


Subject: Re: Multilingual apps
From: "Eric Hourant" <ehourant@echo-soft.com>

Pavel,

Sorry. the correct wed address is www.fertisoft.com

Eric