General Administration

Internationalization I18N - Limitations

 

Conceptual Restrictions

 
  • The customizer has to configure which languages support non-Latin characters.
    This is configured in the column T_LANGUAGE.C_ENCODING.
    This release only supports UTF-8 as encoding, an empty encoding column is interpreted as standard 8-bit encoding as returned by the EPQ.
    Currently, there is no configuration UI besides SQLPlus.
 
  • Only languages that are not yet in use by the customer may be configured to use encoded fields, we do not support migration of existing data.
 
  • It is not supported to set one of these languages (see previous configuration step) as the UI language (or system language in DataView terminology).
There is one exception: If a calculatory field has the multilanguage flag set by the userexit mas_set_mlf_fld, it can display non-Latin characters, too!
 
  • Only multi-language fields using one of the encoded languages can store non-Latin characters.
    These fields are called encoded fields in the rest of this document.
    We do not allow to use non-Latin characters in standard text fields because these are used as ID's, file names and so on.
 
  • If the data stored in multi-lingual fields is used to generate field or mask titles, the user will see the raw UTF-8 data in the title. UI elements like titles are not yet capable of using non-Latin characters.
 
  • Only the Java Client, the Web Client and the Workflow Editor will be able to display and modify encoded fields properly.
    In the Windows-Client these fields are displayed in UTF8 syntax (not human readable!) and are read-only to not tamper the value.
 

Coding Restrictions

 
  • Application code must not copy the content of an encoded field into a standard text field and vice versa.
    Doing otherwise may result in invalid multi-byte sequences. Such code needs to use for instance the ICU library to be on the safe side.
 
  • Application code must not concatenate field content of a standard text field with the content of an encoded multi-language field.
    Doing otherwise may result in invalid multi-byte sequences. Such code needs to use for instance the ICU library to be on the safe side.
 
  • Application code that parses encoded fields must be adapted to use the ICU library.
    Otherwise it might corrupt multi-byte sequences.
 
  • LogiView restrictions
    The restrictions listed above apply to all kind of code running in the server, which includes LogiView.
    LogiView code should not concatenate or copy text from encoded fields to standard text fields or vice versa.
    We plan to add an I18N LogiView API in a future release.
 

Customization Restrictions

  Field menus that copy data from an encoded field into a standard text field need to be adapted: we recommend to use the Lookup-Table module (xlut userexits) instead of such menus:
 
  • Copying a multi-language field into a non-multilanguage field is never a good idea. The xlut userexits allow you to present a human readable multi-language text in the menu, and to store the ID assigned to this menu entry into the target field.
 
  • Existing field menus that write multi-language data into multi-language fields work fine.
 

Components that do not support Encoded Fields

  This is a list of components where we identified problems with encoded fields:
 
  • DataView Client: Shows raw UTF-8 data and might truncate multi-byte sequences.
  • External Mail Client: Shows raw UTF-8 data.
  • IEF: Might truncate multi-byte sequences.
  • PrintStudio: Shows raw UTF-8 data and might truncate multi-byte sequences.
  • SML (Classification):
    The SML - especially the Attribute Pool - allows to enter non-Latin characters into encoded fields (which is fine), but this data is then used to create field titles.
    This will result in raw UTF-8 data written into the field titles. So in this release, we recommend to use only latin characters for attribute name and code.