Документи/Як/Створити багатомовний проєкт

Створення багатомовного проєкту є нетривіальним завданням, яке торкається чи не всіх аспектів OpenSCADA, якщо метою є вичерпна багатомовність. Та загалом цей процес передбачає кроки:

1. визначення переліку мов проєкту та БАЗОВУ мову із цього переліку;
2. перевірка наявності перекладу системних-загальнопрограмних повідомлень обраними мовами та планування або ігнорування перекладу цих повідомлень відсутніми мовами;
3. визначення потрібного режиму багатомовності проєкту користувача;
4. загальна реалізація користувацького проєкту на БАЗОВІЙ мові, або на одній іншій, у одномовному режимі;
5. перемикання проєкту у багатомовний режим та переклад мовами із переліку у пункті 1, разом із перенесенням мови одномовного режиму та перекладом БАЗОВОЮ, якщо не вона була мовою попереднього режиму;
6. поточний супровід змін повідомлень проєкту при зміні їх у БАЗОВІЙ та неБАЗОВІЙ мовах.

Із самого переліку кроків видно, що багатомовний проєкт це не просто, якби саме середовище розробки OpenSCADA не намагалося спростити це завдання, тому, якщо ви реально бажаєте створення багатомовного проєкту, то маєте бути психологічно готовими до цих труднощів та значного об'єму роботи!

1 Визначення переліку мов проєкту та БАЗОВУ мову із цього переліку

Цей крок залежить суто від автору проєкту та його завдання, але щодо БАЗОВОЇ мови наполегливо рекомендується обирати міжнародну — Англійську (en), та цей короткий посібник не розглядає інших варіантів. Хоча OpenSCADA загалом дозволяє встановити-обрати іншу мову БАЗОВОЮ із блокуванням файлів бібліотечних БД у режимі лише для читання, або виключення змін там чогось, оскільки БАЗОВОЮ мовою цих БД є саме Англійська (en)!

Окрім БАЗОВОЇ мови, для динамічної багатомовності вводиться поняття ОСНОВНОЇ мови, тобто мови локалі у якій запущено програму і якою буде надано повідомлення по замовченню та щодо мов для яких відсутній переклад.

2 Переклад системних-загальнопрограмних повідомлень

Із процедурою перекладу системних повідомлень ви можете ознайомитися у короткому "Як виконати ...", який можна тут доповнити хіба тим, що для перекладу повідомлень інтерфейсу виконання можна перекласти лише повідомлення модулів побудови цих інтерфейсів, а саме UI.Vision та UI.WebVision.

Системні повідомлення так само динамічно перекладаються у режимі БАГАТОМОВНИЙ-ДИНАМІЧНИЙ відповідно до мови користувача та за віддаленого підключення, але є низка комбінованих попередньо-збережених повідомлень, переклад яких неможливо динамізувати та вони відповідно завжди представляються ОСНОВНОЮ.

3 Визначення потрібного режиму багатомовності проєкту користувача

Загалом OpenSCADA надає три режими:

1. ОДНОМОВНИЙ (типовий), але із можливістю використання та коригування повідомлень мови локалі запуску програми для вже багатомовних сховищ конфігурації, тобто які містять поля повідомлень для цієї мови — все що користувач створить нового у цьому режимі буде одномовним;
2. БАГАТОМОВНИЙ стосовно конфігурації, у сховищах якої при збереженні створюються окремі поля повідомлень мови локалі запуску програми — саме у цьому режимі створюються багатомовні сховища (бібліотечні БД та проєкти користувача) для типів сховищ із підтримкою властивості перекладу (TR);
3. БАГАТОМОВНИЙ-ДИНАМІЧНИЙ стосовно можливості у контексті програми отримати багато мов як при розробці, так і виконанні та що особливо актуально для WEB-інтерфейсів із окремими сеансами для окремих користувачів та різними мовами, або для серверу візуалізації який має передавати інтерфейс мовою локальної станції, яких може бути багато.

Відповідно, завданням на цьому етапі є визначитися чи вам потрібна динамічна багатомовність (режим 3), чи цілком достатньо багатомовної конфігурації проєкту, який ви запускатимете на різних станціях у різних локалях-мовах.

4 Загальна реалізація користувацького проєкту на БАЗОВІЙ мові, або на одній іншій, у одномовному режимі

На цьому етапі можна взагалі не перейматися багатомовністю, а реалізовувати проєкт у одній та бажано обраній як БАЗОВА.

Ви також можете просто взяти вже раніше розроблений одномовний проєкт, який бажаєте виконати багатомовним.

5 Перемикання проєкту у багатомовний режим та переклад обраними мовами

