Откройте для себя возможности интернационализации Angular (i18n) и локализации (l10n)

Angular i18n и локализация приложений подверглись капитальному ремонту в версии 9, благодаря новому механизму рендеринга Ivy. В этой статье мы подробнее рассмотрим, как теперь работает этот встроенный пакет Angular, отметив при этом его преимущества и недостатки.

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

Интернационализация и локализация

Легко запутаться в терминах интернационализация (i18n) и локализация (i10n) и в том, где провести черту между ними. Интернационализация - это процесс разработки вашего приложения таким образом, чтобы его можно было адаптировать к различным языкам по всему миру, а локализация - это процесс создания версий приложений для разных языков.

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

Как работает локализация с Ivy

Новый процесс локализации Angular Ivy основан на концепции тегированных шаблонов. Теги позволяют анализировать литералы шаблона с помощью функции. Используемый здесь тег - это глобальный идентификатор $localize. Вместо перевода строк компилятор шаблонов Ivy преобразует весь текст шаблона, помеченный атрибутами i18n, в строки с тегами $localize.

Итак, когда мы добавляем:

<h1 i18n>Hello World!</h1>

Он будет скомпилирован для $localize вызовов, и где-нибудь в скомпилированном коде мы сможем найти:

$localize`Hello World!`

Принцип работы шаблона с тегами заключается в том, что вы помещаете функцию, которую хотите запустить, напротив строки перед шаблоном. Вместо function() у вас function`` или, как в данном случае, $localize``.

Когда этот шаг будет выполнен, у нас есть два варианта:

  • Встраивание во время компиляции: тег $localize преобразуется во время компиляции транспилятором, удаляя тег и заменяя буквальную строку шаблона переводом.
  • оценка времени выполнения: тег $localize - это функция времени выполнения, которая заменяет строку литерала шаблона переводами, загружаемыми во время выполнения.

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

В конце статьи мы подробнее рассмотрим оценку времени выполнения.

Поскольку приложение не нужно создавать заново для каждой локали, процесс сборки выполняется намного быстрее, чем до версии 9 в Angular.

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

Хорошее и плохое

Стандартная интернационализация и локализация Angular предназначены для создания одного скомпилированного приложения для каждого языка. Делая это, мы получаем оптимальную производительность, поскольку нет накладных расходов на загрузку файлов перевода и их компиляцию во время выполнения. Но это также означает, что каждый язык должен быть развернут по отдельному URL-адресу:

www.mydomain.com/en
www.mydomain.com/nb
www.mydomain.com/fi

Это означает, что нам нужно немного больше настроить наш веб-сервер. Ограничением ng serve является то, что он работает только с одним языком за раз, и для запуска разных языков также требуется некоторая настройка. Чтобы запускать все языки локально, нам нужно использовать локальный веб-сервер. В этой статье мы рассмотрим, как мы все это делаем.

Angular i18n использует форматы XLIFF и XMB, основанные на XML, более подробные форматы, чем JSON. Но поскольку эти файлы используются во время компиляции, это не имеет значения. Когда мы загружаем файлы перевода во время выполнения, имеет смысл использовать JSON, чтобы размеры файлов были меньше. Форматы, выбранные для встроенного i18n, используются программным обеспечением для перевода, которое, как мы увидим, помогает нам в наших переводах.

Недостаток номер один, который люди находят при использовании этого решения, заключается в том, что вам необходимо перезагружать приложение при переключении языков. Но действительно ли это будет проблемой для вас? Обычно люди меняют язык один раз, если вообще когда-нибудь. И те пару секунд, которые потребуются для перезагрузки приложений, не будут проблемой.

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

Прежде чем выбирать маршрут, важно понять свои требования.

Transloco

Если стандартный Angular i18n не дает того, что вы хотите, то лучшей альтернативой на сегодняшний день, на мой взгляд, является Transloco. Он активно поддерживается и имеет активное сообщество. Это позволит вам быстрее приступить к работе и более гибко, чем встроенное решение. Поскольку Transloco - это переводчик во время выполнения, у вас есть только www.mydoman.com и вы можете менять локализацию на лету.

Итак, прежде чем выбирать, какой путь сделать в таком фундаментальном выборе, вы должны проверить Transloco, чтобы увидеть, подходит ли он вам больше.

