skip to main content
OpenEdge Development: Translation Manager
Preparing Your Application for Translation : 4GL considerations
 
4GL considerations
This section describes the following programming techniques developers can use to ease translation:
*Defining text as untranslatable
*Defining alignment and space
*Defining accelerator keys
*Using default buttons
Defining text as untranslatable
When creating OpenEdge applications, a developer can explicitly use the :U character-string literal after a text phrase to mark the text phrase as “Untranslatable.” For example, the developer might not want to translate the name of your company or the name of a product, an internal key value, or a string used in determining program behavior. The developer can use the :U notation to ensure that the Translation Manager will not even display a given text phrase in the list of phrases to be translated.
It is imperative that you mark any programmatic strings in you code withe the :U attribute that may be evaluated by the translation process. For example, perhaps you want to find message strings in your code that are displayed by IF THEN ELSE statements to translate. Now assume that some of the IF THEN ELSE statements use strings as part of the condition. You must add the :U attribute to these conditional strings to prevent them from being affected by the translation process.
When you extract text phrases in Translation manager, the Compiler automatically filters out and does not extract those phrases marked :U. You do not have to set this filter in the Translation Manager. You should encourage the developers to use the :U character string literal appropriately to make the task of selecting filters easier. See OpenEdge Development: AppBuilder for more information on filters.
Defining alignment and space
OpenEdge allows developers to use alignment literals after a text phrase —:L, :C, :R, :T. Developers can also specify the amount of space (in characters) that should be reserved for the string’s display. For example, specifying that side labels be right aligned can ease layout problems during translation. See OpenEdge Development: AppBuilder for more information on alignment of labels.
Defining accelerator keys
Developers should always use an ampersand (&) to define an accelerator key. As the project manager, you should decide and convey to your translators which of the following you want to do:
*Choose different accelerator keys based upon the target language. For example, if C is the accelerator key for the English word Close, use F for the French translation, Fermer, and use S for the German translation, Schliessen.
*Use the same accelerator key consistently for all languages to support portability. For example, always define C as the accelerator key for Close, no matter what the target language is.
Using default buttons
When creating Windows applications, developers often use the default buttons (OK and Cancel). This technique might not be the best for applications you want to translate. The default buttons display labels in the language of the operating system on which they are running. For example, if an application is running on Windows for French, the labels for the default buttons appear in French. Only if your application will always run in one language environment, should you use the default buttons.
If your application allows users to specify a language in which they will see the interface, you should avoid using default buttons, because you cannot programmatically specify the strings that the default buttons use as labels. Create your own buttons and mark the labels as translatable.