|
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.
|