RE: multi language interfaces

Hi Arco,

We currently run a "Common European System" that runs in many European
countries (UK, Eire, France, Spain, Portugal, Germany, Italy, Switzerland,
The Netherlands, Belgium, Austria, Hungary, etc...).

Now there are MANY things you need to consider to do this properly:

1) You will want all DISPLAY and PRINT text data in the language of the
user.
2) You will want all customer-facing PRINT text data in the language of the
customer.
3) You will want to easily change your soft-coded text.
4) You will want to easily support your soft-coded text across all
languages/environments.
5) You will want to reuse as much soft-coded text as possible.
6) You will want to manage your changes across different production
machines.
7) You will want to present a COMMON look-and-feel across your applications.
8) You will want to ensure you can fit ALL text in ALL fields for ALL
languages.

This list is by no means exhaustive, but it gives you an idea of the things
you need to consider.

OK, here's how we do it:

We toyed with the idea of data in PF, and some applications still have a
residual amount still in place from the early days. However, the most common
repository of our soft-coded text is in Message Files. The simple reason for
using message files over Physical Files is that you can easily implement a
message ID directly into your DDS if you want to. As it is we don't. :-) It
also allows common handling of text literals and error message data.

The way we soft-code is to use a utility program that is called when each of
our display/print programs load. This porgram then retrieves the message
text for each field to be displayed/printed by the calling program (it is
called in a loop passing it the message IDs - usually in compile-time arrays
at the foot of the program). The fields are placed in the elements of an
array, which overlays a DS containing the soft-coded fields. So, once the
array is populated all screen/print fields are populated. Any message file
specific knowledge is encapsulated in the called program - you don't need to
know where your text comes from. The only concession we have on this point
is the fact that we have one message file for text/literals and another for
error messages. Although error message text is handled differently - as each
error occurs the error message text is displayed in a message subfile. Only
text literals are loaded up-front.

The extra advantage of retrieving the data in this way is that you have the
ability to format the data prior to use. This is used extensively by us to
allow an application-wide look-and feel. For example, we may have a message
ID for the literal "Customer". For a subfile heading the text may be
left/right adjusted. For a print field it may contain trailing formatting
characters (such as ". . . . . :"). For a print heading it may be aligned to
a central position and contain wrapping characters("______Customer______").
But the point is that it is ALWAYS the same literal - your user is presented
with a consistent interface. A further advantage is the fact that we can
pass the language code to this program and it will not use the default
(user) language, but it will use the language passed in. This means that we
can print documents in the language of the Customer. This is VERY important
if we are shipping goods to a customer in Barcelona from a warehouse in
Madrid! Or even worse - cross border shipping to Portugal!! Imagine if
either of those documents were in Castilian and not Catalan or Portuguese!!!
:-) 

Regarding how we implement this:
All of our database data is kept in separate libraries - the program objects
are common but the data is separated by business entity. This is almost
always divided down country borders, but is not always the case. So, we keep
our language-specific data in libraries separate from both - these
language-specific libraries are added to the user's library list, above the
data libraries, when the user signs on. This means, for example, I can work
in ANY European country, over any set of data, but still be presented with
the screen literals in English.

We have two COMMON messages files - one for our literals and one for our
error messages. These reside on the Development machine. Whenever we
add/amend message descriptions to either of these message files the
additions/amendments are migrated to the production environments
automatically. These will all be in English, it is the responsibility of the
staff in each country to overwrite the language-specific version with the
appropriate text.

The message IDs are usually descriptive (as much as you can) - for example:
All of our function keys are soft-coded so for F12=Previous we'd have
FK0012A, for F12=Cancel we'd have FKO012B, etc... This makes quick scanning
for previously defined message descriptions easier. We also have a suite of
"scan" and "merge" utilities to check for text that has been previously
used.

In our Enquiry System EVERYTHING is softcoded - including the subfile
options and function keys - the user isn't displayed the option/function key
literal if they are not authorised to the option/function - and the
option/function key is disabled for that user - all softcoded. So we can add
a new function to a program by adding a record to a file for that function
key, giving it a message ID and a program to call: Voila - a new function in
a program without recompiling! It also means that the new function can be
added to 20-30 other programs by simply adding a record for the those
programs too. Boy does that make programming easy - 30 new functions by
writing one program, and in 12 different languages! :-)   

Oh yeah - ALWAYS add 50% on your field lengths if you're going to use German
text. ;-)

Anyway, food for thought. Just remember - it takes a lot of hard work in the
early days, but if you do it right it is SOOOO much easier in the long term.

(If you want any code for "scan" or "merge" MSGF utilities I'm sure I can
dig them out for you)

Cheers

Larry Ducie