GUI Internationalization for CA Gen

Document ID : KB000027671
Last Modified Date : 14/02/2018
Show Technical Document Details

Summary:

This article provides a summary of all steps necessary to provide a national-language-specific interface for a GUI application developed with CA Gen.  It describes the design and runtime aspects for localized GUI applications. It does not cover the internationalization of block-mode or web applications.

 

Instructions:

Design

Dialect Definition

From the main menu of the Toolset choose Design/Dialect Definition/Add to add a new dialect.
The Dialect Name is limited to eight characters.
The Message Table Name identifies language-specific resources:
the DLL for the runtime error messages
the GDICW RC file, which contains the database logon dialog
the RC file, which is included in the Window Manager resource code

Figure 1

All the language-specific resources are built from a code prefix consisting of two characters and a suffix identifying the usage.

Filename Purpose

_guiw.rcMessage Table source for Windows Systems
_guin.dllMessage Table runtime DLL, built from _guiw.rc
_gui.rcLanguage-specific submenu items for Windows and Help
_gdicw.rcdatabase logon dialog source for Windows Systems

To prevent problems, do not use the full file name in the Message Table Name entry field. Just use the two-character code.

The following table lists languages and codes provided by the installation:

ArabicAR
DanishDA
DutchDU
FinnishFI
FrenchFR
GermanGE
ItalianIT
NorwegianNO
SpanishSP
SwedishSW

The Trans Table Name is used only when developing block-mode applications. It specifies the name of a translation table coded in the user exit TIRUPPR used for lower-to-uppercase translation.

Window Design

First, design your window with all associated logic/events in the default dialect. Then a copy of that window will need to be created for the specific dialect.

Next, set the current dialect to work with in the Design/Dialect Definition dialog by highlighting it in the list box. Then, open the Window Selection dialog in Window Design, select the desired window, click the Add button, and select the target dialect in the upcoming Window properties dialog box. Translate the window title, and click OK.

Figure 2

All events associated with the window will be copied along with the window definition. Even the basic help descriptions are copied and can be translated for the dialect-specific window.

Exit State messages

The translation of Exit State messages is done in the Business System Defaults.
Select the current dialect to work with in the Design/Dialect Definition dialog.

Figure 3

Open Design/Business System Defaults, and select the Business System. Then open the Exit States submenu item of the Detail drop-down menu.

Figure 4

Choose the Exit State, click on the Properties button, and translate your Exit State message in the upcoming dialog box:

Generation

Figure 5

The dialect-specific window managers are listed in the Generation window directly below the default dialect.

To generate the dialect-specific application, select the dialect-specific Window Manager. All other load module members are not dialect specific.

During generation, a subdirectory with the name of the dialect is created under the c subdirectory of the model. The Window Manager c source with its associated RC file is placed in this subdirectory. The RC file includes the dialect-specific [xx]gui.rc file with the translations for Window and Help submenus. The characters for [xx] are taken from the message table name in the dialect definition.

All source code for common non-dialect-specific parts stays in the C subdirectory of the model.

Implementation and Test

Figure 6

Testing on the client

Applications with a dialect-specific interface are implemented in a subdirectory named after the dialect. Applications without a dialect-specific interface, especially those without a GUI interface, are implemented in the C subdirectory of the model. However, testing of flows between dialect- and non-dialect-specific application 'packages' does not work from the build tool in the first step. To allow this test, all non-dialect-specific parts have to be copied to the dialect subdirectory. The same restriction applies if an action block DLL is built that is triggered by the installation option.

Remote Database Access (RDA)

If a dialect-specific client does not contain database access but a flow to a common server with database access (RDA style) the Build Tool does not detect the necessity to copy the database stub for the executable but uses the common blank executable stub. To solve this problem, copy the stub for the selected database system to the dialect subdirectory and name it like the load module. For example, for WINDOWS/ORACLE:

Copy c:\...\Gen\stuboran.exe d:\models\model.ief\c\GERMAN\mdtest.exe

Runtime support

Runtime messages

The default dialect specified in AllFusion Gen supports the English language. The default language code is wr. The runtime messages are offered by wrguin.dll. The database logon dialog is implemented in wrc850n.dll.

For a dialect, the two-character code entered in the message table name is used to identify the files during runtime. For a code xx, the following files must be provided as source for the runtime DLLs:

xxgui.rctranslated submenu items, included in generated Window Manager.
xxguiw.rctranslated runtime messages, source for xxguin.dll
xxgdicw.rctranslated database logon, source for xxc850n.dll

To compile the dialect-specific runtime message/database, logon DLL scripts are provided for each of the supported operating systems:

Operating System Script

Windowsmkdialn.bat
UNIXmkdial.sh

The script takes the two-character message table code as its first parameter. The syntax help is listed below:

C:\...\Gen>mkdialn
Enter a two character dialect id
USAGE: mkdialn.bat **
The two character dialect id is associated with the business system
dialect. These two characters are the first two characters of the
dialect message table name. The dialect id is used to identify both
the dialect specific message table and database gdic logon dlls.

INPUT: ** represents the two character dialect which can be any of the following:

AR -- Arabic
DA -- Danish
DU -- Dutch
FI -- Finnish
FR -- French
GE -- German
IT -- Italian
JA -- Japanese
KO -- Korean
NO -- Norwegian
SP -- Spanish
SW -- Swedish
WR -- English

OUTPUT: **GUIN.DLL and **C850N.DLL

WRGLB User Exit

The dialect-specific handling of numeric formats can be influenced in the User Exit WRGLB. Changes to this User Exit are not needed but if made they have to be consistent with the dialect specifications. There is no need to modify this exit if the dialect settings conform to the International Settings chosen for the workstation where the application executes.

The function WRGLB is contained in the source file wrexitn.c, which is shipped with the Gen software:

int WRGLB( char * rp1, char * rp2,
           char * separator, char * decimal, char * currency,
           char * datesep, char * timesep, char * dateorder)
     
{
/* By default return the thousands separator, decimal point,
   date separator, time separator and date order passed in
   but always copy the Dollar sign to the currency. */
/* Default values are for US standards. */
#define DEF_CURR"$"
#define DEF_THOU","
#define DEF_DECI"."
#define DEF_DATE"-"
#define DEF_TIME":"
#define DEF_ORDER0
*currency = *DEF_CURR;
    return 1;}

 

Additional Information/Restrictions:

Different localized versions of the same application cannot run concurrently on the same PC. All versions of an application, regardless of the dialect, have the same DLL and executable names. Therefore, they cannot run on the same PC at one time. However, different applications can use different dialects at the same time without interfering with each other.

The GUI internationalization offered by Gen does not provide support for switching dialects at runtime. This is a design-time issue.

Gen does not provide support for any kind of international database contents. These issues need to be addressed in the application logic.