Угловой 6 - i18n против ngx-translate

Ответ 1

Это слишком ново, чтобы взять на себя?

Это основано на мнениях, и, следовательно, вне темы

Видимо, у меня должен быть отдельный веб-сайт

Вам нужно отдельное приложение (например, index.html + bundles). Но вы можете обслуживать все эти приложения с одного URL-адреса, решая, какой из них будет обслуживаться на сервере. Это будет (надеюсь) изменяться с помощью Angular 7, когда будет доступен новый динамический i18n, построенный на вершине Айви.

это случай, когда файлы шаблонов динамически вставляются каждый раз?

Не уверен, что вы имеете в виду. Перевод языкового стандарта, который вы создаете, хранится в сгенерированных классах шаблонов во время компиляции компилятором Angular AOT.

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

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

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

Нет. Неэффективно.

Это то, что они называют JIT?

Нет. Компилятор JIT - это то, что компилирует ваши HTML-шаблоны в JavaScript при запуске, в браузере. В производстве вы используете компилятор AOT (который также используется для интеграции переводов в сгенерированные классы JS), который выполняет аналогичную компиляцию шаблонов, но во время сборки, а не во время выполнения.

Ответ 2

Дискуссия по-прежнему продолжается, и здесь вы можете найти ответы и мнения даже прямо от разработчиков Angular: https://github.com/ngx-translate/core/issues/495

Лично я бы структурировал приложение с официальным i18n и, в конце концов, добавил некоторый выделенный перевод в коде с помощью библиотеки ngx-translate.

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

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

Официальные доски объявлений и предлагаемый учебник

Ответ 3

Понятно, почему разработчики любят библиотеку типа ngx-translate, чтобы заботиться об интернационализации. В конце концов, это делает нашу жизнь настолько легкой, превращая задачу перевода в отображение 1 на 1. К сожалению, это не так, как это работает с человеческими языками. У одного есть два человека, которые знают более одного языка, чтобы лучше понять недостатки этого подхода.

Вот небольшой пример: скажем, у вас есть приложение для командировочных расходов, у вас есть табличное представление, в котором заголовок одного столбца - "время", указывающее, когда были сообщены расходы. Затем представьте, что в таком приложении у вас есть мини-калькулятор для базовой проверки ваших расходов, в котором есть кнопка умножения x с отложенным сообщением "время". Когда вы выполняете ngx-translate, вы извлекаете их обоих с одним и тем же ключом "TIMES", который, в свою очередь, переводчик возвращает вам один перевод. Но первое вхождение "время" не обязательно переводится так же, как и второе, во всех других языках. Взять, к примеру, испанский:

• "два раза три" (как в калькуляторе) → "dos POR tres"
• "ВРЕМЯ РАСХОДА" (как в табличном представлении) → "TIEMPOS de gasto"

Именно поэтому интернационализация движется в направлении использования более сложного формата, такого как XLF, для поддержки значения, описания (в случае Angular), а не старого стиля JSON с 1 глубиной, который не может быть приспособлен для перевода относительно контекста.

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

Чтобы ответить на ваш другой вопрос "Есть ли способ сделать живое переключение языков с помощью angular i18n?": Да, есть. Посмотрите на эту удивительную статью об управлении состоянием в приложениях. Короче говоря, вам нужно, чтобы ваш клиент и постоянные состояния отображались в URL. Тогда все, что вам нужно сделать, это добавить префикс локали к вашему пути, чтобы ваш веб-сервер дал вам правильную сборку локали. Тогда каким бы ни было состояние вашего приложения до изменения действия по изменению локали, его можно восстановить из URL (поскольку оно "отражает как постоянное состояние, так и состояние клиента").

Ответ 4

Одним из больших преимуществ Angular I18N является то, что его влияние на шаблоны минимально. Вам нужно только добавить атрибут i18n для каждого элемента, который вы хотите локализовать. Так

<p>Hello World<p>

становится

<p i18n>Hello World<p>

Не нужно много менять разметку и не нужно вручную поддерживать файл ресурсов. Если вы используете любую другую библиотеку I18N для Angular или React, вам нужно изменить свою разметку, например:

<p>Translate("Hello World")<p>

и вы должны вручную добавить строку в нейтральный файл ресурсов, такой как

"Hello World": "Hello World"

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

С Angular I18N вы используете инструмент извлечения для создания и поддержки нейтральных файлов ресурсов.

В Angular I18N в настоящее время отсутствует возможность локализовать строку в исходном коде. Однако эта функция появится в ближайшее время.