A frequent problem that occurs when you translate an application is that the user‑interface layout varies from one language to another due to text expansion. This section describes the following programming techniques you can discuss with your company’s developers to help reduce the effects of text expansion on layout:
Sizing and positioning widgets.
Planning for text expansion.
Creating adjustable text on rectangles.
Distinguishing between length and width of text phrases.
Creating message statements.
Adjusting justification on database fields.
Explicitly sizing and positioning widgets
If developers use explicit sizing and positioning when they define widgets, the application is easier to translate and the interface layout does not vary from one translation to another. Relative layouts, while easier for a developer to code from the Procedure Editor, have more problems compared to layouts made with the AppBuilder, which uses absolute sizes and coordinates.
The following code in tmproc1.p shows an example of code created in the Procedure Editor:
tmproc1.p
DEFINE VARIABLE a AS LOGICAL NO-UNDO
VIEW-AS TOGGLE-BOX LABEL "Replace if E&xists".
DEFINE VARIABLE b AS LOGICAL NO-UNDO
VIEW-AS TOGGLE-BOX LABEL "Check Syntax Now".
DEFINE FRAME myframe
"Options" VIEW-AS TEXT AT ROW 1 COL 1 SKIP
a SPACE(2)
b
WITH 1 DOWN.
This code example has the following translation problems:
The widths of variables a and b are defined implicitly at compile time based upon properties such as the label. The label, “Replace if E&xists,” might have an implicit width of 18 characters which, depending on the font used, might not display the entire label text in the source language, let alone the target language.
The width and height of the frame are not explicitly defined in the DEFINE FRAME statement. Typically, this means that the frame will not grow to accommodate translation space. Instead, the frame is clipped on the right side due to the implied widths of a and b.
The 4GL positions the frame at row 1, column 1 because the frame’s position is not explicitly defined.
The SKIP and SPACE options might not properly align the free text, “Options,” or the variables a and b.
To design for translatability, use the following code instead of the code in tmproc1.p.
tmproc2.p
DEFINE VARIABLE a AS LOGICAL NO-UNDO
VIEW-AS TOGGLE-BOX LABEL "Replace if E&xists" SIZE 30 BY 1.
DEFINE VARIABLE b AS LOGICAL NO-UNDO
VIEW-AS TOGGLE-BOX LABEL "Check Syntax Now" SIZE 30 BY 1.
DEFINE FRAME myframe
"Options" VIEW-AS TEXT SIZE 8 BY .85 AT ROW 1 Col 1
a AT ROW 2 COL 1
b AT ROW 3 COL 1
WITH 1 DOWN SIZE 40 BY 10.
Note: Even when you use explicit sizing and positioning of widgets, you can still encounter text‑expansion problems unless you also create margin space around widgets to accommodate expanded text phrases.
Planning for text expansion
When preparing your screen for translation, you should be aware that a translation can be much longer than the original text phrase. This is especially true when translating from English. Table 1–1 lists the standard formula for determining how much developers should plan for text expansion if English is the source language. This is the same table that the Translation Manager tool uses internally to calculate text expansion in the Compile dialog box. For example, if the length of the source text phrase is fourteen characters, you should plan to add space for eleven to fourteen additional characters, or a total of between twenty‑five and twenty‑eight characters. See Chapter 8, “Incorporating a Translated Kit into the Project,” for information on how the Translation Manager handles text segment expansion.
Note: This table is meant as a guide. There is no one rule or formula that can accommodate all translations. Discussion with a translator about a particular language and its text expansion properties can help you develop an application that is usable in the target language.
Table 1–1: Standard text expansion table for English source language
Length of English text phrase
Recommended expansion for
target phrase
Up to 10 characters
100–200%
11 to 20 characters
81–100%
21 to 30 characters
61–80%
31 to 50 characters
41–60%
51 to 70 characters
31–40%
Over 70 characters
30%
Developers should oversize the widgets in the interface layout and provide adequate space around labels and messages to accommodate text expansion in translation. For example, they should make buttons, list items, and radio options large enough to fit translations, otherwise the translator will need to abbreviate the translation.
For example, if you use the following code, there will not be enough space for the Spanish translations “Avion,” “Camion,” and “Barato”:
DEFINE c AS CHARACTER NO-UNDO VIEW-AS SELECTION-LIST
LIST-ITEMS "air", "truck", "boat"
SIZE 14 BY 2.
Depending on the target language, the font for text phrases in a user interface can increase or decrease in size from the source language. Therefore, make sure the application developer leaves plenty of space around text and between objects so that when you translate the application, the user interface still appears in order. Often a developer creates an interface that looks perfect in the source language-with exact spacing. However, when you translate the text phrases to a language that uses a larger font, the text phrases in the user interface look crowded, overlap, or truncate.
The developer should also be aware of text expansion when sizing and positioning objects in the interface. A crowded interface in the source language could result in overlapping objects and text in the target language. Using the Text Expansion table will not always result in a perfect translated interface, and the translator will need to do some cleanup to achieve optimal results. However, properly planning for text expansion makes the translator’s job smoother, results in a translated application that is clear and usable, and saves time that would be spent retrofitting the application.
Creating adjustable text on rectangles
Developers often overlay text over rectangles in graphical interfaces, especially for three-dimensional applications or for radio sets where the rectangle creates a border for the radio options. If the developers use an absolute boundary to eliminate space to the right of the last letter of text for the source language, when you translate the application, the target text phrase might be truncated or have too much extra space. To avoid this problem, developers should use run-‑time adjustments as illustrated in the following code example. In this example, the FONT–TABLE object allows the width of the object to grow or shrink as needed.
This requires more coding but provides a uniform and predictable interface for translation, as follows:
DEFINE VARIABLE ThisLabel AS CHARACTER NO-UNDO VIEW-AS TEXT SIZE 10 BY 1.
When you plan to translate an application, the developer should keep in mind not only the text-expansion factor of the target language, but also the font in which the target language will be displayed.
When you translate an application, you affect both the length and the width of the text phrases in the application. Translation Manager stores translations in terms of their length in bytes, but displays them in terms of their font’s width. For example, if a button has the label “Hello,” Translation Manager stores the label in a text segment that is five bytes long and uses 33 pixels to display “Hello” in Sans Serif 8‑point font.
Creating message statements
You should be aware that some message statements might be difficult to translate. For example, message statements that contain compound phrases that follow the noun-verb-object rules of English do not translate well into languages that follow different grammatical rules. Sometimes developers create message statements with embedded SKIP statements to align the message statement evenly on the screen. While this hard-coded alignment might look attractive in the source language, it might look awkward when you translate the message into another language.
For example, the following code contains three text phrases that most likely will be translated out of context of one another:
“The filename you entered,”
“, is”
“invalid under DOS.”
DEFINE VARIABLE fname AS CHARACTER NO-UNDO.
MESSAGE "The filename you entered," + fname + ", is" SKIP
"invalid under DOS." VIEW-AS ALERT-BOX WARNING.
When you translate these text phrases, the message will probably wrap awkwardly. To solve this problem, ask developers to avoid SKIP statements and to create message statements that do not split into text phrases that follow the grammar rules of a particular language. For example, in place of the above code, use one of the following code segments to display a similar message:
DEFINE VARIABLE fname AS CHARACTER NO-UNDO.
MESSAGE fname SKIP(1) "is invalid under DOS. Please try again."
VIEW-AS ALERT-BOX WARNING.
DEFINE VARIABLE fname AS CHARACTER NO-UNDO.
MESSAGE SUBSTITUTE(The filename you entered, &1, is invalid under DOS.",
fname) VIEW-AS ALERT-BOX WARNING.
Adjusting database field justification
Many OpenEdge applications use text labels from the OpenEdge databases. The fields in the database might be left-justified. Left justification might work well on the user interface of the source language but might not work well on the user‑interface after translation.
To avoid layout problems after translation, use the TRIM string attribute to trim the database fields. If you have multiple fields to trim, run the following 4GL code to automatically set the TRIM attribute on all database labels:
FOR EACH _field WHERE NOT _field._field-name BEGINS "_":U
Sizing and positioning widgets.