Values defined in the ABAP Dictionary cannot be translated, only their short texts. You therefore cannot use mnemonic keys at all.

Help views have to be maintained correctly. When doing this, please ensure that the type of relationship is also maintained correctly for the text tables, which must have the dependency factor 'TEXT'. Otherwise, the first found text (language-independent) is displayed when using the F4 help; currently, this is the German text because the language indicator 'D' has priority over all other language indicators (EFINSKOV).

When translating messages and titles in header lines, assembling texts from different, possibly variable parts into a useful and linguistically perfect unit can be a problem.

Texts which contain more than one variable symbol can often not be translated meaningfully. Until a suitable Basis function is available, you should take this into account and use only one variable symbol for new messages. Already existing messages, however, should not be revised.

In future, variables will be numbered (&1, &2, &3, &4). However, even with numbering, a continuous text assembled dynamically from several variables will be either difficult to translate or may not allow any translation at all.

Variables should never contain continuous texts.

Control keys that are stored in tables cannot be translated.

Keys of general importance, such as order type, document type, and so on, must therefore be language-independent. These fields have to be encrypted in numerical sequence, unless the application programs assign a new key externally or internally. In future, the Central Objects group will develop a conversion function for this purpose.

Within these elements, translation cannot be guaranteed, if you are using variables in IF constructs. Such constructs are to be avoided.

Leave Space!

During the output of texts on forms, you should provide enough space to avoid inconvenient abbreviations during the translation.

We strongly recommend that the developer contacts the responsible translator in such cases.

Output of texts that are shorter than the original field length (for example &TABCD-VTEXT(17)&) does not usually make sense with forms. During the translation, however, the length of the text output cannot be recognized.

Therefore, do not define text fields longer than necessary in the Data Dictionary, and write text fields in the defined length, if possible.

Since there is no proof of change that forms have been changed, you should at least document the changes in comment lines in the form itself (that is, chnages since the last maintenance level upgrade). This helps the translators as well as the customers who use our forms or use them as a reference for their own forms.

Therefore, enter those texts directly in the form.

If possible, a form should belong to exactly one business object, for example the document type. It should not be used for different purposes by means of (unclear) dynamic programming, because otherwise it may not be possible to achieve a meaningful translation.

After the translation, developers should test the foreign language forms everywhere they are used. They should discuss any problems with the translator.

For country-specific forms, translators should consult the "Internationalization" Group.