RE: multi language interfaces

Whoow, I'm impressed... It sounds pretty good!
and yes, I like to see MSGF utility code if you will so kind.

Our company language is Dutch, so I think I always have room enough in
fields when translating for other languages. It's even worse as Germany
;-)

Many thanks, Arco

> -----Oorspronkelijk bericht-----
> Van: rpg400-l-bounces@xxxxxxxxxxxx 
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx] Namens Larry Ducie
> Verzonden: maandag 6 juni 2005 23:30
> Aan: rpg400-l@xxxxxxxxxxxx
> Onderwerp: 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
> 
> --
> This is the RPG programming on the AS400 / iSeries (RPG400-L) 
> mailing list To post a message email: RPG400-L@xxxxxxxxxxxx 
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives 
> at http://archive.midrange.com/rpg400-l.
> 
> 
DISCLAIMER:
This message contains information that may be privileged or
confidential and is the property of C.Meijer B.V. It is intended only for the 
person to whom it is addressed. If you are not the intended recipient, you are 
not authorized to read, print, retain, copy,disseminate, distribute, or use 
this message or any part thereof. If you
receive this message in error, please notify the sender immediately and delete 
all copies of this message. 

This footnote also confirms that this email message has been swept by the 
presence of computer viruses