The DataView language management differentiates between system language and user data language and supports up to 10 languages.
The language management differentiates between system language and user data language. For instance you can develop an application with a German user interface/meta data, while the language of the test and user data changes several times.
DataView supports a maximum of 10 languages. Five of these are fixed standard languages and the other five can be free assigned. Language shortcuts and the corresponding identifiers are defined in special system menus (#LANGUAGE_SYS and #LANGUAGE_USR) and can not be changed.
With the help of the four LANGUAGE default variables you can register all required languages user-specifically as well as specify the starting and default languages of the application. Please note that you may only use the language shortcuts of the languages supported by DataView.
*If you use a comma-separated list of language shortcuts instead of the language shortcut, the corresponding language selection boxes in toolbars will not display all the available ten languages, but only the languages contained in the list. The first language shortcut will still determine the system or application data language, respectively.
**The default language is only used in case of the following situations:
If no default language has been defined our the passed language shortcut cannot be found in LANGUAGE_LIST, DataView will use the first language registered in LANGUAGE_LIST.
During model definition you can set up the individual language for each table field in the multilanguage field. The multilanguage field expects a comma-separated list of language shortcuts (field language list). Via a selection menu you enter either the complete language list corresponding to the default variable LANGUAGE_LIST or you select one or several language shortcuts. When creating the database, DataView will then internally create the required number of field objects for the multilingual texts. The required internal field names will be generated using the selected language shortcuts in the form TABLENAME.COLUMNNAME_LNG.
Multilingual table fields cannot be indexed. They are not appropriate for uniquely identifying records or to form key fields. You should only used multilingual fields for descriptive texts, additional texts, etc..
Multilingual view fields may contain fewer language shortcuts than the corresponding basic fields, but never different ones.
If you display a multilingual field in masks, you can open a multilingual mask for viewing or editing the multilingual texts in Widget- and in Mask-Edit state. If you are open the multilingual mask in Widget state, this is a View mask only. If you open it in MAS state, you can edit the multilingual texts. It is called at keys with the event macro @EDIT_LANGUAGE (only possible in MAS state) or alternatively at items/buttons with the userexit lng_edt_fld (possible in MAS and WDG state). Because @EDIT_LANGUAGE is called in MAS state by the system event [Strg+L], the multilingual mask can be opened at any active multilingual field in all masks of the application. If the multilingual mask is also to open in Widget state, you could for instance create a language button in a select button area for a form, position it directly next to the multilingual field and install the call using lng_edt_fld TABLENAME.FIELDNAME.
If you display a multilingual field in the non-significant area of a list, you can -- as an alternative for the multilanguage mask -- simultaneously make all language entries of the multilingual field visible in individual columns and edit them there. The userexit lng_shw_fld toggles visibility. It is called by the system event [Shift+Ctrl+L]. For multilingual field in the significant area you can view these entries only end of multilanguage mask.
If you edit a language entry in the multilingual mask or in the displayed language fields of a list, the userexit lng_cop_dat will copy any changes to the subsequent language fields if these are empty. It is automatically installed at the Post_Field trigger of multilingual fields when the default masks are created.
If in case of queries on multilingual fields the current language is not contained in the field language list or no text is entered for the current language, the query will automatically comprise the default language text. If even the default language is not contained in the field language list or there is no text for it, the query will use the first language in the field language list.
If you want to provide your own function for changing the language in your application, it is recommended to create a choice box in the toolbar. For this purpose you define the fields in the toolbar (top button area) in the menu data form, sub-list selection-assignment as follows:
Field in SL selection assignment | Entry/comment |
Selection name | @CBOXName |
Selection text | @LNGSYS or @LNGUSR |
Userexit | lng_set_act_sys or lng_set_act_usr |
Parameter | #LANGUAGE_SYS or #LANGUAGE_USR |
As the result you get the same language choice boxes in your toolbar like in the DataView setup toolbar. The macros @LNGSYS or @LNGUSR determine the readable text for the current system or user data language from the system menus #LANGUAGE_SYS or #LANGUAGE_USR. This text is displayed and language selection box. The userexits lng_set_act_sys or lng_set_act_usr set the selected language. The languages offered can be limited by passing a language list to LANGUAGE_SYSTEM or LANGUAGE_USERDATA.
DataView does not automatically translate a top menu after a change of the language. It will only be refreshed with the desired language after a restart of the application.
Any required change of the language must be done before the help system is called for the first time, because the language of the help system cannot be changed after its first call in a session.