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.
Gen GUI C applications using dialects.
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.
Filename Purpose
_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:
Arabic | AR |
Danish | DA |
Dutch | DU |
Finnish | FI |
French | FR |
German | GE |
Italian | IT |
Norwegian | NO |
Spanish | SP |
Swedish | SW |
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 the 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. Manually translate the Window title as required 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.
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 per above.
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 the 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.
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 specific 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.
This is not a dialect specific scenario but is included here for completeness,.
If a client does not contain database access itself but flows to a second client in a separate Window Manager which does have database access, when building the first client the Build Tool does not detect the necessity to copy the database stub for its executable and uses the common blank executable stub. This can cause a database error at runtime when the first client flows to the second client:*** TIRM038E: Fatal database error was encountered
*** TIRM039E: DB last status = DB
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 "%Gen86%\Gen\stuboran.exe" model.ief\c\GERMAN\MDTEST.exe
The default dialect specified in 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 wrcn.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 xxcn.dll |
To compile the dialect-specific runtime message/database, logon DLL scripts are provided for each of the supported operating systems:
Windows | MKDIALN.BAT |
UNIX/Linux | mkdial.sh |
The script takes the two-character message table code as its first parameter. The syntax help is listed below.
NOTE: From a command prompt before running MKDIALN.BAT the file "%Gen86%\Gen\genenv.bat
" must be executed first to set up the Visual Studio environment for whatever Visual Studio version is installed.
C:\Program Files (x86)\CA\Gen86\Gen>MKDIALN.BATEnter 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 (UPPERCASE):
AR -- Arabic
DA -- Danish
DU -- Dutch
FI -- Finnish
FR -- French
GE -- German
HB -- Hebrew
IT -- Italian
JA -- Japanese
KO -- Korean
NO -- Norwegian
SP -- Spanish
SW -- Swedish
WR -- English
OUTPUT: **GUIn.DLL and **Cn.DLL
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 "%Gen86%\Gen\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_ORDER 0
*currency = *DEF_CURR;
return 1;
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.