💌 Интернационализация в макетах и разработке (1/2)

Несколько постов назад, я писал о том, как оптимизировал ресайз и создание полноценных компонентов иконок для дизайн-системы, сохранив ребятам силы и время. Там же я обещал рассказать, как оптимизировал локализацию макетов.

Пацан сказал, пацан сделал.

Мы с разрабами договорились, что мы пойдем путем i18n. Чем интернационализация отличается от локализации прочитаете сами, если не лень.

Итак, диспозиция

Все переводимые тексты с макетов будут иметь ключи и значения. То есть любое слово в вашем UI имеет какой-то идентификатор (ключ), и через него мы будем получать итоговый текст. Из названия ключа должно быть понятно на какой из страниц продукта он задействован, в каком компоненте.

У нас будет единый способ написания ключей (camelCase, kebab-case и т.д.) и разделитель групп используем (в плагине, про который будет ниже, лучше использовать точку).

Например, из ключа checkout.LabelTotal можно понять, что это страница чекаута, этот текст из лейбла, и она означает итог. Если ключ переиспользуется сквозь весь продукт, то используется группа common, например common.statusDone.

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

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

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

В Confluence описано все вышесказанное с примерами, и там же выкладываются итоговые файлы локализации с указанием версии. Еще там было бы хорошо вести список изменений, но я его веду напрямую в Figma и пишу там в какой версии, что мы добавили.

Как все это готовить в Figma

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

Я же хочу иметь контроль над тем, как и что переводится, и не переводить вообще всё. Потому что какие-то данные мы получаем извне и они должны переводиться еще «там».

Плюс иметь возможность как-то этим всем оперировать. Например, зашить переменную в строку перевода или подкорректировать.

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

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

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

Есть возможность добавить переводы для множественного числа (заявка/заявки), возможность добавить в строку перевода переменную типа {{count}} или {{formattedNumber}}.

продолжение в следующем посте