Conversion to two-character language key
From Release 4.0 the previously 1-character language key has 2-characters as in ISO Code 639. For example, English is now 'EN' insead of 'E', Hebrew is 'HE' instead of 'B' and Korean is 'KO' instead of '3'.
The two most important reasons for this change were:
- Requests from international customers to use the internationally recognized 2-character ISO Code instead of the often non-intuitive 1-character key.
- Making language keys available for new languages; available codes were used up for Release 3.1H
The 2-character language keys only affect the external display, which is always in the form of the 2-character ISO Norm 639 code in Release 4.0 . The database and program view of the language key remains the same; 1-character with unchanged values. In the DB the character 'E' still stands for English and 'D' for German in Release 4.0.
In Release 4.0 the set of keys includes lower-case letters as well as the previous upper-case letters and numbers.
No data or user programs which use the language flag must generally be converted (see the section "Customer developments").
For backwards-compatibility the input of the previous 1-character language keys is supported as follows in Release 4.0: if only 1 language key character is entered, it is assumed to be the previous 1-character notation, so 'EN' and 'E' are English. Note case-sensitivity. In 4.0 'e' is not the same as 'E'. Only 'E' is English.
Existing Batch Input programs benefit from this compatibility. The 1-character language key can continue to be passed.
The implicit conversion between external ISO Code and the 1-character internal notation is based on assignments in the central Dictionary table T002 of data type LANG. Each domain of this type has the ISO 639 conversion exit for the external 2-character format in all screen and report interfaces.
The data type LANG always implies the conversion exit, so all customer domains of type LANG are automatically supported in 4.0, i.e. after the 4.0 upgrade the language key is displayed externally in customer developments in the 2-character ISO norm.
I/O attributes of language domains up to 3.1:
Uppercase obligatory (implicit uppercase translate)
Internal and external format identical
I/O attributes of language domains from 4.0:
Internal format case-sensitive
Internal and external formats differ according to
conversion exit ISOLA ("ISO code language key conversion")
Notes on customer developments
(for further details see OSS note 92012)
A language key should have a domain of type LANG. It should not be of type CHAR(1).
In new developments from 4.0 leave two characters space for screen language fields for the ISO code. This change is generally automatic in the 4.0 Upgrade. If an automatic change is not possible, e.g. for layoutreasons, the language field remains one-character, but can be rolled. Two-character input is also possible here, although not visualizable.
When using WRITE in a language key field,
WRITE <language key field> TO <target field>
WRITE <language key field>
contain the 2-character language key conversion, so <target field> should be large enough, or there must be enough space in the list, and external format must be wanted (see OSS note 92012). Otherwise use MOVE instead of WRITE.
Language key as function module parameter:
The language key can still be a function module parameter in internal 1-character format.
If the module is to be called externally by a Remote Function Call which passes the external 2-character value, it should be converted into the internal 1-character format for further processing. You can use the function module CONVERSION_EXIT_ISOLA_INPUT (see function module doc.).
Batch input programming:
Data transfer by Batch input is based on a sequential dataset containing records in one or more specified formats. These formats may contain the 1-character language key .
It is possible to support passing both the 1-character and 2-character language keys in Batch input programs.
You must define the new 2-character key as a new right-justified, compatible field in existing Batch input program record structures. A preference rule must interpret the two language keys.
A preference rule which is in some SAP 4.0 Batch input programs, for example, prioritizes the existing 1-character notation, i.e. if there is a 1-character language key not equal to space, the existing notation applies. Otherwise the new 2-character entry is interpreted (for function module CONVERSION_EXIT_ISOLA_INPUT, see above).