- Автор: Роман Савоченко
- Спонсорування на 17 ЛД[!]: Вінницька Птахофабрика
Створення багатомовного проєкту є нетривіальним завданням, яке торкається чи не всіх аспектів OpenSCADA, якщо метою є вичерпна багатомовність. Та загалом цей процес передбачає кроки:
- визначення переліку мов проєкту та БАЗОВУ мову із цього переліку;
- перевірка наявності перекладу системних-загальнопрограмних повідомлень обраними мовами та планування або ігнорування перекладу цих повідомлень відсутніми мовами;
- визначення потрібного режиму багатомовності проєкту користувача;
- загальна реалізація користувацького проєкту на БАЗОВІЙ мові, або на одній іншій, у одномовному режимі;
- перемикання проєкту у багатомовний режим та переклад мовами із переліку у пункті 1, разом із перенесенням мови одномовного режиму та перекладом БАЗОВОЮ, якщо не вона була мовою попереднього режиму;
- поточний супровід змін повідомлень проєкту при зміні їх у БАЗОВІЙ та неБАЗОВІЙ мовах.
Із самого переліку кроків видно, що багатомовний проєкт це не просто, якби саме середовище розробки OpenSCADA не намагалося спростити це завдання, тому, якщо ви реально бажаєте створення багатомовного проєкту, то маєте бути психологічно готовими до цих труднощів та значного об'єму роботи!
Contents
[hide]- 1 Визначення переліку мов проєкту та БАЗОВУ мову із цього переліку
- 2 Переклад системних-загальнопрограмних повідомлень
- 3 Визначення потрібного режиму багатомовності проєкту користувача
- 4 Загальна реалізація користувацького проєкту на БАЗОВІЙ мові, або на одній іншій, у одномовному режимі
- 5 Перемикання проєкту у багатомовний режим та переклад обраними мовами
- 6 Поточний супровід змін повідомлень проєкту
- 7 Завдання із вдосконалення контролю перекладами та підвищення рівня охоплення
1 Визначення переліку мов проєкту та БАЗОВУ мову із цього переліку
Цей крок залежить суто від автору проєкту та його завдання, але щодо БАЗОВОЇ мови наполегливо рекомендується обирати міжнародну — Англійську (en), та цей короткий посібник не розглядає інших варіантів. Хоча OpenSCADA загалом дозволяє встановити-обрати іншу мову БАЗОВОЮ із блокуванням файлів бібліотечних БД у режимі лише для читання, або виключення змін там чогось, оскільки БАЗОВОЮ мовою цих БД є саме Англійська (en)!
Окрім БАЗОВОЇ мови, для динамічної багатомовності вводиться поняття ОСНОВНОЇ мови, тобто мови локалі у якій запущено програму і якою буде надано повідомлення по замовченню та щодо мов для яких відсутній переклад.
2 Переклад системних-загальнопрограмних повідомлень
Із процедурою перекладу системних повідомлень ви можете ознайомитися у короткому "Як виконати ...", який можна тут доповнити хіба тим, що для перекладу повідомлень інтерфейсу виконання можна перекласти лише повідомлення модулів побудови цих інтерфейсів, а саме UI.Vision та UI.WebVision.
Системні повідомлення так само динамічно перекладаються у режимі БАГАТОМОВНИЙ-ДИНАМІЧНИЙ відповідно до мови користувача та за віддаленого підключення, але є низка комбінованих попередньо-збережених повідомлень, переклад яких неможливо динамізувати та вони відповідно завжди представляються ОСНОВНОЮ.
3 Визначення потрібного режиму багатомовності проєкту користувача
Загалом OpenSCADA надає три режими:
- ОДНОМОВНИЙ (типовий), але із можливістю використання та коригування повідомлень мови локалі запуску програми для вже багатомовних сховищ конфігурації, тобто які містять поля повідомлень для цієї мови — все що користувач створить нового у цьому режимі буде одномовним;
- БАГАТОМОВНИЙ стосовно конфігурації, у сховищах якої при збереженні створюються окремі поля повідомлень мови локалі запуску програми — саме у цьому режимі створюються багатомовні сховища (бібліотечні БД та проєкти користувача) для типів сховищ із підтримкою властивості перекладу (TR);
- БАГАТОМОВНИЙ-ДИНАМІЧНИЙ стосовно можливості у контексті програми отримати багато мов як при розробці, так і виконанні та що особливо актуально для WEB-інтерфейсів із окремими сеансами для окремих користувачів та різними мовами, або для серверу візуалізації який має передавати інтерфейс мовою локальної станції, яких може бути багато.
Відповідно, завданням на цьому етапі є визначитися чи вам потрібна динамічна багатомовність (режим 3), чи цілком достатньо багатомовної конфігурації проєкту, який ви запускатимете на різних станціях у різних локалях-мовах.
4 Загальна реалізація користувацького проєкту на БАЗОВІЙ мові, або на одній іншій, у одномовному режимі
На цьому етапі можна взагалі не перейматися багатомовністю, а реалізовувати проєкт у одній та бажано обраній як БАЗОВА.
Ви також можете просто взяти вже раніше розроблений одномовний проєкт, який бажаєте виконати багатомовним.
5 Перемикання проєкту у багатомовний режим та переклад обраними мовами
Всі основні дії із перекладами здійснюються у вкладці "Переклади" кореневої сторінки конфігурації станції, яку наведено на рисунку 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 Primary project objects
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:
- 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
- 2.1. + MULTILANGUAGE mode:
БАЗОВЕ повідомлення може бути спільним для декількох джерел тож ви не зможете відредагувати його перекладу окремо, але ви можете розділити його, із контекстного меню, за джерелами, а далі здійснити окремий переклад.
Копіювання об'єктів, як і перейменування, загалом здійснюється без урахування перекладу, тобто цільовий об'єкт його не матиме, більш того, ОСНОВНЕ повідомлення стане БАЗОВИМ, від мови виконання проекту, що корисно якщо ви копіюєте об'єкт для подальшого одномовного використання ОСНОВНОЮ мовою. Якщо-ж для цього об'єкту також потрібна багатомовність, то одразу після копіювання можете скористатися менеджером перекладу (Рис.1), який автоматично замінить БАЗОВУ мову та встановить вказані переклади.
У режимі БАГАТОМОВНИЙ-ДИНАМІЧНИЙ всі переклади копіюються автоматично!
6.2 Окремі повідомлення (контейнер-таблиця "Trs")
Але не всі повідомлення в OpenSCADA пов'язано із її об'єктами, наприклад — процедури на внутрішній мові можуть містити текстові повідомлення, які варто перекладати окремо, а не цілком цю процедуру чим призводячи до логічної її розбіжності на різних мовах. Тому до мови внутрішніх процедур запроваджено функцію tr(), яка повертає переклад охопленого нею повідомлення згідно до ОСНОВНОЇ мови, або мови динамічного контексту у режимі БАГАТОМОВНИЙ-ДИНАМІЧНИЙ та якщо процедура із цим контекстом пов'язана.
Зв'язок динамічного контексту у режимі БАГАТОМОВНИЙ-ДИНАМІЧНИЙ передбачає власне виконання цієї процедури від користувача з окремою мовою або від мови, тобто лише для процедур графічного інтерфейсу СВУ, відтак виконання процедур джерел даних ніяк не може здійснюватися від якогось окремого користувача чи мови, тому вони завжди перекладаються ОСНОВНОЮ.
Для зберігання перекладу повідомлень такого кшталту спеціально передбачено окремий контейнер-таблицю "Trs", яка розташовується у сховку-БД що пов'язано із об'єктом OpenSCADA із такою процедурою. Повідомлення огорнуті функцією tr() потрапляють до таблиці "Trs" під час виконання цієї процедури або компіляції, для строкових літералів, та самі ці повідомлення у процедурі мають бути БАЗОВОЮ мовою. Наразі відсутня можливість відстеження зміни повідомлень, огорнутих функцією tr(), тому всі вони після виконання будуть там накопичуватися, але ви можете видалити їх вручну із контекстного меню менеджеру.
Копіювання об'єкту OpenSCADA із процедурами з одного сховку-БД до іншого не призводить до копіювання і перекладів між окремими контейнерами-таблицями "Trs", але ви можете виконати цю процедуру нового об'єкту, чим додати її до "Trs", а потім скопіювати й переклади за допомогою менеджеру перекладів (Рис.1).
7 Завдання із вдосконалення контролю перекладами та підвищення рівня охоплення
- - розробити механізм відстеження неактуальності повідомлень у таблиці "Trs"
- ?> можливо додати до таблиці "Trs" поле опцій, де позначати час оновлення-реєстрації та при компіляції або виконанні, відповідно очищати надто старі та оновлювані-реєстровані при компіляції