SAP ABAP Data Element RSLIN_XMLS (SLIN Checkbox: Internationalization)
Hierarchy
☛ SAP_BASIS (Software Component) SAP Basis Component
   ⤷ BC-ABA-LA-EPC (Application Component) Extended Program Check (SLIN)
     ⤷ SLIN_EXTERNAL (Package) External SLIN Interfaces
Basic Data
Data Element RSLIN_XMLS
Short Description SLIN Checkbox: Internationalization  
Data Type
Category of Dictionary Type D   Domain
Type of Object Referenced     No Information
Domain / Name of Reference Type BOOLEAN    
Data Type CHAR   Character String 
Length 1    
Decimal Places 0    
Output Length 1    
Value Table      
Further Characteristics
Search Help: Name    
Search Help: Parameters    
Parameter ID   
Default Component name    
Change document    
No Input History    
Basic direction is set to LTR    
No BIDI Filtering    
Field Label
  Length  Field Label  
Short 0   
Medium 0   
Long 40 Internationalization 
Heading 0 Internationalization 
Documentation

Definition

Activate Internationalization Checks

There are two different checks:

1. Checks whether TRANSLATE ... TO UPPER/LOWER CASE statements are working in the correct language environment.

2. Check whether all known date formats are handled (see below)

Re. 1. : Check TRANSLATE ... TO UPPER/LOWER CASE

This displays TRANSLATE ... TO UPPER/LOWER CASE statements that work on table fields without a preceding SET LOCALE LANGUAGE statement.

There are two cases:

  1. The table containing the field to which the TRANSLATE statement applies contains a language field.

    In this case, the data processed comes from a table containing a language field (regardless of whether the field occurs in the key). The correct language environment can almost certainly be set before the TRANSLATE statement is executed.

  2. The table in question does not contain a language field.

    If the current table does not contain a language field, the error is harder to correct. The language can either be identified from the surrounding data, or a language field must be inserted and provided with values.

Note

The TRANSLATE statement depends on the current language environment, which itself depends on the language in which the data was entered.

Incorrect settings for the language environment can cause loss of data if, for example, the TRANSLATE statement is used to generate matchcodes.

Examples of problems with the statement TRANSLATE:

  • What is the UPPER CASE of "a umlaut (ä)"?
    • 'Ä' in German.
    • 'A' in French.
    • In English, however, it would depend on the implementation, since 'ä' is not recognized at all.
    • In Japanese serious errors occur. The byte with the bit combination that looks like 'ä', is in reality the first half of a two byte representation of many different kanji.
  • If you try to process German data in a Russian environment, the result is variable: "a umlaut (ä)" and "A umlaut (Ä)" are processed correctly. However, 'ö' turns into '¦' and 'Ö' into '¶'. The capital 'Ö' has a bit combination that stands for lower case 'sch' in the Russian character set.

When does the problem occur?

  1. Problems of this nature can occur if the wrong language environment has been set up using SET LOCALE. However, this is very rarely the case, and the system does not check for it.
  2. Problems of this type can also occur if SET LOCALE is not used at all and data that does not belong to the log on language is processed regardless. This often occurs. Since language key fields are not filled automatically, it is not always easy to see whether an ABAP program is processing foreign language texts. (For comparison, think of clients where the source of data can be recognized from the addition "CLIENT SPECIFIED".) Since this is not so easy to recognize with languages, the critical parts are highlighted in the extended program check. These parts must either be corrected or marked with a special comment indicating that they are programmed securely (see below).

Before using the TRANSLATE statement, make sure that the language environment is set correctly and supplement it if necessary with a SET LOCALE LANGUAGE statement as described in the examples below, or the function calls suggested.

Afterwards, mark this program position as completed after the TRANSLATE statement (on the same line) using the special comment

"#EC TRANSLANG

.

The extended program check automatically includes SET LOCALE LANGUAGE statements and 'SCP_MIXED_LANGUAGES_1_SWITCH' calls if they occur shortly before a TRANSLATE statement, but the pseudo comment is a safer way to ensure that the point in the program will not be listed in the check results.

