Transmaintain — Инструмент Для Поддержания Файлов Перевода Интерфейса Проекта Symfony В Согласованном Состоянии.

"Боль это боль, как бы вы это ни называли.

Это страх, а там, где есть страх, нет места любви».

Агата Кристи Сколько бы проектов ни прошло через мои руки, всегда одно и то же: файлы перевода в ужасном состоянии.

Лучше всего эту проблему выражают слова Агаты Кристи в начале статьи.

Лингвистические нюансы и качество переводов здесь обсуждаться не будут. Предположим, у нас есть отличные переводы.

В разрезе рассматриваются те проблемы, которые можно контролировать с помощью технических средств и предназначенных для этого инструментов.

Материал предназначен для людей, имеющих опыт работы с Symfony и консолью Linux в целом.

Также предполагается, что вы умеете подключать к проекту сторонние бандлы.

Поэтому некоторые вопросы не понимаются с позиции «все понятно».




Из всех проблем, связанных с переводами, есть такие, которые очень сложно контролировать техническими средствами.

Например, качество переводов, их смысловое значение и уместность использования тех или иных слов в той или иной части пользовательского интерфейса.

А есть такие, которыми довольно легко управлять технически.

Из последней категории, с чем мы обычно сталкиваемся на проектах, можно выделить:

  1. Отсутствие некоторых переводов.

    Даже если переводы добавлены для одного или двух языков, для остальных они не добавляются.

  2. Переводы вообще не добавлены.

  3. Использование похожих, но тем не менее разных ключей для одних и тех же переводов.

  4. Разные переводы одних и тех же ключей (дубликаты ключей).

    В результате получаем, что нужный перевод есть, но отображается не то, что мы ожидали.

Но это внешнее проявление проблемы.

Какова его основа? Посидев и подумав, что мешает застройщикам поддерживать их в хорошем состоянии, я выделил 3 основные причины:

  1. Всем людям удобно использовать отсортированные списки.

    Но что на самом деле видит в файлах разработчик? Все перепутано.

    Один бросил все в спешке, как это произошло.

    Другой просто поленился привести в порядок свои ключи.

    Сверху наслаивались слияния филиалов и разрешение конфликтов в них.

    А теперь в файлах черт ногу сломает.

  2. Вторая проблема тесно связана с первой: распределять переводы по файлам действительно долго и утомительно.

    Явно не то, что хотел бы сделать разработчик, хотя это часть его работы.

    Да и у застройщика не всегда есть время привести все в порядок.

    И все же существует вероятность механической ошибки.

  3. Где наши тесты? Ну, это правда.

    Есть отличные инструменты для тестирования кода.

    Например PHPUnit. А как насчет тестов файлов с переводами, которые можно легко настроить в CI проекта? И пусть каждый мерж-реквест проверяется, чтобы убедиться, что всё добавлено.

Первое, что я сделал, это поискал существующие инструменты.

Казалось, проблема стара как время и уже должно быть написано 100 500 инструментов.

Я посмотрел, что нам предоставляет стандартный пакет «symfony/translation».

Я гуглил инструменты разработчика, пока хватало терпения, но не нашел того, что искал.

Если в комментариях дадут ссылки на существующие инструменты, предназначенные для решения описанных в статье проблем, буду очень признателен.

Имея такой опыт, я решил создать свой собственный инструмент. Если модераторы пропустили, то здесь будет ссылка на репозиторий .

В противном случае найдите проект на Github. В текущей реализации проект представляет собой пакет для проектов Symfony 4.4+.

Ниже мы опишем, какие конкретно задачи решает пакет и как его использовать.



Борьба с беспорядком в файлах

Первое, на что я нацелился, — это «беспорядок» в файлах.

На всех последних проектах, где я работал и работаю, переводы хранятся в ЯМЛ файлы.

Я начал с них.

Их особенностью является возможность хранить ключи в виде структурированного, читаемого дерева.

При загрузке в передатчик они склеиваются через точку.

Помимо преимуществ, это дает возможность устанавливать разные переводы для одних и тех же клавиш, даже не замечая этого.

Итак, вам нужно сделать две вещи:

  1. Преобразование ключей.

    Где есть возможность, разделите склеенные через точку ключи, а где-то, наоборот, склейте их вместе, чтобы построить более компактное дерево.

  2. Сортировка по ключам.

Это упрощает поиск и применение существующих ключей.

А похожие ключи (с опечатками и дублями) будут рядом и их будет легче исправить.

Помимо простоты чтения и поиска существующих ключей, мы также получаем меньше конфликтов при слиянии веток.

Для этого была создана соответствующая консольная команда:

  
  
  
  
  
   

aeliot_trans_maintain:yaml:transform PATH_TO_FILE_IN PATH_TO_FILE_OUT

Вызывается как обычная команда Symfony. Если передается только один аргумент, PATH_TO_FILE_OUT становится равным PATH_TO_FILE_IN. Это дает пространство.

Добавление некоторых стандартных команд Linux, таких как находить или греп и теперь вы можете конвертировать все необходимые файлы.

Например, вы можете конвертировать все файлы YAML в определенном каталоге:

find PATH_TO_DIRECTORY -type f \( -iname \*.

yml -o -iname \*.

yaml \) | sort | xargs -I {} -t php bin/console aeliot_trans_maintain:yaml:transform $1{}



Находим и переводим все, чего не хватает

Далее вам нужно добавить недостающие переводы.

Самый простой способ — взять список недостающих переводов и закинуть его в переводчик, например Google Translate. Он хорошо переводит на европейские языки, например, с английского на немецкий или французский.

