Comments 8
Такие же проблемы проходили — грузить все или кусками. Второй подход у нас нельзя было реализовать. Решили подмену токенов на сервере делать. Т.е сервер генерировал скрипты на каждый язык и возвращал в готовом виде
Интересный подход. В нашем случае мы могли бы в этом же сервере реализовать параметр с нужным скопом(токеном), и сервер бы возвращал только нужный кусок переводов. Это избавило бы нас от необходимости обрабатывать переводы при загрузке/выгрузке в poeditor. Но осталось бы неудобство при работе с огромным файлом при разработке.
angular.io/guide/i18n
Раньше пробовали работать с библиотекой ngx-translate, но потом решили выбрать собственный вариант Angular. В версии Angular 8 — время сборки составлял в несколько этапов и длился почти в двое больше, но с версии 9 — разница по времени нет, может на 3-4 секунда.
Собственный i18n — хорош и тем, что в DOM`е не будет лишних bind`ов, так как текст уже вшит в шаблон, а эта уже производительность на стороне клиента.
В частных случаях использовать встроенное решение действительно удобнее, и поддержка у него лучше. Но в нашем случае оно не подходит, потому что у в некоторых местах есть логика с динамической генерацией перевода, когда результат собирается из нескольких токенов по каким то параметрам, или когда перевод необходимо передать как аргумент в некий сервис (вроде сервиса показывания модальных окон, конфирмов и тд).
i18n на сколько я помню не поддерживает «живую смену языка», в нашем случае можно в настройках сменить язык и приложение не будет перезагружатся (а оно очень громоздкое), не нужны поддомены или доп роуты по локали
Тут все конечно зависит от проекта. Если вы не планируете в будущем добавлять много переводов, то наверное не стоит. И наоборот, если вы планируете добавить в ваш проект еще много переводов, возможно стоит их как можно раньше побить на модули, чтобы потом не пришлось рефакторить.
Из этого следует вопрос, а "много переводов" — это сколько? Ответ на этот вопрос тоже зависит от вашего проекта, ваших пользователей, их географической удаленности от хостинга проекта. Если ваши пользователи находятся далеко от хостинга, вы не используете cdn для хостинга переводов, и в вашем проекте не всем пользователям доступны все переводы (как, например, в нашем случае, из-за разграничения доступа), то вероятно не стоит заставлять пользователей выкачивать большой файл с переводами.
Но надо учитывать, что разделение переводов на чанки ускоряет только первичное отображение контента, при навигации по приложению пользователи наоборот получат задержку из-за докачивания переводов.
Ленивая подгрузка переводов с Angular