Export translations

Settings

Group
Language
Format	Export for off-line translation Export in native format

<noinclude>
<languages/>
{{Info|
* '''Author:''' [[User:RomanSavochenko|Roman Savochenko]]
* '''Sponsored on 17 {{CtxDetails|HD|human-days, 1 HD — 10 hours}}:''' Vinnica Poultry Farm
}}
</noinclude>

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:
# definition of the list of project languages and the BASIC language from this list;
# checking the availability of translation of system-wide program messages in selected languages and planning or ignoring the translation of these messages in missing languages;
# determining the desired multilingual mode of the user project;
# general implementation of a user project in the BASIC language, or in one other, in a monolingual mode;
# switching the project to a multilingual mode and translation into the languages listed in paragraph 1, together with the transfer of the language of the monolingual mode and the translation of the BASIC, if it was not the language of the previous mode;
# current support of changes in project messages when changing them in BASIC and nonBASIC languages.

[[file:at.png]] 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!

=== Definition of the list of project languages and the BASIC language from this list ===
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.

=== Translation of system-general program messages ===
You can get familiar with the procedure of translation of system messages in [[Special:MyLanguage/Documents/FAQ#UsingCore|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 [[Special:MyLanguage/Modules/Vision|UI.Vision]] and [[Special:MyLanguage/Modules/WebVision|UI.WebVision]].

[[file:at.png]] 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.

=== Specifying the need multilingual mode of [[Special:MyLanguage/Documents/Program_manual#Projects|the user project]] ===
OpenSCADA provides three modes:
# SINGLELANGUAGE (typical), but with the ability to use and correction messages on the language of the application launch locale for already multilingual configuration storage, ie containing message fields for this language — everything that the user creates a new one in this mode will be singlelingual;
# MULTILANGUAGE about the configuration, in the storage of which separate fields on the language of the program startup are created during saving — it is in this mode that multilingual storage (library databases and user projects) are created for the storage types with [[Special:MyLanguage/Documents/Program_manual#DBFeat|support of the translation (TR) feature]];
# MULTILANGUAGE-DYNAMIC about the ability of obtaining in the program context of multiple languages both in the development and execution and which is especially actual for WEB-interfaces with individual sessions for individual users and different languages, or for the visualization server that has to transmit the interface in the language of the local station, of which there may be many.

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.

=== General implementation of a user project in the BASIC language, or in one other, in a monolingual mode ===
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.

=== Switching the project to a multilingual mode and translation into the selected languages ===
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.

[[File:QTCfg_sys_transl.png|center|thumb|1000px|Fig.1. The tab "Translations" of the main page of the station configuration.]]

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.

[[file:at.png]] 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 [[Special:MyLanguage/Modules/VCAEngine|the VCA projects and libraries]] and can be done simply by opening [[Special:MyLanguage/Modules/Vision|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 [[Special:MyLanguage/Documents/Program_manual#ConfigTr|the description page]].

=== Current support of changes in project messages ===
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).

==== Primary project objects ====
Storage support for [[Special:MyLanguage/Documents/Program_manual#DBFeat|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:
:1. SINGLELANGUAGE storage:
::* READING => direct reading the single field
::* CHANGING, CLEARING => direct changing the single field
::1.1. + SINGLELANGUAGE mode:
::* SETTING => direct changing the single field
::1.2. + MULTILANGUAGE mode:
::* SETTING => BASIC — direct, nonBASIC — direct translation and base (in fact converting the storage to MULTILANGUAGE)
:2. MULTILANGUAGE storage:
::2.1. + MULTILANGUAGE mode:
::* READING => reading the translation and BASE filed, of which the selection is BASIC in the absence-emptiness of translation
::* SETTING => BASIC — direct, nonBASIC — direct translation and base
::* CHANGING => just changing the early marked as "<!>" or: changing, BASIC — marking as "<!>" for actual translations, nonBASIC — marking as "<!>" for the base language
::* CLEANING => cleaning the BASIC and all translations
::2.2. + MULTILANGUAGE-DYNAMIC mode, the changed values transferred in the form "{base}\000{lang}\000{mess}":
::* READING => reading only BASIC and it registering in the message index
::* SETTING => direct for the MAIN and copying the translation and BASIC; updating for the message index and translation cache
::* CHANGING => just changing the early marked as "<!>" or: changing, BASIC — marking as "<!>" for actual translations; updating for the message index and translation cache
::* CLEANING => cleaning the BASIC and all translations

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.<BR/>
[[file:at.png]] In the MULTILANGUAGE-DYNAMIC mode all translations are copied automatically!

==== Individual messages (the container-table "Trs") ====
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, [[Special:MyLanguage/Documents/User_API|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 [[Special:MyLanguage/Modules/VCAEngine|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. [[file:at.png]] 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).

=== Tasks to improve the translation control and increase coverage ===
<section begin=ToDo />
: - develop a mechanism for tracking the irrelevance of messages in the table "Trs"
:: ?> it is possible to add to the table "Trs" a field of options where to specify time of update-registration and at compilation or execution, accordingly to clear too old and updated-registered at compilation
<section end=ToDo />

Export translations

Views

Navigation menu

OpenSCADA

OpenSCADA Wiki

Search

Tools

MediaWiki

Personal tools