Можно сразу с ключей.

Затем исправьте ключи и вставьте их в нужный файл.

Для этой задачи также была создана команда:

bin/console aeliot_trans_maintain:yaml:export_missed_translations DOMAIN DONOR_LOCALE FILTER_BY_LOCALE

Где:

  • ДОМЕН — обрабатываемый домен.

  • DONOR_LOCALE — локаль, с которой берутся переводы
  • FILTER_BY_LOCALE — локаль, для которой происходит загрузка.

    Если указано, будут загружены только переводы, отсутствующие в этой локали.

    В противном случае всё, чего не хватает хотя бы в одной локали этого домена.

Ключи будут склеены.

Полученные данные загружаются в StdOut. Вы можете направить его непосредственно во временный файл.

Например:

bin/console a:y:e messages en de > .

/donor.txt

Если кто-то еще не знал, названия консольных команд в Symfony можно сокращать.

Например, как здесь по первым буквам.

Обычно я создаю еще один файл для данных из онлайн-переводчика и быстро исправляю ключи, сравнивая два файла в PhpStorm. После чего эти данные можно загрузить в целевой файл.

Конечно, для получения идеальных переводов нужна работа профессиональных переводчиков, но это тема для другой статьи.

Внимание! Все эти команды имеют одно ограничение.

Поскольку для создания файлов YAML используется стандартный дамп Symfony (\Symfony\Component\Yaml\Yaml::dump()), все переводы, состоящие из одного слова без специальных символов, не будут выгружаться.

Да, еще не идеально.

В будущем это планируется исправить.



Декоратор для переводчика

Еще один инструмент, обеспечивающий добавление всех переводов, — декоратор стандартного переводчика.

Включено в настройках пакета (ключ конфигурации: Insert_missed_keys).

После его включения все переключатели, вызванные во время работы проекта, но отсутствующие в файлах перевода, будут добавлены в соответствующий домен и локаль.

На данный момент принимает следующие значения:

  • нет - неполноценный.

    Значение по умолчанию.

  • конец — вставить найденные ключи в конец файла в склеенном виде
  • слить — встроить в дерево ключей.

    Это экспериментальная версия и будет развиваться дальше.

В настоящее время к использованию рекомендуются только следующие значения: нет И конец .

Также рекомендуется включать декоратор только в режиме dev и только временно, т.к.

сильно тормозит работу сайта.

В связи с тем, что файлы перевода постоянно меняются и из-за этого кэш постоянно сбрасывается и перестраивается.

Пример подключения в конфиге:

parameters: env(TRANS_MAINTAIN_INSERT_MISSED_KEYS): no aeliot_trans_maintain: insert_missed_keys: "%env(TRANS_MAINTAIN_INSERT_MISSED_KEYS)%"

После этого декоратор-переводчик легко включить/отключить, изменив значение ключа.

TRANS_MAINTAIN_INSERT_MISSED_KEYS В .

env или .

env.local файлы без риска закомментировать что-либо ненужное.

Большой.

Файлы были конвертированы.

Ошибки исправлены.

Добавлены недостающие переводы.

Все бы ничего.

но целостность переводов все равно зависит от разработчика.

А что насчет тестов? Где бы был современный проект без них?

Автоматическое тестирование переводов в проекте

Для проверки переводов создана команда:

aeliot_trans_maintain:lint:yaml KEY_1 KEY_2 KEY_N

Возвращает статус 0, если проблем не обнаружено, и 1, если проблемы есть.

И он предоставляет таблицы отчетов в StdOut. Принимает проверочные ключи или имена предустановок в качестве аргументов.

Может принимать несколько аргументов одновременно.

Пресеты:

  • база — выполнить базовые проверки, подходящие для большинства проектов (рекомендуется).

  • все — выполнить все возможные проверки.

    Зарезервировано для будущего использования.

    Теперь то же самое, что и base, за исключением того, что all должен быть единственным аргументом команды.

Проверьте ключи:
  • files_missed — проверяет наличие файлов домена перевода для всех локалей, используемых в проекте.

    Отображает таблицу пропущенных доменов перевода и локалей для каждого домена.

    Если домен представлен во всех локалях, он не будет включен в список.

  • ключи_пропущено — проверяет наборы ключей, используемые в разных локалях одного домена.

    Печатает домен, полученные ключи (объединенные точкой) и список локалей, в которых они отсутствуют. В список будут включены только ключи, отсутствующие хотя бы в одной локали.

  • ключи_дублированные — проверяет наличие дубликатов ключей.

    Отображает домен таблицы, локаль, ключ.

Клавиши проверки можно комбинировать с база .

Если вы укажете один и тот же ключ несколько раз, проверка будет выполнена один раз.

Теперь запуск этой команды можно настроить в CI и ни один мердж с неполными трансляциями не пройдет. Это, конечно, не защищает от того, что ни к одному файлу не будет добавлен какой-то ключ перевода, но значительно снижает количество проблем.



Планы на будущее.

Послесловие

В ближайшем будущем:
  1. Добавьте возможность проверки соответствия ключей определенному шаблону и возможность проверки отдельных доменов.

    В случае, если у проекта разные требования для разных доменов.

  2. Расширьте совместимость со старыми проектами.

  3. Также планируется реализовать использование Google/Yandex API для автоматических переводов.

    Для ряда проектов это вполне приемлемо.

Проект открытый.

Буду рад любому участию и здоровой критике в комментариях.

Теги: #открытый исходный код #тестирование ИТ-систем #symfony #автоматические тесты #переводы #переводчик
Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.