Створення багатомовного проєкту є нетривіальним завданням, яке торкається чи не всіх аспектів OpenSCADA, якщо метою є вичерпна багатомовність. Та загалом цей процес передбачає кроки:
Із самого переліку кроків видно, що багатомовний проєкт це не просто, якби саме середовище розробки OpenSCADA не намагалося спростити це завдання, тому, якщо ви реально бажаєте створення багатомовного проєкту, то маєте бути психологічно готовими до цих труднощів та значного об'єму роботи!
Цей крок залежить суто від автору проєкту та його завдання, але щодо БАЗОВОЇ мови наполегливо рекомендується обирати міжнародну — Англійську (en), та цей короткий посібник не розглядає інших варіантів. Хоча OpenSCADA загалом дозволяє встановити-обрати іншу мову БАЗОВОЮ із блокуванням файлів бібліотечних БД у режимі лише для читання, або виключення змін там чогось, оскільки БАЗОВОЮ мовою цих БД є саме Англійська (en)!
Окрім БАЗОВОЇ мови, для динамічної багатомовності вводиться поняття ОСНОВНОЇ мови, тобто мови локалі у якій запущено програму і якою буде надано повідомлення по замовченню та щодо мов для яких відсутній переклад.
Із процедурою перекладу системних повідомлень ви можете ознайомитися у короткому "Як виконати ...", який можна тут доповнити хіба тим, що для перекладу повідомлень інтерфейсу виконання можна перекласти лише повідомлення модулів побудови цих інтерфейсів, а саме UI.Vision та UI.WebVision.
Системні повідомлення так само динамічно перекладаються у режимі БАГАТОМОВНИЙ-ДИНАМІЧНИЙ відповідно до мови користувача та за віддаленого підключення, але є низка комбінованих попередньо-збережених повідомлень, переклад яких неможливо динамізувати та вони відповідно завжди представляються ОСНОВНОЮ.
Загалом OpenSCADA надає три режими:
Відповідно, завданням на цьому етапі є визначитися чи вам потрібна динамічна багатомовність (режим 3), чи цілком достатньо багатомовної конфігурації проєкту, який ви запускатимете на різних станціях у різних локалях-мовах.
На цьому етапі можна взагалі не перейматися багатомовністю, а реалізовувати проєкт у одній та бажано обраній як БАЗОВА.
Ви також можете просто взяти вже раніше розроблений одномовний проєкт, який бажаєте виконати багатомовним.
Всі основні дії із перекладами здійснюються у вкладці "Переклади" кореневої сторінки конфігурації станції, яку наведено на рисунку 1 та де розглянемо всі дії цього етапу.
У першу чергу маємо перемкнути проєкт попереднього етапу у режим багатомовності, для чого у визначеній вкладці вводимо код обраної раніш БАЗОВОЇ мови, або перелік локалей усіх мов проєкту із БАЗОВОЮ першою, що краще, оскільки тоді вони будуть підставлятися далі автоматично та використовуватися у перекладі системних-бібліотечних повідомлень як то місяці дати — на рисунку вказано "en_US.UTF-8;uk_UA.UTF-8;ru_RU.UTF-8", тобто базовою є Англійська (en). Якщо ще потрібна й динамічна багатомовність, то встановлюємо прапорець за полем мови, який є планом увімкнення багатомовності за наступного запуску. Тобто зберігаємо ці зміни до сховку проєкту та перезапускаємо його.
Якщо все відбулося коректно то після перезапуску у статусі перекладу маємо отримати "БАГАТОМОВНИЙ" або "БАГАТОМОВНИЙ-ДИНАМІЧНИЙ" та переходити безпосередньо до перекладу на цій самій вкладці, тобто у таблиці "Повідомлення". Якщо сама таблиця у вас ще відсутня то ви обрали не динамічний режим, де початково відсутній індекс повідомлень перекладу для побудови менеджеру-таблиці перекладу, але є поле "Ввімкнення менеджера", яке цей індекс формує.
Перед ввімкненням менеджеру перекладу, або початком роботи з ним у динамічному режимі, необхідно цілком завантажити всі повідомлення, що не відбувається автоматично для проєктів та бібліотек СВУ та що можна здійснити просто відкривши середовище розробки.
Після ввімкнення менеджеру перекладів, а відтак його появи, у полі "Мови контролю" та через символ розділювача ";" вказуєте перелік обраних мов за виключенням БАЗОВОЇ. Тепер ви можете здійснити переклад повідомлень у таблиці визначеними мовами та разом із БАЗОВОЮ, якщо початковою мовою проєкту була не вона.
Менеджер перекладів, а точніше процедура його формування, також здійснює низку перевірок із відповідними маркуваннями та прямі виправлення невідповідностей для максимального спрощення цього процесу, що вмикається відповідним прапорцем.
Більше дізнатися про особливість елементів інтерфейсу цієї сторінки можете на сторінці її опису.
Здійснюючи загальний переклад можна не занурюватися глибоко у деталі походження цих повідомлень та причини відсутності перекладу окремих з них, а також не перейматися питанням перенесення напрацювань цього проєкту зі збереженням перекладів та ключовим питанням того, що буде із перекладом у процесі його супроводу та розширення, тобто при зміні повідомлень у різних режимах перекладу та за різних мов локалі виконання проєкту.
Але якщо рівень перекладу є важливим, як і перелічені вище питання, то починаємо заглиблюватися...
Джерелом повідомлень, як і їх перекладу, може бути або контейнери-таблиці сховища із полями текстового типу від первинних ОБ'ЄКТІВ ПРОГРАМИ, назві яких передує код мови (db:SQLite.LibDB.flb_Controller#DESCR), або контейнер-таблиця "Tr" із ОКРЕМИМИ ПОВІДОМЛЕННЯМИ (db:SQLite.vcaBase.Trs#base).
Підтримка сховищем властивості перекладу (TR) власне і передбачає опрацювання перекладу первинних об'єктів програми, тому доцільно тут розглянути поведінку їх алгоритму у різних режимах багатомовності за різних локалей-мов виконання програми (БАЗОВА чи неБАЗОВА) та щодо текстового поля:
БАЗОВЕ повідомлення може бути спільним для декількох джерел тож ви не зможете відредагувати його перекладу окремо, але ви можете розділити його, із контекстного меню, за джерелами, а далі здійснити окремий переклад.
Копіювання об'єктів, як і перейменування, загалом здійснюється без урахування перекладу, тобто цільовий об'єкт його не матиме, більш того, ОСНОВНЕ повідомлення стане БАЗОВИМ, від мови виконання проекту, що корисно якщо ви копіюєте об'єкт для подальшого одномовного використання ОСНОВНОЮ мовою. Якщо-ж для цього об'єкту також потрібна багатомовність, то одразу після копіювання можете скористатися менеджером перекладу (Рис.1), який автоматично замінить БАЗОВУ мову та встановить вказані переклади.
У режимі БАГАТОМОВНИЙ-ДИНАМІЧНИЙ всі переклади копіюються автоматично!
Але не всі повідомлення в OpenSCADA пов'язано із її об'єктами, наприклад — процедури на внутрішній мові можуть містити текстові повідомлення, які варто перекладати окремо, а не цілком цю процедуру чим призводячи до логічної її розбіжності на різних мовах. Тому до мови внутрішніх процедур запроваджено функцію tr(), яка повертає переклад охопленого нею повідомлення згідно до ОСНОВНОЇ мови, або мови динамічного контексту у режимі БАГАТОМОВНИЙ-ДИНАМІЧНИЙ та якщо процедура із цим контекстом пов'язана.
Зв'язок динамічного контексту у режимі БАГАТОМОВНИЙ-ДИНАМІЧНИЙ передбачає власне виконання цієї процедури від користувача з окремою мовою або від мови, тобто лише для процедур графічного інтерфейсу СВУ, відтак виконання процедур джерел даних ніяк не може здійснюватися від якогось окремого користувача чи мови, тому вони завжди перекладаються ОСНОВНОЮ.
Для зберігання перекладу повідомлень такого кшталту спеціально передбачено окремий контейнер-таблицю "Trs", яка розташовується у сховку-БД що пов'язано із об'єктом OpenSCADA із такою процедурою. Повідомлення огорнуті функцією tr() потрапляють до таблиці "Trs" під час виконання цієї процедури або компіляції, для строкових літералів, та самі ці повідомлення у процедурі мають бути БАЗОВОЮ мовою. Наразі відсутня можливість відстеження зміни повідомлень, огорнутих функцією tr(), тому всі вони після виконання будуть там накопичуватися, але ви можете видалити їх вручну із контекстного меню менеджеру.
Копіювання об'єкту OpenSCADA із процедурами з одного сховку-БД до іншого не призводить до копіювання і перекладів між окремими контейнерами-таблицями "Trs", але ви можете виконати цю процедуру нового об'єкту, чим додати її до "Trs", а потім скопіювати й переклади за допомогою менеджеру перекладів (Рис.1).
| Documents/How_to/Create_multi_language_project/uk - GFDL | March 2024 | OpenSCADA 0.9.7 |
