Тут все конечно зависит от проекта. Если вы не планируете в будущем добавлять много переводов, то наверное не стоит. И наоборот, если вы планируете добавить в ваш проект еще много переводов, возможно стоит их как можно раньше побить на модули, чтобы потом не пришлось рефакторить.
Из этого следует вопрос, а "много переводов" — это сколько? Ответ на этот вопрос тоже зависит от вашего проекта, ваших пользователей, их географической удаленности от хостинга проекта. Если ваши пользователи находятся далеко от хостинга, вы не используете cdn для хостинга переводов, и в вашем проекте не всем пользователям доступны все переводы (как, например, в нашем случае, из-за разграничения доступа), то вероятно не стоит заставлять пользователей выкачивать большой файл с переводами.
Но надо учитывать, что разделение переводов на чанки ускоряет только первичное отображение контента, при навигации по приложению пользователи наоборот получат задержку из-за докачивания переводов.
В частных случаях использовать встроенное решение действительно удобнее, и поддержка у него лучше. Но в нашем случае оно не подходит, потому что у в некоторых местах есть логика с динамической генерацией перевода, когда результат собирается из нескольких токенов по каким то параметрам, или когда перевод необходимо передать как аргумент в некий сервис (вроде сервиса показывания модальных окон, конфирмов и тд).
Интересный подход. В нашем случае мы могли бы в этом же сервере реализовать параметр с нужным скопом(токеном), и сервер бы возвращал только нужный кусок переводов. Это избавило бы нас от необходимости обрабатывать переводы при загрузке/выгрузке в poeditor. Но осталось бы неудобство при работе с огромным файлом при разработке.
Тут все конечно зависит от проекта. Если вы не планируете в будущем добавлять много переводов, то наверное не стоит. И наоборот, если вы планируете добавить в ваш проект еще много переводов, возможно стоит их как можно раньше побить на модули, чтобы потом не пришлось рефакторить.
Из этого следует вопрос, а "много переводов" — это сколько? Ответ на этот вопрос тоже зависит от вашего проекта, ваших пользователей, их географической удаленности от хостинга проекта. Если ваши пользователи находятся далеко от хостинга, вы не используете cdn для хостинга переводов, и в вашем проекте не всем пользователям доступны все переводы (как, например, в нашем случае, из-за разграничения доступа), то вероятно не стоит заставлять пользователей выкачивать большой файл с переводами.
Но надо учитывать, что разделение переводов на чанки ускоряет только первичное отображение контента, при навигации по приложению пользователи наоборот получат задержку из-за докачивания переводов.
В частных случаях использовать встроенное решение действительно удобнее, и поддержка у него лучше. Но в нашем случае оно не подходит, потому что у в некоторых местах есть логика с динамической генерацией перевода, когда результат собирается из нескольких токенов по каким то параметрам, или когда перевод необходимо передать как аргумент в некий сервис (вроде сервиса показывания модальных окон, конфирмов и тд).
Интересный подход. В нашем случае мы могли бы в этом же сервере реализовать параметр с нужным скопом(токеном), и сервер бы возвращал только нужный кусок переводов. Это избавило бы нас от необходимости обрабатывать переводы при загрузке/выгрузке в poeditor. Но осталось бы неудобство при работе с огромным файлом при разработке.