Всі основні дії із перекладами здійснюються у вкладці "Переклади" кореневої сторінки конфігурації станції, яку наведено на рисунку 1 та де розглянемо всі дії цього етапу.

Рис.1. Вкладка "Переклади" кореневої сторінки конфігурації станції.

У першу чергу маємо перемкнути проєкт попереднього етапу у режим багатомовності, для чого у визначеній вкладці вводимо код обраної раніш БАЗОВОЇ мови, або перелік локалей усіх мов проєкту із БАЗОВОЮ першою, що краще, оскільки тоді вони будуть підставлятися далі автоматично та використовуватися у перекладі системних-бібліотечних повідомлень як то місяці дати — на рисунку вказано "en_US.UTF-8;uk_UA.UTF-8;ru_RU.UTF-8", тобто базовою є Англійська (en). Якщо ще потрібна й динамічна багатомовність, то встановлюємо прапорець за полем мови, який є планом увімкнення багатомовності за наступного запуску. Тобто зберігаємо ці зміни до сховку проєкту та перезапускаємо його.

Якщо все відбулося коректно то після перезапуску у статусі перекладу маємо отримати "БАГАТОМОВНИЙ" або "БАГАТОМОВНИЙ-ДИНАМІЧНИЙ" та переходити безпосередньо до перекладу на цій самій вкладці, тобто у таблиці "Повідомлення". Якщо сама таблиця у вас ще відсутня то ви обрали не динамічний режим, де початково відсутній індекс повідомлень перекладу для побудови менеджеру-таблиці перекладу, але є поле "Ввімкнення менеджера", яке цей індекс формує.

Перед ввімкненням менеджеру перекладу, або початком роботи з ним у динамічному режимі, необхідно цілком завантажити всі повідомлення, що не відбувається автоматично для проєктів та бібліотек СВУ та що можна здійснити просто відкривши середовище розробки.

Після ввімкнення менеджеру перекладів, а відтак його появи, у полі "Мови контролю" та через символ розділювача ";" вказуєте перелік обраних мов за виключенням БАЗОВОЇ. Тепер ви можете здійснити переклад повідомлень у таблиці визначеними мовами та разом із БАЗОВОЮ, якщо початковою мовою проєкту була не вона.

Менеджер перекладів, а точніше процедура його формування, також здійснює низку перевірок із відповідними маркуваннями та прямі виправлення невідповідностей для максимального спрощення цього процесу, що вмикається відповідним прапорцем.

Більше дізнатися про особливість елементів інтерфейсу цієї сторінки можете на сторінці її опису.

6 Поточний супровід змін повідомлень проєкту

Здійснюючи загальний переклад можна не занурюватися глибоко у деталі походження цих повідомлень та причини відсутності перекладу окремих з них, а також не перейматися питанням перенесення напрацювань цього проєкту зі збереженням перекладів та ключовим питанням того, що буде із перекладом у процесі його супроводу та розширення, тобто при зміні повідомлень у різних режимах перекладу та за різних мов локалі виконання проєкту.

Але якщо рівень перекладу є важливим, як і перелічені вище питання, то починаємо заглиблюватися...

Джерелом повідомлень, як і їх перекладу, може бути або контейнери-таблиці сховища із полями текстового типу від первинних ОБ'ЄКТІВ ПРОГРАМИ, назві яких передує код мови (db:SQLite.LibDB.flb_Controller#DESCR), або контейнер-таблиця "Tr" із ОКРЕМИМИ ПОВІДОМЛЕННЯМИ (db:SQLite.vcaBase.Trs#base).

6.1 Первинні об'єкти програми

Підтримка сховищем властивості перекладу (TR) власне і передбачає опрацювання перекладу первинних об'єктів програми, тому доцільно тут розглянути поведінку їх алгоритму у різних режимах багатомовності за різних локалей-мов виконання програми (БАЗОВА чи неБАЗОВА) та щодо текстового поля:

1. ОДНОМОВНЕ сховище:

• ЧИТАННЯ => пряме читання єдиного поля
• ЗМІНА, ОЧИЩЕННЯ => пряма зміна єдиного поля

1.1. + ОДНОМОВНИЙ режим:

• ВСТАНОВЛЕННЯ => пряма зміна єдиного поля

1.2. + БАГАТОМОВНИЙ режим:

• ВСТАНОВЛЕННЯ => БАЗОВА — прямо, неБАЗОВА — прямо переклад та базову (фактично перетворення сховища у БАГАТОМОВНЕ)

2. БАГАТОМОВНЕ сховище:

2.1. + БАГАТОМОВНИЙ режим:

