From OpenSCADAWiki
Jump to: navigation, search
This page contains changes which are not marked for translation.


Constr.png Creating now.


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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- розробити механізм транзитивного динамічного перекладу для джерел даних, тобто кінцеву реєстрацію та переклад повідомлень на боці динамічного контексту виконання СВУ
 !> потрібно для динамічних значень на кшталт статусів "ВВІМКНЕНО", "ЗАКРИТИ", ...
 !> потрібне для динамізації перекладу повідомлень на кшталт порушень, дій оператору; тобто такі повідомлення генеруються окремо від динамічних значень БАЗОВОЮ мовою, що потім розбирається — виокремлюється текст повідомлення без динаміки та яке потім вже реєструється-перекладається на станції-сервері візуалізації
- розробити механізм відстеження неактуальності повідомлень у таблиці "Tr"
 ?> можливо додати до таблиці "Tr" поле опцій, де позначати час оновлення-реєстрації та при компіляції або виконанні, відповідно очищати надто старі та оновлювані-реєстровані при компіляції