Хорошо, хватит технических деталей, давайте посмотрим код!

Добавить локализацию в проект Angular

Пакет @angular/localize был выпущен вместе с Angular 9 и поддерживает i18n в приложениях Ivy. Этот пакет требует существования глобального символа $localize. Символ загружается путем импорта модуля @angular/localize/init.

Чтобы добавить функции локализации, предоставляемые Angular, нам нужно добавить в наш проект пакет @angular/localize:

ng add @angular/localize

Эта команда:

  • Обновляет package.json и устанавливает пакет.
  • Обновления polyfills.ts для импорта пакета @angular/localize.

Если вы попытаетесь использовать i18n без добавления этого пакета, вы получите самоочевидное сообщение об ошибке, напоминающее нам запустить ng add @angular/localize.

Перевод шаблонов

Чтобы перевести шаблоны в нашем приложении, нам нужно сначала подготовить тексты, пометив их атрибутом i18n.

I18n - настраиваемый атрибут из API WebExtensions. Это признано инструментами и компиляторами Angular. Во время компиляции он удаляется, а содержимое тега заменяется переводами.

Помечаем текст так:

<span i18n>Welcome</span>

Этот тег <span> теперь отмечен и готов к следующему этапу процесса перевода.

Перевод файлов TypeScript

NB! Для извлечения строк из файлов исходного кода (.ts) вам потребуется Angular 10.1 или новее.

Переводить нужно не только наши шаблоны. Иногда у нас есть код в наших файлах TypeScript, который также нуждается в переводе. Чтобы локализовать строку в исходном коде, мы используем литерал шаблона $localize:

title = $localize`My page`;