• ЧИТАННЯ => читання поля перекладу та БАЗОВЕ, з яких обрання БАЗОВЕ за відсутності-порожнечі перекладу
• ВСТАНОВЛЕННЯ => БАЗОВА — прямо, неБАЗОВА — прямо переклад та базову
• ЗМІНА => просто зміна раніш маркованих "<!>" або: зміна, БАЗОВА — маркування "<!>" актуальних перекладів, неБАЗОВА — маркування "<!>" базової мови
• ОЧИЩЕННЯ => очищення БАЗИ та усіх перекладів

2.2. + БАГАТОМОВНИЙ-ДИНАМІЧНИЙ режим, змінені значення передаються у формі "{base}\000{lang}\000{mess}":

• ЧИТАННЯ => читання лише БАЗОВЕ та його реєстрація у індексі повідомлень
• ВСТАНОВЛЕННЯ => прямо для ОСНОВНА та копіювання перекладу і БАЗОВА; оновлення індексу та кешу перекладу повідомлень
• ЗМІНА => просто зміна раніш маркованих "<!>" або: зміна, БАЗОВА — маркування "<!>" актуальних перекладів; оновлення індексу та кешу перекладу повідомлень
• ОЧИЩЕННЯ => очищення БАЗИ та усіх перекладів

БАЗОВЕ повідомлення може бути спільним для декількох джерел тож ви не зможете відредагувати його перекладу окремо, але ви можете розділити його, із контекстного меню, за джерелами, а далі здійснити окремий переклад.

Копіювання об'єктів, як і перейменування, загалом здійснюється без урахування перекладу, тобто цільовий об'єкт його не матиме, більш того, ОСНОВНЕ повідомлення стане БАЗОВИМ, від мови виконання проекту, що корисно якщо ви копіюєте об'єкт для подальшого одномовного використання ОСНОВНОЮ мовою. Якщо-ж для цього об'єкту також потрібна багатомовність, то одразу після копіювання можете скористатися менеджером перекладу (Рис.1), який автоматично замінить БАЗОВУ мову та встановить вказані переклади.
У режимі БАГАТОМОВНИЙ-ДИНАМІЧНИЙ всі переклади копіюються автоматично!

6.2 Окремі повідомлення (контейнер-таблиця "Trs")

Але не всі повідомлення в OpenSCADA пов'язано із її об'єктами, наприклад — процедури на внутрішній мові можуть містити текстові повідомлення, які варто перекладати окремо, а не цілком цю процедуру чим призводячи до логічної її розбіжності на різних мовах. Тому до мови внутрішніх процедур запроваджено функцію tr(), яка повертає переклад охопленого нею повідомлення згідно до ОСНОВНОЇ мови, або мови динамічного контексту у режимі БАГАТОМОВНИЙ-ДИНАМІЧНИЙ та якщо процедура із цим контекстом пов'язана.

Зв'язок динамічного контексту у режимі БАГАТОМОВНИЙ-ДИНАМІЧНИЙ передбачає власне виконання цієї процедури від користувача з окремою мовою або від мови, тобто лише для процедур графічного інтерфейсу СВУ, відтак виконання процедур джерел даних ніяк не може здійснюватися від якогось окремого користувача чи мови, тому вони завжди перекладаються ОСНОВНОЮ.

Для зберігання перекладу повідомлень такого кшталту спеціально передбачено окремий контейнер-таблицю "Trs", яка розташовується у сховку-БД що пов'язано із об'єктом OpenSCADA із такою процедурою. Повідомлення огорнуті функцією tr() потрапляють до таблиці "Trs" під час виконання цієї процедури або компіляції, для строкових літералів, та самі ці повідомлення у процедурі мають бути БАЗОВОЮ мовою. Наразі відсутня можливість відстеження зміни повідомлень, огорнутих функцією tr(), тому всі вони після виконання будуть там накопичуватися, але ви можете видалити їх вручну із контекстного меню менеджеру.

Копіювання об'єкту OpenSCADA із процедурами з одного сховку-БД до іншого не призводить до копіювання і перекладів між окремими контейнерами-таблицями "Trs", але ви можете виконати цю процедуру нового об'єкту, чим додати її до "Trs", а потім скопіювати й переклади за допомогою менеджеру перекладів (Рис.1).

7 Завдання із вдосконалення контролю перекладами та підвищення рівня охоплення

- розробити механізм відстеження неактуальності повідомлень у таблиці "Trs"

 ?> можливо додати до таблиці "Trs" поле опцій, де позначати час оновлення-реєстрації та при компіляції або виконанні, відповідно очищати надто старі та оновлювані-реєстровані при компіляції