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.
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
All the language-specific resources are built from a code prefix consisting of two characters and a suffix identifying the usage.
|_guiw.rc||Message Table source for Windows Systems|
|_guin.dll||Message Table runtime DLL, built from _guiw.rc|
|_gui.rc||Language-specific submenu items for Windows and Help|
|_gdicw.rc||database 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:
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.
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.
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.
Open Design/Business System Defaults, and select the Business System. Then open the Exit States submenu item of the Detail drop-down menu.
Choose the Exit State, click on the Properties button, and translate your Exit State message in the upcoming dialog box:
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
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
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.rc||translated submenu items, included in generated Window Manager.|
|xxguiw.rc||translated runtime messages, source for xxguin.dll|
|xxgdicw.rc||translated 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
The script takes the two-character message table code as its first parameter. The syntax help is listed below:
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. */
*currency = *DEF_CURR;
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.