Без отправки файла перевода
На данный момент я много работаю с пакетами Angular, которые содержат разные компоненты, созданные мной на основе компонентов материалов по умолчанию. Эти меньшие пакеты служат для того, чтобы сделать общий проект немного чище и дифференцировать различные подпроекты.
В конце концов вы подойдете к тому моменту, когда вам нужно будет помнить, что компоненты, возможно, должны стать многоязычными.
Рассматривая перевод в контексте Angular, вы сначала сталкиваетесь с такими понятиями, как Интернационализация (i18n) или ngx-translate . Даже если i18n-out-of-the-box-решение не подходит для нашего приложения, ngx-translate превратился в это лучший вариант для меня лично, так как с ним намного проще работать и он не создает файлы на ходу.
Возможность повторного использования на первом месте
Поскольку эта тема была создана только по одной причине (возможность повторного использования), мы также придаем этому большое значение. Следовательно, необходимо создать прочную основу, на которой мы можем опираться. Итак, мы создаем новое приложение Angular и проект библиотеки - очень быстро вперед.
нг новый перевод
ng сгенерировать библиотеку ngx-translation
Другие параметры (угловая маршрутизация, hammerJS, тип таблицы стилей) не имеют значения, потому что мы не будем создавать повторно используемые компоненты в этом пакете.
Поскольку проект будет основан на ngx-translate, нам нужно будет установить эти две зависимости:
npm install @ ngx-translate / core @ ngx-translate / http-loader --save
После нескольких секунд ожидания все должно быть в порядке.
Эти зависимости лучше всего объявить в package.json ”библиотеки как зависимости или, по крайней мере, как одноранговые зависимости , поскольку это обязательно зависит от него.
Поскольку я также хочу переводить угловые компоненты материала, такие как paginator, я также добавил @ angular / material взаимозависимость.
Я также написал средний пост в блоге о зависимостях и версиях.
Также мы удаляем файлы компонентов из папки ./lib/, потому что нам нужны только модуль и сервис.
Это основа проекта. Далее мы продолжим работу с основой перевода.
Идея, лежащая в основе
Мы напишем собственный загрузчик, который читает основные файлы перевода (*.json) из приложения и объединяет их с переводом, предоставляемым каждым компонентом. Компоненты, которые нуждаются в переводе, должны быть зарегистрированы в службе реестра, чтобы мы могли прочитать перевод для каждого компонента.
Базовый перевод с помощью ngx-translate
В качестве следующего шага нам понадобится модуль, который мы позже сможем импортировать в другие пользовательские модули или проекты. Благодаря хорошей документации ngx-translate для общих модулей это очень просто. Итак, сначала мы создадим общий модуль в нашей библиотеке, который позже будет импортировать, экспортировать и предоставлять нам все необходимое для перевода пользовательских компонентов.
Он в основном импортирует TranslateModule из @ ngx-translate / core, определяет TranslationLoader (который является нашим собственным) для использования, предоставляет приложению службу TranslationRegistryService и функция инициализации (для установки параметров по умолчанию).
TranslationRegistryService
TranslationRegistryService должен быть простой службой, которая предоставляет загрузчику переводы компонентов. Итак, в основном он состоит из двух методов. Один метод должен сохранить привязку к зарегистрированному компоненту, а другой метод должен собрать переводы.
Чтобы идентифицировать каждый компонент, я добавил к нему свойство идентификации («id»). Также я выбрал тему уведомления моей переводческой службы, когда «регистрируется» новый компонент.
TranslationLoader
TranslationLoader выполняет реальную работу. Он должен загрузить обычные файлы перевода (в ./assets/i18n/*.json) и объединить их с предоставленными объектами перевода зарегистрированных компонентов. Перейдем к собственно кодированию.
Самое необходимое здесь - это функция слияния. Все стоит и падает с функцией слияния, которая объединяет основной объект перевода из файла JSON с объектами перевода компонентов.
Хороший пример можно найти здесь:
Поскольку мы предоставили наш пользовательский загрузчик в модуле, каждый раз перевод перезагружается (с помощью триггера или чего-то еще), загрузчик звонят. Остальная часть нашего кода пользовательского загрузчика выглядит следующим образом, в котором используются наши функции слияния:
Наш загрузчик переводов запрашивает самую новую версию файлов перевода (*.json) и использует функции слияния, чтобы объединить эти объекты с языковым объектом реестра переводов.
И последнее, но не менее важное: мы могли бы предоставить разработчику абстрактный класс, чтобы он не упустил необходимые функции:
Теперь разработчик может расширить этот абстрактный класс из своих компонентов. Он должен предоставить «id», который может быть просто именем компонента.
Внимание: он не работает с this.constructor.name, потому что он недоступен для производственных сборок.
Кроме того, требуется передать экземпляр TranslationRegistry-Instance для регистрации перевода. Если все это сделано, его можно использовать так же просто, как следующий код.
Дополнительный
В некоторых случаях необходимо перезагрузить текущий язык, что может сделать сервис ngx-translate.
Если все это сделано, перевод можно использовать, как правило, с помощью ngx-translate.
В моем следующем рассказе я опишу, как переводить материальные компоненты, такие как Пагинатор материалов
Заключение
Благодаря этой реализации и расширению пользовательского загрузчика довольно легко переводить пользовательские компоненты, которые поставляют свой собственный перевод и при этом сохраняют преимущества базового ngx-translate . Многоязычный!
Особая благодарность Томасу Себастьяну Йенсену, который предоставил мне отзыв.
Пожалуйста, не стесняйтесь оставлять отзывы.
