The most common way to define constant text is to specify the text directly in the source code as a literal. While this method is the most common way to define constant text, it is the most difficult to translate. Avoid using this method whenever coding an application, even if the application is not planned for translation.
If you are coding an application that will not be translated, you might want to use this technique for:
Default values on input fields (DFT keyword)
Error messages (ERRMSG/SFLMSG keyword)
For device files, specify the text as an unnamed field, indicating the starting line and column and the constant text itself.
For example:
A line pos 'Text . . . . . . . . . . . . . : '
A similar rule applies to user-created commands. Define the text directly on the keywords of your command source statements.
For example:
CMD PROMPT(' Command description ')
When defining the text directly on the keywords, standardize the sizes of the different elements in a large literal, rather than specifying many small single ones as single words. This makes the source code more readable and more flexible for translation.
Consider that the space needed for explanation text can vary from language to language. To have enough room after translation, remember to reserve space initially. The source members need to be translated and the objects need to be created for different languages as shown in the following figure:
Each national language version has one set of programs, but can have multiple sets of source members and data objects. When the application is run, you can choose the appropriate textual data of the language version that you want to work with. This can be done if you set up the system part of the library list with the specific library that contains both the textual data and the program library.