Creating a multilingual project is a non-trivial task that affects almost all aspects of OpenSCADA, if the goal is comprehensive multilingualism. But in general, this process involves steps:
The list of steps shows that a multilingual project is not easy as the OpenSCADA development environment itself does not try to simplify this task, so if you really want to create a multilingual project, you must be psychologically prepared for these difficulties and a lot of work!
This step depends purely on the author of the project and its task, but for the BASIC language it is strongly recommended to choose international — English (en), and this short guide does not consider other options. Although OpenSCADA generally allows you to set-choose another language in BASIC with blocking library DB-files in read-only mode, or exclude changes there something, because the BASIC language of these DBs is English (en)!
In addition to the BASIC language, the concept of the MAIN language is introduced for dynamic multilingualism, ie the language of the locale in which the program is run and in which the messages will be provided by default and for languages for which there is no translation.
You can get familiar with the procedure of translation of system messages in the short "How to ...", which can be supplemented here only by the fact that for the translation of the messages of the runtime interface there can be translated only the messages of the modules for building these interfaces, that is UI.Vision and UI.WebVision.
System messages are also dynamically translated in the MULTILANGUAGE-DYNAMIC mode according to the user's language and remote connection, but there are a number of combined presaved messages, the translation of which cannot be dynamized and they are always the MAIN.
OpenSCADA provides three modes:
Accordingly, the task at this stage is to determine whether you need dynamic multilingualism (mode 3), or whether a multilingual configuration of the project is enough, which you will run on different stations in different language locales.
At this stage, it is possible not to worry about multilingualism at all, but to implement the project in one and preferably selected as BASIC.
You can also just take a previously developed singlelingual project that you want to make multilingual.
All basic translation actions are performed in the "Translations" tab of the station configuration root page, which is shown in Figure 1 and where we will consider all the actions in this step.
First of all, we have to switch the project of the previous stage to multilingual mode, for which in the specified tab we enter the code of the previously selected BASIC language, or a list of locales of all project languages with BASIC first, which is better, because then they will be substituted automatically and used in the translation of system-library messages such as months of date — the figure shows "en_US.UTF-8;uk_UA.UTF-8;ru_RU.UTF-8", so the BASIC is English (en). If you also need dynamic multilingualism, check the box after the language field, which is a plan to enable multilingualism the next time you run it. That is, save these changes to the project storage and restart it.
If everything happened correctly, then after restarting in the translation status we should get "MULTILANGUAGE" or "MULTILANGUAGE-DYNAMIC" and go directly to the translation on the same tab, ie in the table "Messages". If you do not have the table itself, then you have chosen non-dynamic mode, where initially there is no translation messages index to build a translation table manager, but there is a field "Enable manager", which forms that index.
Before enabling the translation manager, or starting to work with it in dynamic mode, you must fully download all messages that do not happen automatically for the VCA projects and libraries and can be done simply by opening the development environment.
After enabling the translation manager, and then its appearance, in the field "Languages of managing" and through the delimiter symbol ";" specify the list of selected languages except BASIC. You can now translate the messages in the table into the specified languages and together with the BASIC, if the original language of the project was not it.
The translation manager, or rather the procedure for its formation, also performs a series of checks with appropriate markings and direct corrections of inconsistencies to simplify this process as much as possible, which is enabled by the appropriate flag.
You can learn more about the interface elements of this page on the description page.
When conducting a general translation, you can not go deep into the details of the origin of these messages and the reasons for the lack of translation of some of them, as well as not worry about transferring the work of this project with preservation of translations and key issues of what will happen to translation in the process of its maintenance and expansion, that is, when changing messages in different translation modes and in different languages of the project execution locale.
But if the level of translation is important, as well as the issues listed above, then we begin to go deeper...
The source of messages, as well as their translation, can be either the storage container-table with text-type fields from the primary PROJECT OBJECTS, the name of which is preceded by the language code (db:SQLite.LibDB.flb_Controller#DESCR), or the container-table "Tr" with INDIVIDUAL MESSAGES (db:SQLite.vcaBase.Trs#base).
Storage support for the translation properties (TR) actually involves processing the translation of primary program objects, so it is advisable to consider the behaviour of their algorithm in different multilingual modes at different locales-languages (BASIC or nonBASIC) and for the text field:
BASIC message can be common for several sources so you cannot to edit its translation separately, but you can split that, from the context menu, per sources and next perform the differential translation.
Copying objects, as well as renaming, is generally done without translation, ie the target object will not have it, moreover, the MAIN message will be BASIC, from the language of the project execution, which is useful if you copy the object for further singlelingual use in the MAIN language. If this object also requires multilingualism, then immediately after copying you can use the translation manager (Fig.1), which will automatically replace the BASIC language and install the specified translations.
In the MULTILANGUAGE-DYNAMIC mode all translations are copied automatically!
But not all messages in OpenSCADA are related to its objects, for example — procedures on the internal language may contain text messages that should be translated separately, and not the whole procedure, which leads to its logical differences in different languages. Therefore, the function tr() has been implemented in the internal procedure language, which returns the translation of the message covered by it according to the MAIN language, or the language of the dynamic context in the MULTILANGUAGE-DYNAMIC mode and if the procedure is related to this context.
Dynamic context relation in the MULTILINGUAL-DYNAMIC mode involves the actual execution of this procedure by the user with a separate language or by language, ie only for procedures of the VCA graphical interface, so execution of the data source procedures cannot be performed by a single user or language, so they are always translated as MAIN.
To store the translation of such messages, a separate container-table "Trs" is specially provided, which is located in the database-storage associated with the OpenSCADA object with such procedure. Messages wrapped with the "tr()" function are included in the "Trs" table at the time of this procedure execution or compilation, for string literals, and these messages in the procedure themselves must be the BASIC language. At this time, it is not possible to track changes of messages wrapped in the tr() function, so they will all accumulate there, but you can delete them manually from the manager context menu.
Copying of OpenSCADA objects with procedures from one storage-database to another does not copy also the translations between individual "Trs" containers-tables, but you can execute this procedure on the new object, than adding it to "Trs" and then copy the translations also with help of the translation manager (Fig.1).
| Documents/How_to/Create_multi_language_project/en - GFDL | November 2024 | OpenSCADA 1+r2996 |
