Writing Multi-Lingual Software

Many multi-national companies, especially in multi-lingual countries like Belgium and Switzerland, need to write their software so the Screen / Print Formats can be shown in different languages. We have talked to GV developers in these countries and the technique which appears to be the standard method for achieving the goal is to keep all screen text as messages in message files (*MSGF) because of the reduced overhead in accessing this type of object compared to a database file. The Screens Layouts are designed in one language and the Message File is translated when the application is complete.

There are 2 appropriate DDS keywords when displaying message file messages on the display. MSGID and MSGCON. MSGID is the preferred method. MSGID is a real-time access of the message from the message file. To run multi-lingual software you need only one version of the RPG program, one version of the DSPF and as many message files as languages required. The required message file sits at the top of the library list for the language required. MSGCON is a compile time option. The required message file must be at the top of the library list for the CRTDSPF, but this means that you can have one version of the RPG program but you will need a separate library of display files (which have been compiled with different message files at the top of the library list) so that the required language display file library can be at the top of the library list for individual users.

MSGCON would seem to be more efficient, as it is compiled, but the developers in Europe suggest there is no noticeable difference in using MSGID so we must follow their recommendation. However MSGID has two, quite major, restrictions. a) MSGID cannot be used on a print file so you must use MSGCON for these. b) MSGID can be used for subfile column headings but cannot be used in the subfile. So you cannot use multi-line subfile records or subfile fold/drop. (if you do then GV will create MSGCON DDS source)

The developers in Europe have been using Genesis V with this technique for some years. They have been declaring Output work fields in the formatter to hold the text and using a special naming convention for the fields and the descriptions. They have then made knowledge base changes to recognise these fields and output MSGID source lines. The problem with this technique is that the formatters showed 'oooooooooooooooo' on the screen rather than the message text that was in the particular message, and they would have to switch to command entry to ADDMSGD / CHGMSGD entries.

We have taken their lead and amended Genesis V to not only generate MSGIG or MSGCON source in the DDS but to recognise the special message descriptions in the formatters and retrieve the message text whilst formatting so it is a real WYSIWYG. Also access to the message file is improved through the formatters.

To keep your screen text in message files you must do the following:-

1) Change Data Area GVOPTIONS in GVINP3P4 position 54 - 63 to hold the name of a message file that will hold Non-Column Heading Text (i.e. text not directly associated with a field). Change positions 64 - 73 to hold the name of a message file that will hold Column Heading text. If you wish it can be the same as 54 - 63. Change position 74 to be either 'C'ompile time or 'R'un time, which decides whether Genesis V will create MSGID ('R') or MSGCON ('C') DDS source. Finally change positions 75 - 76 to show a 2 character sentinel or indicator (e.g. ªª or @@) that will be used in the formatter to indicate that you are not using a normal description but require the formatter to retrieve a message from the message file. (Command GVOPTN will prompt the data area update)

You may choose to copy this data area into a particular SPC library so that you can use different message files for different application.

2) Create the message files using CRTMSGF GV does not do it for you. Probably best to create them in the DTA library or even have a special library (included at the top of your environment library list) purely for the job. If individual applications use different message file names you could have an ENGMSGLIB , a GERMSGLIB and a FRNMSGLIB to hold all of you different message files for translation.

3) In either the Non-Subfile or Subfile formatter, try entering a line of text in the bottom section of the formatter where the format of the description entered is

ªªMMMMMMM,LL

Where ªª is the special indicator in position 75/76 (we recommend ªª although this is inconvenient on some Europen or PC keyboards so @@ is an alternative) , MMMMMMM is the message id of the message (normal IBM message id format i.e. AAANNNN) , the comma is compulsory, and the LL is the length that you wish to display on the screen.

The formatter takes you the normal message maintenance display and as this is a line of text and not a column heading it will store the message in the message file quoted in 53/64 of GVOPTIONS. We recommend that having typed the line of message text you should place a special marker '!' or '|' etc in the position after length of the message that you wish to display (i.e. LL + 1) so that when the message file is copied for translation, the translator can see where the translated language text must end.

If you P&C in the WYSIWYG secion and select 'T' for create new text, and enter text in the window in the format shown above, you will be taken through the same sequence.

You can type in 'ªª?' on an existing 'ªª' line and be shown the content of the message file, but this is the IBM Display so you cannot pick with an 'X' the message you require. You must return and type it in after the 'ªª'. You cannot type in 'ªª?' on a new line.

You can use the 'ªª' description on a Field picked for the formatter and you will be routed through the message maintenance function if the message quoted is a new message. The message for column headings will be stored in the message file quoted in 64/73 of GVOPTIONS.

Note. Message Data (&1,&2) is not supported for this technique.