В этой статье поделюсь личным кейсом который упростил нам работу с локалями, а именно слияние локалей и решение merge-конфликтов.
Независимо от того планируете вы выход на международный рынок или нет, использование i18n в проекте кажется очень логичным ходом хотя бы потому, что это упрощает перевод проекта на английский или любой другой язык, если такая необходимость назреет.
У нас есть довольно крупный проект, в котором используется i18n, а ещё есть «вариация» этого проекта, которая является форком (git-fork) исходного проекта. Над проектами трудятся разные команды разработчиков, которые развивают проект в смежных направлениях, но раз в какой-то период возникает необходимость «синхронизации» или обновления форков от базы. Естественно во время таких обновлений приходится решать изрядное количество merge-конфликтов. Со временем мы заметили, что один из самых сложных для слияния файлов является ru.json, в котором содержатся все наши текстовки для приложения на родном языке. И перед нами стал вопрос: как упростить себе жизнь во время решения конфликтов?
Сортируем json по алфавиту
Первая идея которая пришла нам в голову логично вытекает из опыта решения алгоритмических задачек на сравнение пары множеств. Перед тем как искать сходства или различия в множествах - неплохо было бы их заранее отсортировать. В принципе написать скрипт на node js, сортирующий json-файл не составляет труда, но мы решили воспользоваться уже готовым решением, а именно библиотекой json-sort-cli. Основные плюсы для нашего случая:
- Она ставится глобально, т.е. Мы ставим её на свою машину и не тянем лишние зависимости в проект
- Она сортирует объекты независимо от уровня вложенности
- Т.к. это Opensource-решение - это рабочая, протестированнная сообществом библиотека
Итак, после сортировки локалей в исходном проекте и в проекте слияния стало гораздо проще ориентировать в файлах локалей. Когда нужно срочно закончить фичу разработчик может добавлять ключи не заморачиваясь с тем чтобы сортировать ключи по алфавиту, затем он запускает скрипт и файл приводится в идеальный порядок. Соответственно решать конфликты тоже стало проще, когда оба файла отсортированы по алфавиту.
Ищем ошибки в файлах i18n
Но, тем не менее конфликты решает человек, текстовок в файлах уже несколько тысяч - не редки случаи, когда какие-то ключи случайно удаляются, что портит пользовательский интерфейс. Или же из одного проекта в другой «кочуют» ключи, которые в нём не используются.
И тут нам приходит на помощь ещё одна замечательная библиотека vue-i18n-extract.
У неё как и у первой библиотеки есть разные флаги, позволяющие использовать её в разных режимах, но главное чем она нам может быть полезна:
- Она подсвечивает что в проекте используется ключ, которому нет соответствия в файле локали
- Она показывает, что в файле локали присутствуют не используемые ключи
- Её так же не обязательно устанавливать в проект даже как devDependency, а можно использовать локально через npx
Используя пару этих библиотек мы значительно упростили себе жизнь и облегчили работу с файлами локалей. Берите на вооружение и пусть ваши json-файлы будут в идеальном порядке).