There is a further pseudocomment

"#EC SYNTCHAR

to indicate that the TRANSLATE statement is allowed because the data only uses characters from the 'syntactical character set'.

Solutions:

There are several ways of solving the problems:

The following examples are based on a table with a text field and a language key:

    DATA: BEGIN OF data OCCURS 0, 
            langu   LIKE sy-langu, 
            txt(20) TYPE CHAR, 
          END  OF  data.

Solution 1

Until now:          TRANSLATE data-txt TO UPPER CASE. 
                              || 
                              \/ 
New suggestion: SET LOCALE LANGUAGE data-langu. 
                 TRANSLATE data-txt TO UPPER CASE. 
                 SET LOCALE LANGUAGE SPACE.

This solution is correct. It is also simple because it does not require wide-ranging program changes. Each TRANSLATE TO UPPER CASE statement is called in the correct environment.

A possible disadvantage is the large number of nestings, since the SET LOCALE command takes some time. This solution also fails to account for two special conditions, although these should not occur very often:

  • It is possible that the language in data-txt is not permitted. This would cause a runtime error.
  • It is also possible that the program does not run in the logon language. The SET LOCALE LANGUAGE SPACE command always resets to the logon language.

Solution 2: Using sort:

If the data can be sorted without a problem because, for example, they are in an internal table that is not too large, it may be quicker to sort the data first.

    SORT data BY langu. 
    LOOP AT data. 
      IF data-langu >< SY-LANGU. 
        SET LOCALE LANGUAGE data-langu. 
      ENDIF. 
      TRANSLATE data-txt TO UPPER CASE. 
    ENDLOOP. 
    SET LOCALE LANGUAGE SPACE. 
    SORT data BY keyfield1 keyfield2.

Solution 3: Multiple passes:

This technique is the most time-consuming to program . This method is only worthwhile if large datasets have to be processed quickly and sequentially but cannot be easily sorted and are not already roughly sorted by language.

In a first pass, only the texts of the own language are translated. Additionally, using COLLECT, all the other languages that occurred are noted in a small internal table.

A loop can then be made across the internal table, a switch to the next language, and another pass across the entire dataset.

An example of this would be too long for this documentation. The "2nd procedure" in RSCP0104 is a test of this procedure.

Solution 4: Only process the logon language:

IF data-langu = sy-langu.
TRANSLATE data-txt TO UPPER CASE. "#EC TRANSLANG
ELSE.
" Something important missing ?
ENDIF.

What else is to be noted?

SY-LANGU:

SET LOCALE also resets the SY-LANGU field. Before processing more than TRANSLATE TO UPPER CASE and small, easy-to-understand actions, it is best to switch back to the logon language immediately, especially before calling new procedures.

Languages:

Depending on the body of data, it is possible that the language key may contain nonsense. Or a language may have been used that cannot be processed by a particular application server. Or perhaps a language is not installed correctly.

There are four function modules which relieve the various applications of having to handle these special cases individually.

  • SCP_MIXED_LANGUAGES_1_INIT
    is called at the start of processing
  • SCP_MIXED_LANGUAGES_1_SWITCH
    switches to desired language.
  • SCP_MIXED_LANGUAGES_1_NORMAL
    permits a temporary switch, during processing, back to the language that was active at the point of the SCP_MIXED_LANGUAGES_1_INIT.
  • SCP_MIXED_LANGUAGES_1_FINISH
    is called at some point after the end of the action.

As is customary for function modules, there are not many mandatory parameters in standard cases. Additional optional parameters are introduced for special cases that occur relatively frequently.

If exceptions are not queried, it is guaranteed that the function module either fulfills its task or causes the program to terminate with an ABAP mini dump. Using these functions, solution 1 looks like this:

    CALL FUNCTION 'SCP_MIXED_LANGUAGES_1_INIT'. 
    ... 
    LOOP AT data.     " Or SELECT, or... 
      ... 
      CALL FUNCTION 'SCP_MIXED_LANGUAGES_1_SWITCH' 
        EXPORTING&#x
History
Last changed by/on SAP  20141013 
SAP Release Created in