- Created by Unknown User (dv), last modified on 09.10.2014
Общие задачи
Реализовать систему локализации для JSON-коллекций, загружаемых при upgrade
Описание проблемы
На настоящий момент в JSON-коллекциях, загружаемых при upgrade отсутсвуют переводы на языки, отличные от английского. Для EventClass и AlarmClass предусмотрен механизм, позволяющий задать разные варанты перевода. Но он жестко зашит в код, не предусматривает каких-либо инструментов для локализаторов за исключением ручной правки JSON. Кроме того, все переводы устанавливаются в базу и извлекаются из MongoDB при каждом обращении к event class. Кроме того, отсутсвует механизм поиска по локализованным сообщениям.
Общие предположения
- Механизм должен выбирать сообщение на правильном языке в момент запуска upgrade и записывать его как обычное текстовое поле
- Любое текстовое поле имеет право на локализацию
- Локализаторы могут быть незнакомы с синтакисисом JSON
- Переводчики на разные языки могут быть не связаны друг с другом
- JSON-файлы создаются разными людьми и поступают в проект разными способами
- Помимо записей, импортированных из JSON каждая база NOC в процессе работы пополняется локально. Часть изменений может вернуться в проект
- В качестве базового языка для текста по историческим причинам принят английский (в королевском варианте)
- Список поддерживаемых переводов будет расти
Требования
# | Требования | С точки зрения пользователя | Важность | Примечания |
---|---|---|---|---|
1 | Переводы должны храниться в исходном JSON-файле | Каждый JSON является отдельным независимым объектом | Обязательно | Минимизация накладных расходов на ведение JSON-коллекции |
2 | Выбор правильного языка должен осуществляться в момент запуска upgrade. После установки ядро NOC должно обрабатывать переведенные поля как обычные текстовые | Администратор запустил upgrade и сделал себе хорошо | Обязательно | Минимизация расходов на разработку. Все тяжелые операции должны выполняться только в момент апгрейда |
3 | Любое текстовое поле в JSON можно локализовывать без модификации исходного кода NOC | JSON содержит в себе все необходимые декларации | Обязательно | |
4 | Необходимо иметь возможность задания нескольких языков локализации как глобально, так и на уровне коллекции. По возможности должен использоваться первый перевод. В случае его отсутсвия - следующий по приоритету, и так далее | В noc.conf добавляется секция для предпочтительных переводов как глобально, так и на уровне коллекции | Обязательно | В случае отсутствия перевода на родной язык возможен переход на родственный, но понятный пользователям системы. Например: украинский -> русский -> английский, каталонский -> испанский -> английский |
5 | В случае изменения сообщения на базовом языке остальные переводы должны быть помечены как нечеткие (fuzzy) | Локализаторы могут дополнительно проверять нечеткие и устаревшие переводы и приводить их в соответсвие | Желательно | В противном случае возможна рассинхронизация перевода с реальным смыслом |
6 | Локализаторы должны иметь возможность обнаруживать отсутствующие переводы для объектов | У локализатора есть инструмент для быстрого определения пропущенных переводов | Желательно | В противном случае возможны кусочные переводы и мешанина из языков |
7 | Контрибуторы должны иметь возможность присылать JSON даже в случае отсутсвия переводов сообщений на всех поддерживаемых языках | Контрибутор нажимает кнопку JSON и получает JSON-файл, достаточный для пересылки | Обязательно | При создании дополнительных сложностей контрибуторам поток изменений может сократиться |
Общий дизайн
Дополнительные соглашения при обработки JSON
Вместо текстового значения атрибута может быть указан особым образом сформатированый dict. Например
... "subject": "Link down" ...
может быть заменено на
... "subject": { "$i18n": { "en": "Link down", "ru": "Упал линк" } },
Признаками наличия переводов являюется:
- dict вместо строки
- единственный ключ $i18n в dict
- наличие ключа en во вложенном dict
Настройки
В noc.conf
[i18n] collection.global = ua,ru,en collection.fm.eventclasses = en collection.global.allow_fuzzy = true collection.gm.eventclasses.allow_fuzzy = false
Опция collection.global задает глобальные настройки для всех коллекций. Языки указываются через запятую, наиболее предпочтительными является первый в списке. В качестве fallback всегда используется английский (код en)
Настройки для коллекции перебивают глобальные.
Дополнительно настраивается возможность использования неточного перевода (allow_fuzzy), как глобально, так и на уровне коллекции
fuzzy translation
При изменении текста для первичного языка (en) все остальные переводы помечаются как нечеткие (fuzzy). Нечеткий перевод требует дополнительной проверки со стороны локализаторов, в противном случае смысл перевода может быть сильно искажен.
нечеткие переводы помечены соответсвующим префиксом.
... "subject": { "$i18n": { "en": "Network Link down", "ru": "[FUZZY] Упал линк" } },
При установке в базу префикс FUZZY удаляется и далее нигде, кроме JSON, не фигурирует.
upgrade
Upgrade строит список предпочтительных языков для коллекции. Процесс upgrade происходит в штатном режиме за одним исключением – если в качестве значения поля указан dict c размером в один ключ со значением $i18n, который в свою очередь также является dict, содержащим, как минимум, ключ en, то upgrade переходит в режим поиска перевода.
Upgrade проверяет наличие ключа для первого предпочтительного языка. Если перевод помечен как нечеткий, то проверяется соответсвующая настройка конфига. В случае неудачи проверяется следующий язык. И так далее. Для языка по умолчанию параметр fuzzy игнорируется.
В результате перевода получается строка, которая и записывается в базу.
Дополнительное приложения для локализаторов
Необходимо разработать дополнительное приложение (dev.translation) для локализаторов, позволяющее заводить переводы.
Приложение позволяет отфильтровывать только пропущенные или только нечеткие переводы.
При нажатии на кнопку Save происходит запись переводов в коллекции. При изменении нечеткого перевода признак FUZZY снимается
Открытые вопросы
Отрытые вопросы, нерешенные проблемы:
Вопрос | Варианты решения |
---|---|
Таблица кодов языков | Необходимо договориться о кодах языков, которые будут использоватсья для перевода |
Существует ли связь с таблицей Language | Необходимо понять, следует ли хранить коды языков трансляции в таблице Language |
Реакция при Install JSON, для национальных языков | Прописать алгоритм записи переведенного поля в JSON |
Related Issues
Отложенные задачи
- Список задач и предложений, которые были исключены из документа, но могут быть реализованы в рамках отдельных задач и предложений
Свойства
Epic | |
---|---|
Type | FEATURE |
Status | DRAFT |
Open Date | 2014-09-19 |
Modules | CORE |
Language | Russian |
Owner | Unknown User (dv) |
Designer | Unknown User (dv) |
Developers | |
QA | |
Close Date |
2 Comments
Unknown User (evyscr)
> Механизм должен выбирать сообщение на правильном языке в момент запуска upgrade и записывать его как обычное текстовое поле
Отказ от многопользовательского подхода? У одной инсталляции вполне могут быть разноязычные пользователи (как минимум, подобное наблюдалось для инсталляций других web-faced проектов).
С этой же точки зрения напрашивается вынос конфигурационных параметров в пользовательские настройки. В системных могли бы быть (по примеру одного rpm-based distro) список используемых (устанавливаемых - ради облегчения базы etc.) и дефолтная локаль.
> Вместо текстового файла может быть указан особым образом сформатированый dict
Требуется пример с текстовым файлом. Либо, если от этого планируется отказываться, указать это явно.
> При изменении нечеткого перевода признак FUZZY снимается
Видит ли локализатор признак [FUZZY]? Если да - он может удалить его вручную (как это и принято) после доведения строки до желаемого состояния. Лично я нередко оставлял данный признак при сомнении в правильности для последующей вычитки/правки.
Unknown User (dv)
Частично реализовано в FM