Skip to content

ABAP Keyword Documentation →  ABAP Programming Guidelines →  Robust ABAP →  Internationalization 

Storing System Texts

Other versions: 7.31 | 7.40 | 7.54


In ABAP programs, texts are used as parts of processed data but also as a means to communicate with the user. The latter are called system texts, which are delivered with an ABAP application. The ABAP Workbench manages system texts in such a way that they can be translated from the original language into other languages independently of the actual development object. The following are examples of translatable system texts:

  • Texts and documentation of data elements in the ABAP Dictionary
  • Short texts and documentation of the components of local classes
  • UI texts of dynpros, in Web Dynpro applications and in menu entries
  • Message texts
  • Text pools of ABAP programs that include the text elements of the program, for example, text symbols
  • Texts of the Online Text Repository (OTR)

In addition to translatable system texts, an ABAP program can also contain untranslatable texts. These are usually the character literals and the comments that are stored as a part of the source code.


Send only translatable system texts to the user

Specify all texts that a program uses to communicate with the user as translatable system texts. When you create translatable system texts, ensure that the length is sufficient for translations.


This rule is not only critical when programs are used in an international environment; it applies when working in multilingual development groups too. The prohibition of the use of character literals in the ABAP source code for all texts that are relevant for user dialogs is derived from this rule. You cannot translate character literals. Their content is independent of the respective logon language. Instead of character literals, you use text symbols or link character literals with text symbols. This is also checked in the extended program check.

When you create system texts, ensure that the length is sufficient. It is not usually possible to change the text length during translation, so the translator relies on you providing sufficient space for a reasonable translation at the development stage. This aspect is very important for longer texts, particularly if the original language is English, because facts can normally be expressed in fewer words in English than in other languages. The opposite can be true for short texts, for example, #Feld# (German) and #field# (English), or for compound words that are written as two or more words in English.


For purely technical texts (such as HTML tags or regular expressions) that are not to be translated, you can use character literals or literal content of character string templates. These should be marked as not relevant for translation for the extended program check using pragmas.

Good example

The following source code shows how to handle translation-relevant and non-translation-relevant text elements in source code: Technical texts that are not relevant for translation are specified as character literals. Other texts are linked with a text symbol. If the additions of the CONCATENATE statement do not play any role (for example, SEPARATED BY), it is preferable to use the chaining operator &&, as shown here, since this makes the source code clearer.

html_line = '<title>' && 'Some Title'(ttl) && '</title>'.
APPEND html_line TO html_body.