Application Strings and System Messages |
|
|
|
Localised text is organised in 2 categories: System Messages and Application Strings:
* Somewhat confusingly, message texts that you write as part of a constraint definition are not considered System Messages but Application Strings. System Messages only include: •Messages that USoft produces in the default application, for example, the message "n records committed" when the user commits records. •Messages that you make up as a developer in the T_SYS_MSG table (see next section) and produce programmatically by calling RulesService.MessageLanguage() or RulesService.TranslateMessage(). Localised texts in USoft DefinerLocalised texts in USoft Definer are visualised in the picture below. If you do not take any action, the application will run with default English texts stored in USD.con. To localise, you must first run the Load System Messages and Populate Application Strings routines that you access via the Tools, Language submenu of USoft Definer. These routines create records in the System Messages table (T_SYS_MSG) and in the Application Strings table (T_APP_USED_STR). These records initially hold the default text elements. Localise these texts by editing these records. These changes are automatically visible in runtime applications that run from repository. For runtime applications that run from flatfiles, you must create and distribute an .SMG flatfile (for System Messages) and an .UMG flatfile (for Application Strings). You can create these flatfiles via the Tools, Create Flat Files submenu of USoft Definer, in the same way that you create .CON and .JOB files.
As the picture shows, there are "default tables" that store default texts (T_SYS_MSG for System Messages and T_APP_USED_STR for Application Strings), and there are "language-related" tables that allow you to store translations of default texts for 1 or more specific languages (T_SYS_MSG_LNG for System Messages, and T_APP_LNG_STR for Application Strings): •The texts in the "default tables" are used if you do not offer multiple versions of the application. At runtime, in this case, the "Language" property is left empty (NULL). •The texts in the "language-related" tables are used if you offer multiple versions of the application. The text selected at runtime depends on the value of the "Language" runtime property. To set a language at runtime, see "Localisation at runtime" in: Localising Your Application. Localised texts in GUI objectsIt is good practice to implement localisation in the USoft Definer repository whenever you can, and not in layers closer to the client such as GUI settings or Java code written for REST services. Implementing localisation in USoft Definer ensures that localised texts will be re-used even in future use cases that you cannot anticipate at development or translation time. This applies to batch applications, REST and SOAP applications, web applications, and client/server applications. If you set or reset text in GUI objects in the Windows Designer or Web Designer, these texts will overwrite anything that you have set in USoft Definer. •Texts customised in Windows Designer, such as customised field prompts in windows, are automatically imported into the T_APP_USED_STR table when you run the Populate Application Strings routine. •Texts customised in Web Designer, however, are NOT imported by the Populate Application Strings routine.
See Also |
|