Обратите внимание, что шаблонные литералы используют обратную кавычку (`) вместо двойных или одинарных кавычек.

Извлечение текстов

Когда наше приложение готово к переводу, мы можем использовать команду extract-i18n для извлечения отмеченных текстов в файл исходного языка с именем messages.xlf .

Мы можем использовать следующие параметры команды:

  • --output-path: изменить расположение файла исходного языка.
  • --outFile: изменить имя файла.
  • --format: изменить формат файла. Возможные форматы: XLIFF 1.2 (по умолчанию), XLIFF 2 и Пакет сообщений XML (XMB).

Выполнение этой команды из корневого каталога проекта:

ng extract-i18n

Получаем messages.xlf файл следующего вида:

Мы видим, что в файле есть тексты «Добро пожаловать» и «Моя страница», но что все это значит?

  • trans-unit - тег, содержащий единственный перевод. id - это идентификатор перевода, который генерирует extract-i18n, поэтому не изменяйте его!
  • source содержит исходный текст перевода.
  • context-group указывает, где можно найти данный перевод.
  • context-type="sourcefile" показывает файл, откуда взят перевод.
  • context-type="linenumber" сообщает строку кода перевода.

Теперь, когда мы извлекли исходный файл, как нам получить файлы на языках, которые мы хотим перевести?

Создать файлы перевода

После того, как мы сгенерировали файл messages.xlf, мы можем добавить новые языки, скопировав его и присвоив новому файлу имя в соответствии с ассоциированной локалью.

Для хранения норвежских переводов мы переименовываем скопированный файл в messages.nb.xlf. Затем мы отправляем этот файл переводчику, чтобы он мог переводить с помощью редактора XLIFF. Но давайте не будем опережать нас и сначала сделаем перевод вручную, чтобы лучше понять файлы перевода.

Перевод файлов вручную

Откройте файл и найдите элемент <trans-unit>, представляющий перевод тега приветствия <h1>, который ранее был помечен атрибутом i18n. Дублируйте элемент <source>...</source> в текстовом узле, переименуйте его в target, а затем замените его содержимое норвежским текстом:

Это все, что нужно для добавления переводов в файлы. Посмотрим, как мы это сделаем с редактором.

Перевод файлов с помощью редактора

Прежде чем мы сможем использовать редактор, нам нужно указать язык перевода. Мы можем сделать это, добавив атрибут target-language для тега файла, чтобы программное обеспечение для перевода могло определить языковой стандарт:

<file source-language="en-US" datatype="plaintext" original="ng2.template" target-language="nb">

Давайте откроем этот файл в инструменте перевода, чтобы увидеть, с чем мы работаем. В этой статье я использую бесплатную версию PoEdit:

С этим выглядит намного проще работать, чем с ручным способом. Мы даже получаем предложения по переводу. Давайте переведем «мою страницу» и сохраним файл. Если мы затем откроем messages.nb.xlf, мы увидим, что он добавил перевод в целевой блок, как когда мы делали это вручную:

<source>My page</source>
<target state="translated">Min side</target>

Мы видим, что он добавил state="translated" к целевому тегу. Это необязательный атрибут, который может иметь значения translated, needs-translation или final. Это помогает нам при использовании редактора находить тексты, которые еще не переведены.

Это отличное начало, но прежде чем мы опробуем переводы в нашем приложении, давайте посмотрим, что еще мы можем сделать, добавив дополнительную информацию в поле на снимке экрана с названием «Примечания для переводчиков».

Примечания для переводчиков

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

<span i18n="Welcome message">Welcome</span>

Мы можем добавить переводчику еще больше контекста, добавив значение текстового сообщения. Мы можем добавить значение вместе с описанием и разделить их символом |: <meaning>|<description>. В этом примере мы могли бы сообщить переводчику, что это приветственное сообщение находится на панели инструментов:

<span i18n="toolbar header|Welcome message">Welcome</span>

Последняя часть, которую мы можем добавить к значению атрибута i18n, - это идентификатор с помощью @@. Обязательно укажите уникальные пользовательские идентификаторы. Если вы используете один и тот же идентификатор для двух разных текстовых сообщений, извлекается только первое, а его перевод используется вместо обоих исходных текстовых сообщений.

Здесь мы добавляем ID toolbarHeader:

<span i18n="toolbar header|Welcome message@@toolbarHeader">Welcome</span>

Если мы не добавим идентификатор для перевода, Angular сгенерирует случайный идентификатор, как мы видели ранее. Запустив ng extract-i18n снова, мы видим, что в нашу единицу перевода добавлена ​​полезная информация:

  • Теперь есть пара тегов note, которые обеспечивают перевод description и meaning, и id больше не является случайным числом.

Если мы скопируем их в файл messages.ng.xlf и откроем его в PoEdit, мы увидим, что все они теперь видны в «Примечаниях для переводчиков»:

Предоставление контекста в файлах TypeScript

Как и в случае с шаблонами Angular, вы можете предоставить переводчикам больше контекста, указав meaning, description и id в файлах TypeScript. Формат такой же, как и для маркеров i18n в шаблонах. Вот различные варианты из Angular Docs:

$localize`:meaning|description@@id:source message text`;
$localize`:meaning|:source message text`;
$localize`:description:source message text`;
$localize`:@@id:source message text`;

Добавление id и description к нашему заголовку может выглядеть так:

title = $localize`:Header on first page@@firstPageTitle:My page`;

Если строка литерала шаблона содержит выражения, вы можете указать имя заполнителя, заключенное в : символов, непосредственно после выражения:

$localize`Hello ${person.name}:name:`;

Специализированные варианты использования

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

Разные языки имеют разные правила множественного числа и грамматические конструкции, которые могут затруднить перевод. Чтобы упростить перевод, мы можем использовать plural для обозначения использования множественного числа и select для обозначения альтернативных вариантов текста.

Атрибуты

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

Возьмем, к примеру, тег img. Люди, использующие программу чтения с экрана, не увидят изображение, но вместо этого им будет прочитан атрибут alt. По этой и другим причинам, по возможности указывайте полезное значение для alt.

<img [src]="logo" alt="Welcome logo" />

Чтобы пометить атрибут для перевода, добавьте i18n-, а затем атрибут, который переводится. Чтобы отметить атрибут alt в теге img, мы добавляем i18n-alt:

<img [src]="logo" i18n-alt alt="Welcome logo" />

В этом случае текст «Приветственный логотип» будет извлечен для перевода.

Вы также можете присвоить значение, описание и собственный идентификатор с помощью синтаксиса
i18n-attribute="<meaning>|<description>@@<id>".

Множественное число

Правила плюрализации для разных языков различаются. Нам необходимо учитывать все возможные случаи. Мы используем предложение plural, чтобы отмечать выражения, которые мы хотим перевести, в зависимости от количества тем.

Например, представьте, что мы выполняем поиск и хотим показать, сколько результатов было найдено. Мы хотим показать «ничего не найдено» или количество результатов, к которым добавлены «найденные элементы». И, конечно, не забываем про случай только с одним результатом.

Следующее выражение позволяет нам переводить различные множественные числа:

<p i18n>
{itemCount, plural, =0 {nothing found} =1 {one item found} other {{{itemCount}} items found}}</p>
  • itemCount - это свойство с количеством найденных элементов.
  • plural определяет тип перевода.
  • В третьем параметре перечислены все возможные случаи (0, 1, другое) и соответствующий текст для отображения. other ловит непревзойденные случаи. Angular поддерживает больше категорий, перечисленных здесь.

Когда мы переводим множественное число, у нас есть две транс-единицы: одна для обычного текста, помещенного перед множественным числом, и одна для множественного числа.

Альтернативы

Если ваш текст зависит от значения переменной, вам нужно перевести все альтернативы. Как и plural, мы можем использовать предложение select, чтобы отмечать варианты альтернативных текстов. Это позволяет вам выбрать один из переводов на основе значения:

<p i18n>Color: {color, select, red {red} blue {blue} green {green}}</p>

В зависимости от значения color мы отображаем «красный», «синий» или «зеленый». Например, при переводе множественного числа мы получаем две транс-единицы:

Редакторы понимают эти блоки и помогают нам с переводами:

Интерполяция

Давайте объединим приветственное сообщение со свойством title:

<h1 i18n>Welcome to {{ title }}</h1>

Это помещает в текст значение переменной title, которую мы ранее перевели. Когда мы извлекаем этот текст, мы видим, как обрабатывается интерполяция:

<source>Welcome to <x id="INTERPOLATION" equiv-text="{{ title }}"/></source>

Для перевода <x.../> остается неизменным для целевого языка:

<target>Velkommen til <x id="INTERPOLATION" equiv-text="{{ title }}"/></target>

И это последний пример переводов, который мы рассматриваем. Теперь давайте посмотрим, как мы можем настроить и запустить эти приложения на нашем новом языке!

Настройка локалей

Чтобы иметь возможность запускать наше приложение на многих языках, нам необходимо определить локали в конфигурации сборки. В файле angular.json мы можем определить локали для проекта с помощью параметра i18n и locales, который сопоставляет идентификаторы локали с файлами перевода:

Здесь мы добавили конфигурацию для норвежского языка. Мы указываем путь к файлу перевода для локали "nb". В нашем случае файл все еще находится в корневом каталоге.

sourceLocale - это языковой стандарт, который вы используете в исходном коде приложения. По умолчанию это en-US, поэтому мы можем не указывать эту строку или изменить ее на другой язык. Какое бы значение мы здесь ни использовали, оно также используется для создания приложения вместе с locales, которое мы определяем.

Чтобы использовать определение локали в конфигурации сборки, используйте параметр "localize" в angular.json, чтобы сообщить CLI, какие языковые стандарты следует сгенерировать для конфигурации сборки:

  • Установите "localize" на true для всех языковых стандартов, ранее определенных в конфигурации сборки.
  • Задайте "localize" в качестве массива подмножества ранее определенных идентификаторов языковых стандартов, чтобы создавать только эти версии языковых стандартов.

Сервер разработки поддерживает локализацию только одного языкового стандарта за раз. Установка для параметра "localize" значения true вызовет ошибку при использовании ng serve, если определено более одной локали. Установка параметра на конкретный языковой стандарт, например "localize": ["nb"], может работать, если вы хотите разработать для определенного языкового стандарта.

Поскольку мы хотим иметь возможность ng serve работать с нашим приложением на одном языке, мы создаем настраиваемую конфигурацию, зависящую от языкового стандарта, указав один языковой стандарт в angular.json следующим образом:

С этим изменением мы можем обслуживать норвежскую версию приложения и убедиться, что переводы работают, отправив nb в параметр configuration:

ng serve --configuration=nb

Мы также можем создать приложение с определенным языковым стандартом:

ng build --configuration=production,nb

Или со всеми языками сразу:

ng build --prod --localize

Другими словами, это более гибко настроить так, как мы, но мы также могли бы просто установить localize и aot в значение true и покончить с этим.

Локальная работа на нескольких языках

Из соображений производительности при запуске ng serve одновременно поддерживается только один языковой стандарт. Как мы видели ранее, мы можем обслуживать определенные языки, отправив локаль в параметр configuration. Но как мы можем запустить приложение со всеми настроенными языками?

Несколько языков

Чтобы запустить все языки одновременно, нам нужно сначала собрать проект. Мы можем создавать приложения с языковыми стандартами, определенными в конфигурации сборки, с помощью параметра localize:

ng build --prod --localize

Когда сборка локализована и готова, нам нужно настроить локальный веб-сервер для обслуживания приложений. Помните, что у нас есть одно приложение на каждый язык, что немного усложняет этот процесс.

В Angular Docs есть пара примеров серверного кода, который мы можем использовать.

Nginx

Чтобы наше приложение заработало, нам необходимо:

  1. Установите Nginx
  2. Добавить конфиг из Angular Docs в conf/nginx.conf
  3. Создавайте наши приложения
  4. Скопируйте приложения в папку, определенную в root в nginx.conf.
  5. Открыть браузер в localhost

Порт установлен в listen и обычно установлен на 80. Вы можете изменить язык, изменив URL-адрес. Теперь мы должны увидеть наше норвежское приложение по адресу localhost/nb.

Вот пример файла nginx.conf:

Если мы используем Nginx в продакшене, имеет смысл протестировать с ним и наше приложение локально.

Развернуть в производство

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

Мы должны учитывать, запускаем ли мы приложение локально или в производственной среде. Мы можем сделать это, используя isDevMode, который возвращает, находится ли Angular в режиме разработки:

isDevMode() ? '/' : `/${locale}/`;

Итак, когда мы запускаем приложение локально с ng serve, мы не добавляем языковой стандарт к URL-адресу, как мы это делаем, когда локализуем приложение в производственной сборке.

Обслуживание приложения

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

Самая большая проблема - это обработка файлов перевода. Нам нужно убедиться, что отмеченные тексты попадают к переводчикам и обратно в приложение до его развертывания. Чтобы помочь в этом, нам нужно найти способ автоматизировать создание файлов перевода и получать уведомление, когда переводы отсутствуют.

Создание файлов перевода

Продолжать объединять файлы переводов вручную нецелесообразно. Нам нужна автоматизация! Для этого я использую бесплатный инструмент под названием Xliffmerge.

Поскольку у этого инструмента есть старые версии Angular как peerDependencies, нам нужно использовать --legacy-peer-deps, если мы используем новую версию NPM (v7), которая в противном случае не удалась бы при установке.

Документация для Xliffmerge ориентирована на более старые версии Angular, но после некоторых экспериментов я обнаружил, что этого достаточно, чтобы установить пакет @ngx-i18nsupport/tooling:

npm install -D @ngx-i18nsupport/tooling --legacy-peer-deps

Обратите внимание, что -D устанавливается в devDependencies, и для использования в конвейере CI вы должны опустить его для использования в dependencies.

Затем мы можем добавить новые языки в конфигурации в angular.json под projects -> projectName -> architect -> xliffmerge.

После добавления новых переводов мы можем извлечь их и перенести в наши файлы переводов, запустив этот скрипт:

ng extract-i18n && ng run projectName:xliffmerge

Мы получаем пару предупреждений при запуске скрипта, которые говорят нам, что он работает!

WARNING: merged 1 trans-units from master to "nb"
WARNING: please translate file "messages.nb.xlf" to target-language="nb"

После этого вы можете раздать языковые файлы переводчикам. А когда переводы закончены, файлы нужно объединить обратно в репозиторий проекта.

Небольшое предупреждение, что эта библиотека не поддерживалась активно на момент написания этой статьи, поэтому вы можете изучить другие варианты. Есть Angular проблема слияния переведенных файлов. Иди и проголосуй, если ты думаешь, что это то, что нам нужно!

Отсутствующие переводы

Еще один способ убедиться, что переводы действительны, - привлечь внимание, если переводы отсутствуют. По умолчанию сборка завершается успешно, но выдается предупреждение об отсутствии переводов. Мы можем настроить уровень предупреждения, генерируемого компилятором Angular:

  • error: отображается сообщение об ошибке, и процесс сборки прерывается.
  • warning (по умолчанию): показать предупреждение об отсутствии перевода в консоли или оболочке.
  • ignore: Ничего не делать.

Укажите уровень предупреждения в разделе параметров для цели сборки вашего файла конфигурации Angular CLI, angular.json. В следующем примере показано, как установить уровень предупреждения об ошибке:

"options": {
  "i18nMissingTranslation": "error"
}

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

Форматировать данные в зависимости от языкового стандарта

При локализации приложений следует учитывать не только языки. Еще пара наиболее очевидных вещей, о которых нам нужно подумать, - это то, как мы представляем даты и числа нашим местным клиентам.

В Angular мы предоставляем токен LOCALE_ID для установки языкового стандарта приложения и регистрации данных языкового стандарта с помощью registerLocaleData(). Когда мы используем параметр --localize с ng build или запускаем флаг --configuration с ng serve, Angular CLI автоматически включает данные локали и устанавливает значение LOCALE_ID.

Установив LOCALE_ID на правильный языковой стандарт, мы можем использовать встроенные каналы Angular для форматирования наших данных. Angular предоставляет следующие каналы:

  • DatePipe: форматирует значение даты.
  • CurrencyPipe: преобразует число в строку валюты.
  • DecimalPipe: Преобразует число в строку десятичного числа.
  • PercentPipe: преобразует число в строку с процентами.

Например, {{myDate | date}} использует DatePipe для отображения даты в правильном формате. Мы также можем использовать каналы в файлах TypeScript, если мы предоставляем их модулю.

Переводы во время выполнения

Когда мы запускаем ng serve --configuration=xx или ng build --localize, приложение компилируется и транслируется перед запуском. Однако, если мы не укажем Angular локализовать наше приложение, тогда теги $localize останутся в коде, и вместо этого можно будет выполнить перевод во время выполнения.

Это означает, что мы можем отправить одно приложение и загрузить нужные переводы до запуска приложения. В @angular/localize есть функция loadTranslations, которую можно использовать для загрузки переводов в форме пар ключ / значение перед запуском приложения.

Поскольку переводы должны быть вызваны перед импортом любого файла модуля, мы можем поместить его в polyfills.ts. Вы также можете использовать его в main.ts, используя динамический import(...) для модуля.

Вот пример использования loadTranslations в polyfills.ts:

import '@angular/localize/init';
import { loadTranslations } from '@angular/localize';
loadTranslations({
  'welcome': 'Velkommen'
});

Обратите внимание, что результат этого фактически такой же, как и при переводе во время компиляции. Перевод выполняется только один раз. Если вы хотите изменить язык во время выполнения, вы должны перезапустить все приложение. Поскольку $localize сообщения обрабатываются только при первом обращении, они не обеспечивают динамического изменения языка без обновления браузера.

Основное преимущество - возможность развертывания в проекте одного приложения с множеством файлов перевода. Документация по этой части все еще отсутствует, но, надеюсь, мы получим официальную документацию о том, как лучше всего работать с loadTranslations и $localize. Существуют сторонние библиотеки, такие как Soluling, которые пытаются восполнить пробелы.

Если вы ищете динамичное и удобное для выполнения решение, то вам следует использовать Transloco.

Заключение

Мы начали эту статью с изучения того, как новый движок Ivy изменил i18n и локализации приложений с помощью Angular. Мы изучили, какие преимущества и недостатки это влечет за собой, и нужно ли и когда использовать альтернативные решения.

Затем мы рассмотрели возможность добавления встроенного пакета в решение и того, как мы помечаем тексты для перевода. Мы узнали, как настроить приложение для локализации, и добавили инструменты для управления нашими файлами переводов. Когда мы использовали редактор для перевода, мы увидели, как помогает добавление контекста к переводам.

Наконец, после настройки и перевода приложения мы настроили веб-сервер для обслуживания нашего приложения как локально, так и в производственной среде.

Локализация приложения состоит из множества частей, и я надеюсь, что после прочтения этой статьи вы лучше поймете, как создавать и управлять многоязычными приложениями с помощью Angular.

Ресурсы