Providing translations

If you want to provide translations to client/server Windows applications and to USoft Batch applications, which are started by the end user from a distributed USoft Binder item, you must set the correct language by setting the "Language" Project Property in that USoft Binder file.

If you use translated System Messages:

•If the end user runs from flat files, you must generate and deliver an application.SMG file. Do this via Tools, Create Flat Files in the Definer menu.

•If the end user runs from repository, system messages and their translations are read directly from the Definer tables. No application.SMG file is in scope.

If you use translated Application Strings:

•If the end user runs from flat files, you must generate and deliver an application.UMG file. Do this via Tools, Create Flat Files in the Definer menu.

•If the end user runs from repository, system messages and their translations are read directly from the Definer tables. No application.UMG file is in scope.

Old use is that you specify the language to be selected at runtime by a *language:language entry in the USDI file placed in the APP directory of the usoft install directory.

If you want to provide translations to web application pages created in USoft Web Designer, you must set the correct language by setting the "DefaultLanguage" publication property of the publication configuration that you publish the pages against:

•This "DefaultLanguage" publication property is what determines in which language GUI elements and constraint messages are presented.

•This publication property also determines, for each individual call to the Rules Service, what is the return language expected of the Rules Service. This happens independently of any underlying setting of the "Language" Rules Service configuration parameter. This behaviour makes it possible to have a Rules Service respond in different languages during dynamic language switching.

•As a consequence, the Rules Service's Language configuration parameter is not effective in this setting.

If you use translated System Messages and the Rules Service runs from flat files, you must generate and deliver an application.SMG file. Do this via Tools, Create Flat Files in the Definer menu.

If you use translated System Messages and the Rules Service runs from repository, system messages and their translations are read directly from the Definer tables. No application.SMG file is in scope.

If you use translated Application Strings, you must generate and deliver .JSON translation files. Do this by publishing the pages. Each time you call the Publish routine, it exports translations to files named:

\WebSite\lang\language.json

For each declared language a separate file is created. The same process also downloads a file called

\WebSite\lang\language.alt.json

These latter files are not generated from Definer tables, but they may be edited by the developer manually.

You need not produce an application.UMG file for web application pages. If you make such a file available, it remains unused. Its function is replaced by the .JSON files.

If you want to provide translations to a REST or SOAP service created in USoft Service Definer, you must set the correct language by setting the "Language" Rules Service configuration parameter.

If you use translated System Messages:

•If the Rules Service runs from flat files, you must generate and deliver an application.SMG file. Do this via Tools, Create Flat Files in the Definer menu.

•If the Rules Service runs from repository, system messages and their translations are read directly from the Definer tables. No application.SMG file is in scope.

If you use translated Application Strings:

•If the Rules Service runs from flat files, you must generate and deliver an application.UMG file. Do this via Tools, Create Flat Files in the Definer menu.

•If the Rules Service runs from repository, system messages and their translations are read directly from the Definer tables. No application.UMG file is in scope.