Хотелось бы увидеть возможность делать динамические привязки в режиме aot. В частности, есть два варианта использования, подтверждающих, почему это следует добавить в дорожную карту.

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

Второй — это случай, когда вы встраиваете приложение в мобильное устройство с помощью Cordova. Насколько я знаю, вы можете выбрать jit, что замедлит работу сайта, создаст отдельное приложение для каждого языка или включит каждый язык в приложение (что, конечно, раздует его). Ни один из этих вариантов не является хорошим. Кажется, Ionic не использует i18n, и мне интересно, не в этом ли причина.

@ jlutz777 это 2 допустимых варианта использования, эта тема недавно обсуждалась внутри компании, и я тоже выступал за это. Это пока нелегко сделать, учитывая, как i18n и AoT работают в Angular, но это может быть в будущем, когда мы получим новый процесс компиляции для AoT в v5.
Я добавлю его в дорожную карту один раз/если у нас будет что-то официальное и конкретное по этому поводу.

Я работаю над приложением Electron + Angular 2 и теперь пытаюсь добавить поддержку локализации для нескольких языков, используя функцию i18n с Angular. На самом деле извлечение строки шаблона и преобразование их в форматы файлов на разных языках четко задокументированы, хотя я до сих пор не могу понять и найти:

• Могу ли я переключать язык динамически? или мне нужно создать приложение отдельно для другого языка.
• Могу ли я управлять/консолидировать все строки в одном месте (в виде пары ключ/значение), чтобы я мог изменить
  строка в одном месте будет выполняться в нескольких местах?
• Могу ли я получить доступ к локализованному файлу из любого места, кроме шаблона, чтобы получить строку на определенном языке с помощью
  предоставили ключ? (так же, как я спросил выше).

Пункты 2 и 3 будут решены с помощью функции «Использовать строки перевода вне шаблона — #11405».
По пункту 1 см. Ответ, который я дал @jlutz777 выше. На данный момент вам все еще нужно создавать приложение на нескольких языках или использовать JIT, который может динамически загружать переводы при начальной загрузке (он не переключается во время выполнения, но все же лучше, чем связывать его x раз).

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

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

Привет @ocombe . Похоже, мы собираемся использовать i18n в Angular для нашего приложения. Есть ли в документах какие-либо функции, которые, по вашему мнению, могут стать устаревшими или в ближайшие месяцы будут внесены серьезные изменения? Любая информация будет принята с благодарностью. И еще раз спасибо за DVD!

Привет @rjsteinert! Рад это знать!
На данный момент запланировано только одно критическое изменение — автоматическое создание идентификаторов. Метод изменится, и идентификаторы больше не будут совпадать, но будет инструмент миграции cli для обновления ваших файлов перевода (и параметр, который вы можете использовать для миграции только тогда, когда будете готовы).

Сегодня я много гуглил по этой теме, и мне интересно, может ли быть «простое» решение, такое как замена тегов i18n вызовом службы вместо перевода?

Текущий:
<span i18n>Hello world</span> => преобразовано в <span>Hello world</span>

Моя идея:
<span i18n>Hello world</span> => преобразовано в <span>{{i18nservice.translate('pass-in-the-generated-message-id')}}</span>

Таким образом, реальный перевод может быть выполнен динамически в AOT, поскольку служба может быть заполнена из API, файла и т. Д., И даже переключение локалей не будет намного больше, чем i18nservice.setLocale('de-DE') с загрузкой нового источника.
Извлечение текста с помощью xi18n-tool по-прежнему будет работать, как и раньше, и мы все равно сможем использовать сгенерированные идентификаторы сообщений в качестве индекса для службы перевода.
Текущая реализация также будет работать безупречно, так как ngc может просто искать флаг «--use-i18nservice» и компилировать, как и раньше.

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

Есть мысли по этому поводу?

Это одна из вещей, которые мы рассматриваем. Да, все еще существует проблема того, как обрабатывать блоки кода внутри этих переводов, когда компилятор недоступен во время выполнения (AOT). Это означало бы, что мы не можем использовать угловые компоненты/директивы/каналы внутри переводов...

Да, об этом не подумал.
В настоящее время я разрабатываю POC/обходной путь, который встраивает все переводы в HTML на этапе сборки (веб-пакет), оборачивая их в ng-контейнеры с помощью ng-switch.
Для атрибутов i18n используется директива, устанавливающая их в nativeElement.
Сами переводы также «рендерятся», чтобы заменить все эти заполнители <x id=".. "/> .

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

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

Репо: https://github.com/actra-development-oss/ng-i18n-aot-loader
NPM: https://www.npmjs.com/package/@actra-development-oss/ng -i18n-aot-loader

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

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

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

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

ИМХО, правильным решением может быть способ, которым я реализовал POC (см. комментарий выше) для встроенных переводов во время компиляции, просто более элегантным и интегрированным способом.
Обе проблемы, упомянутые выше, будут устранены, единственным недостатком, который я могу себе представить, является, возможно, размер пакета, он вырастет до «простого пакета» + (в переводе html-size * locales).
Это может быть уменьшено только ng-switch ing i18n -tagged html вместо всего документа, но все еще есть проблема для i18n-* -tags.

ну вот в чем дело; иногда у вас есть ограничения ....

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

вам нужен кусок с привязкой к данным? хорошо, но это не внутри интернационализированного текста, это должно быть отдельно. вы по-прежнему можете использовать html и css для стилизации и форматирования результата. но вы не можете вставлять или комбинировать их всеми возможными способами.
например, тег div или ap может иметь несколько диапазонов, один диапазон — это текст, а другой диапазон — это связанная дата, текстовый диапазон привязан к службе локали i18n, дата привязана к какой-либо службе дат, два диапазона находятся в тег абзаца, который их форматирует.

Не усложняйте задачу, сначала сделайте так, чтобы она работала для 95 % всех пользователей, а затем разберитесь с крайними случаями.

Я не считаю это крайним случаем, это обычное дело.
Angular — это фреймворк бизнес-класса, поэтому многим, если не всем, пользователям i18n потребуются привязки или, по крайней мере, множественное число и выборки внутри текстов.

<span i18n>Hello, {user.gender, select, m {Mr.}, f {Ms.}} {{user.name}}</span>
Как бы вы решили это с разделенными строками?
Простой ответ: вы не можете, так как вы не можете знать правила целевого языка, не каждый язык следует формату «приветствие», «пол», «имя».

Разделение этих фрагментов будет:

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

Ядро i18n работает в angular, как и ожидалось, и может использоваться для приложений бизнес-класса, единственное, чего не хватает, по-видимому, — это AOT-совместимости, поэтому я не понимаю вашей точки зрения, почему мощная работающая система должна быть заменена чем-то менее способным требуя многократной работы, чтобы сделать это.

У нас завтра собрание, чтобы найти решение этой проблемы.

@ocombe рад слышать это, я надеюсь, что это приведет к чему-то хорошему для будущего выпуска Angular, здесь, на работе, нам действительно нравится, как большая часть этого работает для наших нужд разработки!

@ocombe , можно ли изменить язык, не перезагружая весь документ? Я объясняю :
Я нахожусь на странице с именем «о нас», но когда я меняю язык, меня перенаправляют на главную страницу входа в мое приложение.

Во время работы над своим i18n-приложением я также столкнулся с известной «ошибкой», заключающейся в том, что внешние таблицы стилей, например, из @angular/material (находящиеся в node_modules), не могут быть разрешены, и поэтому инструмент ng-xi18n не работает.
Я реализовал «игнорировать отсутствующие файлы»-HostContext для инструмента извлечения, также как POC, но добавил как PR # 17845, чтобы связать его с основным репо.

@ocombe , поскольку вы, кажется, очень активны в этой теме, не могли бы вы взглянуть на PR и дать отзыв?

Спасибо, я посмотрю на это.

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

Привет @ocombe! Можем ли мы продолжить обсуждение вопроса, поднятого @jlutz777 (о динамических привязках, поэтому у нас нет одного приложения для каждого языка)?

Большое спасибо за вашу работу!

@vicb работает над этим прямо сейчас, это будет версия 5.x (не 5.0, а скорее всего 5.1)

@ocombe Следует ли обновить контрольный список? Я вижу, что некоторые из них уже объединены в более новых версиях. И это лучше отразит вашу тяжелую работу. 😃

да, хорошая идея, обновлю
редактировать: обновлено

Среда выполнения i18n (один пакет для всех локалей с AOT) - [работает над этим]

Где попутный вопрос/пиар/обсуждение?

Было бы здорово иметь API для расширения именованных форматов даты (например, ultraLongDate ), чтобы собственный канал даты знал об этом, и пользовательский канал даты не требовался бы.

Просто любопытно, как продвигается работа над «Время выполнения i18n (один пакет для всех локалей с AOT)».

У моей команды есть несколько больших приложений с более чем 60 языками. Прямо сейчас мы запускаем N сборок параллельно, так что N — это количество языков. Как вы можете себе представить, это требует больших ресурсов, особенно если учесть, что приложения довольно большие и развертываются много раз в день в разных средах.

На что я надеюсь:

1. Некоторое приблизительное ETA во время выполнения i18n
2. Подтверждение того, что среда выполнения i18n выполнит единую сборку для всех языков.
3. Будет ли каждый созданный язык загружаться лениво или будет в одном массивном пакете

@chcaru , ожидая, пока ng предоставит «родное» решение, загляните на https://github.com/actra-development-oss/ng-i18n-aot-loader/
Он предоставляет именно то, что вы просите, одну сборку AOT с несколькими локалями.

@чкару :
1/ приблизительное время прибытия — Angular v6 (первая бета-версия должна быть к концу января, я полагаю? Не уверен), хорошая новость заключается в том, что переводы кода должны следовать быстро после переводов во время выполнения, поскольку почти вся работа будет выполнена.
2/ да
3/ переводы должны быть отделены от пакета, вы сможете лениво загружать тот, который вам нужен перед начальной загрузкой, или просто объединять все в один, мы также хотим поддерживать ленивую загрузку переводов для модулей, но не уверены, когда это будет быть доступным

@ocombe, пока не будет выпущен angularv6, наиболее серьезным вариантом для динамической загрузки переводов и / или создания многоязычного приложения с одним пакетом является ngx-translate.

Есть ли у вас несколько советов, которые помогут людям, начинающим использовать ngx-translate, легко мигрировать после выхода angularv6?
Какой-нибудь мост между обоими приложениями?

Не совсем, код совсем другой... посмотрим, когда v6 выйдет с этими функциями, если у меня будет мотивация работать над инструментом миграции.

Привет, спасибо за прозрачность предстоящих функций.

Было бы очень полезно знать ответы на следующие вопросы:

1. Есть идеи, насколько новый рабочий процесс i18n будет отличаться от текущего, описанного в https://angular.io/guide/i18n ?

2. Будут ли доступны в шаблонах атрибуты i18n и i18n-*, например i18n-title с необязательным пользовательским идентификатором?

3. Будут ли работать следующие команды?

ng serve --aot --locale fr

ng xi18n  --i18nFormat=xlf
ng xi18n  --i18nFormat=xlf2
ng xi18n  --i18nFormat=xmb

1. как транс-блоки messages.xlf, извлеченные из шаблонов, будут объединены с теми, которые используются в коде?

1. Мы сделаем процесс обновления как можно более плавным, скорее всего, то, что работало раньше, будет работать и после, по крайней мере, до v7.
2. Атрибуты i18n останутся прежними
3. вытяжка должна быть такой же
4. это, вероятно, единственная часть, которая изменится, я пока не знаю, как, поэтому я предпочитаю не говорить вам о том, что может измениться, но сообщения будут объединены во время выполнения, когда будут созданы представления (так что между начальной загрузкой и представлением, появляющимся на экран)

Следуя комментарию @Toub , в этот переходный период нам было бы интересно получить отзывы о следующем подходе (смешение атрибута i18n и ngx-translate), который мы хотим реализовать. Наша цель состоит в том, чтобы свести к минимуму количество обновлений кода, когда новая поддержка i18n будет готова.

(Обратите внимание, что нам нужны динамические локали, то есть не одно сгенерированное приложение для каждой локали)

• Мы будем использовать атрибут i18n , чтобы мы могли использовать инструмент извлечения углов.
• На основе извлеченного инструмента мы можем конвертировать файлы xliff (или других форматов) в содержимое с форматами, которые может использовать ngx-translate (json или po)
• Мы будем использовать атрибут translate для элементов, используя атрибут i18n для применения переводов (ранее извлеченных).

Вот пример:

<!-- Without parameters -->
<div i18n="hello-id" translate>HELLO</div>

<!-- With parameters -->
<div i18n="hello-id" translate [translateParams]="{value: 'world'}">HELLO</div>

Спасибо за ваши отзывы!

Не могли бы вы открыть для этого вопрос на ngx-translate? Я думаю, что лучше всего было бы обновить библиотеку для поддержки атрибутов «i18n» в качестве альтернативы «переводу».

@ocombe спасибо за предложение! Просто добавил проблему для этого на ngx-translate...

@ocombe проблема, которую я вижу, заключается в том, что атрибуты i18n / i18n-* удаляются во время выполнения (https://github.com/angular/angular/issues/11042). Есть ли способ сохранить их?

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

@ocombe Я понимаю, но я не загружаю переводы, так как использую Angular CLI и запускаю приложение с ng serve ...

@ocombe , наша компания вскоре приложит усилия для поддержки i18n, используя предписываемую в настоящее время стратегию нескольких приложений для каждой локали. Мы также планируем включить языковой стандарт в URL-адрес и установить базовый href в приложении. Когда функция i18n среды выполнения будет завершена, какие изменения нам нужно будет внести в нашу стратегию локализации URL-адресов? Есть ли лучший способ начать избегать большого рефакторинга после выпуска среды выполнения i18n? Спасибо за вашу работу над всем этим.

⬆️ должен сказать "скоро начнется"

одно приложение/локаль должно по-прежнему работать, как сейчас (за исключением небольшого изменения для загрузки файла локали при начальной загрузке, если вы не используете cli)

Может ли кто-нибудь указать мне, в каком файле атрибуты i18n удаляются из шаблона во время пакета?

копия @ocombe

Он был изменен в версии 4.2.6 (PR https://github.com/angular/angular/issues/17999).

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

Спасибо за вашу работу!

Это будет в одной из последних бета-версий или, может быть, в RC (знаю, знаю...).
Интерфейс будет похож на goog.getMsg после закрытия, так как это то, что Google использует внутри для перевода кода: https://developer.pubref.org/static/apidoc/global/closure/goog/getMsg.html .
Но мы можем использовать оболочку, поэтому, возможно, она изменит интерфейс для Angular, пока не уверен.
В своем полифилле я использую аналогичный интерфейс, но с возможностью определения id, description и value при необходимости, и я считаю, что это нам так или иначе понадобится (либо через параметры, либо через декоратор)

Спасибо за ваш тяжелый труд! Мы готовимся к полной переработке всего нашего приложения 1.x, начиная с апреля. Что мы можем/должны сделать, чтобы подготовиться к этим изменениям? Прямо сейчас мы планируем использовать 6.x. Спасибо еще раз!

@ocombe Просто любопытно, когда появится «Игнорировать начальные и конечные пробелы»?

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

@ocombe Да, это было бы здорово. Мы тоже очень заинтересованы в среде выполнения i18n, так как это единственная блокирующая точка для нас. Не могли бы вы дать предположение о его завершении в %?

Большое спасибо за ваш труд!

@ocombe

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

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

@ofuangka функция «Игнорировать начальные и конечные пробелы» не является приоритетной.
@Karamuto пока трудно угадать, мы работаем над этим прямо сейчас

@ocombe
Не могли бы вы поделиться своей вехой о Runtime i18n (один пакет для всех локалей с AOT)

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

Также мы хотели бы иметь возможность разбивать файлы xlf (по одному файлу на модуль), возможно ли это?

вверх вверх
будет ли среда выполнения i18n выпущена в Angular 6?

спасибо и удачного кодирования!

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

Релиз версии 7 был бы довольно поздним для нас.

@Карамуто #22654
Я думаю, что это будет релиз в v6, но сначала они должны закончить Ivy.

На этой неделе у нас должен работать привет, мир, но с минимальными функциями (например, без поддержки ICU).
Но поскольку он выпущен с плющом, который находится под флагом, мы продолжим работу над ним и выпустим, как только закончим новую функцию, нет необходимости ждать v7.

@ocombe
Звучит здорово! Это не должно быть полным с ICU с самого начала. Если он будет продвигаться в последних версиях v6, это нас полностью устраивает.

Еще раз спасибо за отличную работу!

@Karamuto см. # 22654 для краткого обзора!

Глупый вопрос: есть ли способ иметь директиву i18n для строковых входных данных для пользовательских компонентов. Пример при пересылке aria-меток:

Я оборачиваю пользовательскую кнопку, которая делает классные вещи:

Шаблон пользовательской кнопки просто делает:

Есть ли способ сделать это уже?

@kekraft Я думаю, что со статическими входными данными вы можете использовать синтаксис атрибута i18n:

<custom-button ariaLabel="your label" i18n-ariaLabel></custom-button>

В компоненте:

<button [attr.aria-label]="ariaLabel">Some button</button>

@ocombe вам нужны участники, чтобы выполнить какую-либо работу i18n во время выполнения?

Да ! v6 опубликовано ~~~
любое обновление здесь?

пример i18n angular 6 здесь
https://github.com/angular/angular/pull/23660

@sandangel вы имели в виду просто «все» или «все, что проверено» из планов в начале этой темы?
Очень ждал единственного приложения, я думаю, что это одна из самых важных вещей. Перешел к # 23660, на который вы ссылались, а затем достиг https://pr23660-e12f469.ngbuilds.io/guide/i18n .
Но там еще написано:

При интернационализации с помощью компилятора AOT необходимо предварительно создать отдельный пакет приложения для каждого языка и обслуживать соответствующий пакет на основе определения языка на стороне сервера или параметров URL-адреса.

Возможно ли иметь одно приложение для нескольких языков или еще нет?

@MrCroft выглядит так, как будто среда выполнения i18n все еще находится в стадии разработки. Я читал, как и вы, еще несколько вариантов, но не один пакет для всех локализаций :(

У нас есть работающий hello world, но он предназначен только для нового рендерера (ivy), а так как ivy не готов к прайм-тайму, вам, к сожалению, придется его дождаться :(

@ocombe , так что, если у нас нет Ivy в производстве (вероятно, около версии 7), у нас не будет переводов во время выполнения. это правильно?

@ocombe общедоступны ли привет, мир и вещи плюща? Было бы здорово попробовать и понять эту новую реализацию i18next😃

@fetis https://github.com/actra-development-oss/ng-i18n-aot-loader/

@fetis да :(
@feloy да, простой привет, мир здесь: https://github.com/angular/angular/tree/master/packages/core/test/bundling/hello_world_i18n , но очень минимальный
вы можете найти тесты здесь: https://github.com/angular/angular/blob/master/packages/compiler/test/render3/r3_view_compiler_i18n_spec.ts
и некоторый рефакторинг + извлечение здесь: https://github.com/angular/angular/pull/22931

@ocombe мы пытаемся внедрить i18n в наше приложение, но где бы я ни читал об этом, я вижу, что нам нужен один файл messages.xlf для каждого языка. Разве это не стало бы накладными расходами для поддержки сложных приложений с различными экранами, обращенными к клиенту, и т. Д. Я хочу посмотреть, сможем ли мы разбить файл сообщений на компонент или модуль? Это уже поддерживается?

@stickler-v этот файл просто переносит ваши строки в ваше программное обеспечение для перевода. не думайте переводить его вручную.

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

Извините, но я немного потерялся. На основе оригинальной документации здесь https://angular.io/guide/i18n. src/app/app.component.html будет содержать только английский текст. messages.fr.xlf — это файл с французским текстом, но он генерируется автоматически, и его не рекомендуется трогать.

Если я хочу, чтобы app.component.html отображался с использованием французского текста вместо английского, где мне указать французские сообщения «Bonjour» и т. д.?

@stickler-v это действительно оффтоп, пожалуйста, создайте вопрос на StackOverflow. С удовольствием отвечу там.

Пожалуйста, не обсуждайте это здесь, это не в тему, спасибо
Что касается вашего вопроса @stickler-v, один файл на модуль/компонент сейчас невозможен, это может быть в будущем, но его нет в списке вещей, над которыми мы сейчас работаем.

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

Извините, если на этот вопрос уже был дан ответ, но возможны ли переводы в JS в этой версии или это все еще только шаблоны?

@ santhony7 Это все еще невозможно, потому что Айви не готова.

Один вопрос, который у меня есть о намерении/функциональности среды выполнения i18n, заключается в том, означает ли это, что мы по существу сможем выбрать язык во время выполнения и «перевернуть» его без перезагрузки приложения, как это было в старой версии ng-translate для AngularJS и в ngx-translate ? Или это означает совсем другое?

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

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

Преимущества среды выполнения i18n:

• определить языковую клиентскую сторону и лениво загрузить нужный файл переводов
• поскольку код не зависит от языка, вы получаете один пакет для всех языков
• библиотеки также могут быть совместимы с "i18n"
• поскольку мы загружаем переводы во время выполнения, у нас есть все, что нам нужно, чтобы предоставить услугу, которая может выполнять переводы и в вашем коде (а не только в шаблонах).
• мы могли бы разделить переводы на модуль (вероятно, сначала они были недоступны)

Недостатки:

• перевод во время выполнения имеет небольшую стоимость, когда переводы извлекаются и преобразуются в узлы html, но, надеюсь, вы не заметите этого, потому что ivy будет намного быстрее, чем текущий рендерер.
• загрузка приложения задерживается на время, необходимое для ленивой загрузки переводов, или ваш пакет немного больше (если вы объединяете переводы)
• мы должны добавить сериализаторы в ваш пакет приложений, чтобы иметь возможность читать переводы, и это много кода (мы, вероятно, могли бы «предварительно скомпилировать» переводы в какой-то json, чтобы избежать этого, мы еще не решили )

Теоретически вы можете изменить язык без перезагрузки всего приложения, но вам придется воссоздать существующие компоненты, потому что шаблоны генерируются при создании компонента, или вы можете привязать службу к своему шаблону (вместо использования i18n атрибуты), и он будет обновляться при смене языка. Можно было бы написать библиотеку, которая работает как ngx-translate, но внутри использует Angular i18n и позволяет менять язык во время выполнения. Для синхронизации шаблонов с языком потребуется больше памяти, как в случае с ngx-translate. Я, вероятно, напишу такую ​​​​библиотеку.

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

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

@ocombe Большое спасибо за разъяснения! Я реализовал текущий Angular i18n в нашем приложении и столкнулся с проблемой из-за изменений/неизвестных требований. Я также использую библиотеку https://github.com/ngx-translate/i18n-polyfill в сочетании, чтобы помочь преодолеть текущий пробел.

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

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

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

Есть ли ETA для Ivy + среда выполнения i18n?
Я прекрасно понимаю, если это не так, но мне нужно знать, могу ли я (учитывая сроки моего текущего проекта) дождаться его или нужно начать использовать одно из текущих решений и отложить миграцию на среду выполнения i18n для будущей версии. .

Я не буду пытаться указать точные сроки, каждый раз, когда я пытался, это было неправильно :D
Это не будет раньше версии 7 (ранее будет доступна в виде бета-версии)

Нет проблем, мы все знаем, что оценки всегда ошибочны. :D
Как вы думаете, будет проще мигрировать с текущего i18n (+i18n-polyfill) на runtime 18n или с ngx-translate?

возможно из текущего i18n, но я напишу версию ngx-translate, использующую внутренности Angular i18n, если это возможно (пока не уверен)

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

Привет. Можно ли изменить локализацию во время выполнения с помощью ngx-translate/i18n-polyfill?

@suchg Не во время выполнения. Вы можете выполнять переводы во время выполнения, но не можете изменить используемую локаль.

@mjschranz спасибо за быстрый ответ
даже переводы во время выполнения сейчас в порядке. можете ли вы поделиться каким-либо примером для того же самого.
Я попробовал пример, размещенный на https://github.com/ngx-translate/i18n-polyfill , и изменил язык браузера Chrome, но не повезло.
есть ли какой-то конкретный метод перевода ??

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

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

Привет, в настоящее время я использую Angular 5, и нам нужно добавить многоязычность в наш проект.
Я добавил решение, которое работает для меня сейчас, и оно почти элегантное. https://github.com/angular/angular/issues/24549.

В идеале я хотел бы лениво загружать языковые файлы на основе службы сниффера страны (на основе поиска карты имени хоста).
Если бы это было возможно в Angular 6, это было бы здорово.

@mattiLeBlanc Как вы разрешаете динамические сообщения, например сообщения от компонентов или служб?

@zverbeta Пожалуйста, извините меня за то, что я не полностью понимаю Angular Core или контекст этого обсуждения. Для начала я могу подойти к этому только из своего контекста.

Отвечая на ваш вопрос, я бы предположил, что нас интересует только ленивая загрузка файлов перевода (xlf) в удобной форме на основе локали, которую можно вывести из URL-адреса или языкового параметра запроса. (В настоящее время я использую карту URL-адресов, чтобы решить, что такое локаль).

Сообщение от компонента или службы не помечается, как мы помечаем разметку с помощью i18n. У меня есть некоторый опыт работы с i18n для Wordpress и PHP. Там мы используем подход __( 'text' to translate, 'text domain' ) для получения правильного перевода. Этот __() также может быть просканирован командой CLI, создающей файл сообщения.

Это одна из проблем, о которых вы говорите?

Одна вещь, которую я заметил, например, с этим блоком разметки (потому что я был ленив и не хотел добавлять i18n к каждому подэлементу):

<div class="eligibility-banner" i18n="@@eligbilityBanner" fxLayout="column" fxLayout.gt-xs="row" fxLayoutAlign.gt-xs="center center" fxLayoutAlign="center start">
        <div class="requirement-text" fxFlex="20">To be eligible, you:</div>

        <div fxLayout="column" fxFlex="80" fxLayout.gt-xs="row" fxLayoutAlign="center start">
          <div fxLayout="row" fxLayoutAlign="center center" class="requirement" fxFlex="33">
              <pro-svg icon="icon-check-circle" className="icon-check" width="44" height="44"></pro-svg>
              <div class="text">own an Australian business (with a valid ABN/ACN)</div>
          </div>
          <div fxLayout="row" fxLayoutAlign="center center" class="requirement" fxFlex="33">
              <pro-svg icon="icon-check-circle" className="icon-check" width="44" height="44"></pro-svg>
              <div class="text">are over 18 years old</div>
          </div>
          <div fxLayout="row" fxLayoutAlign="center center" class="requirement" fxFlex="33">
              <pro-svg icon="icon-check-circle" className="icon-check" width="44" height="44"></pro-svg>
              <div class="text">are an Australian Citizen or Permanent Resident</div>
          </div>
        </div>
      </div>

то есть копирует весь блок div в мой message.xlf.
Это большое загрязнение разметки. (Конечно, я мог бы использовать i18n для каждого тега, содержащего текст.)

Я думаю, что для этого примера использование команды _e() будет работать очень хорошо. Вы бы обернули свой текст командой echo, и весь этот обернутый текст будет собран. Вы можете избавиться от всей этой копии разметки в xml.
Если вам нужно добавить что-то динамическое в эту строку, вы можете передать это с заполнителями в строке (как вы сделали бы с sprintf . Что-то вроде

<p>{{ __( 'I would like a nice %s, please', fruit ) }}</p> 

где fruit — переменная со значением __( 'apple') или __( 'pear) .
Эти 3 фрагмента текста окажутся в XML и могут быть переведены отдельно.

Будет ли от этого какая-то польза? Это очень похоже на добавление атрибута i18n, я понял после повторного чтения :)

Наконец, глядя на пару форматов. XLIFF 2 выглядит довольно красиво, немного чище, чем 1.2. XMB выглядит сбивающей с толку, ужасная документация, которая выглядит так, как будто она была оформлена в 1995 году.
Я заметил, что при использовании XLIFF 2 текст TARGET не отображался, как в версии 1.2.

Ребята, вы смотрели файлы .pot и .mo? Довольно простой формат, который также используется при переводе с помощью инструмента POEdit.

мне нужно преобразовать мое приложение на английском и испанском языках с помощью кнопки переключения. Сделал все изменения, рабочий файл отдельно. Я создал две сборки в .dist/en и dist/es. Может ли кто-нибудь сказать мне, что мне нужно сделать для развертывания и как переключаться между обеими сборками?

Что мне нужно сделать при нажатии кнопки переключения

@shobhit12345, пожалуйста, разместите запрос о помощи на https://stackoverflow.com

@zverbeta решение, которое я разместил в # 24549, не работает, когда я строю с помощью --prod . Это очевидно, поскольку я использую require , который, вероятно, недоступен?
Без флага --prod решение работает, потому что оно включает код, связанный с веб-пакетом?

@mattiLeBlanc Я нашел эту библиотеку https://github.com/ngx-translate/i18n-polyfill , и она решает мою проблему с динамическим текстом.

Привет, как мы можем перевести динамические значения (интерполяция) с помощью i 18 n.

    <source>This amount is for <x id="INTERPOLATION" equiv-text="{{policyName}}"/> policy #<x id="INTERPOLATION_1" equiv-text="{{policyGroupId}}"/></source>
    <target>Esta cantidad es para <x id="INTERPOLATION" equiv-text="{{**policyName**}}"/> política #<x id="INTERPOLATION_1" equiv-text="{{policyGroupId}}"/></target>

Привет! Есть ли место, где мы можем отслеживать и/или помогать с задачами, над которыми работали? (те, у кого есть работающий тег)

Есть ли какие-либо обновления о сроках выпуска бета-версии среды выполнения i18n?

@marcelnem я не могу найти комментарий, но iirc ocombe упомянул, что среда выполнения i18n объединена для ivy, поэтому вы, вероятно, можете протестировать ее на бета-версии v7 с флагом ivy.

Часть времени выполнения выполнена, но не часть компилятора, что означает, что вы еще не можете протестировать ее с помощью ivy.

Привет, я работаю с Angular 6 i18n. Я работаю с несколькими языками, что означает, что я следил за кулинарной книгой:
https://v2.angular.io/docs/ts/latest/cookbook/i18n.html#!

Моя текущая реализация использует AOT, поэтому я создал файлы messages.xlf и messages.pt.xlf. Все работает нормально, когда я запускаю

ng serve --configuration=pt

Я получаю тексты, переведенные так, как ожидалось. Но я чувствую, что что-то очень не так с тем, как это работает. Я, наверное, что-то упускаю. Насколько я понял, каждый раз, когда я добавляю новую строку для перевода и помечаю ее атрибутом i18n, мне нужно повторно генерировать файл messages.xlf с запуском «ng xi18n», а затем вручную обновлять messages.pt.xlf. Файл xlf также содержит номер строки, где находится источник, поэтому похоже, что если я изменю строку, мне также нужно будет повторно сгенерировать файл и вручную обновить мой файл pt.

<context context-type="linenumber">16</context>

Это не выглядит умным, это даст мне много дополнительной работы, чтобы поддерживать его в рабочем состоянии. Вы понимаете мою озабоченность? Я что-то пропустил?
Я знаю, что у Angular 7 i18n будет большое обновление с включенным Ivy, стоит ли мне его ждать?

С уважением,
Фабио

ps Я очень надеюсь, что это не по теме, но если вы чувствуете, что это так, пожалуйста, дайте мне хотя бы направление. Где я должен спросить это, например? Или если есть ссылка, которая может ответить на мои сомнения.

@fabiopcarvalho Я понял одну вещь: разумно использовать пользовательские идентификаторы для каждого отдельного перевода, чтобы упростить отслеживание изменений в макете HTML.

Но да, вам нужно будет регулярно обновлять файл переводов.

@fabiopcarvalho Я использую xliffmerge , чтобы помочь мне с объединением переводов

Отлично, я использовал этот инструмент, и он отлично работал. Я также использую идентификаторы и
они помогают.
Спасибо за ответ !!

В четверг, 30 августа 2018 г., Педро Ромеро с уведомлением на адрес github.com написал:

@fabiopcarvalho https://github.com/fabiopcarvalho Я использую xliffmerge
https://github.com/martinroob/ngx-i18nsupport , чтобы помочь мне со слиянием
переводов

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/angular/angular/issues/16477#issuecomment-417407822 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AWOWQ6vpjOb0Ntgpv7TUngRrBBsUIkVjks5uWCV7gaJpZM4NOSBk
.

Разрешение сообщений ICU в атрибутах имеет решающее значение для доступности, потому что атрибут aria-label часто используется в доступности. Есть ли проблема для последующего наблюдения?

Я не думаю, что для этого есть проблема, не могли бы вы открыть ее? Сейчас я работаю над выражениями ICU для ivy, поэтому я добавил TODO, но запрос функции был бы лучше.

@ocombe , https://github.com/angular/angular/issues/21615

Отличное спасибо (поиск на Github действительно плохой!)!

Сможем ли мы лениво загружать файлы перевода из внешнего источника, например, через HTTP, с новой версией i18n?

@ocombe , как вы сказали, работаете над средой выполнения i18n (один пакет для всех локалей с AOT). уже больше года ждем. когда мы можем ожидать, что эта функция появится в выпуске angular 7?

@ Sef1995 это одна из вещей, которые мы хотим включить
@AhmadShahid потребуется ivy, который будет выпущен независимо от v7, а ivy не будет готов к выпуску v7. Некоторые части ivy уже находятся в версии 6 под пометкой, но это неполная функция, и вы не должны использовать ее в реальных приложениях. У нас пока нет даты выхода Айви.

@ocombe быстрый вопрос, если мы реализуем i18n на сегодняшний день (angular6), для которого потребуются разные сборки (по одной для каждого языка), будут ли потеряны усилия, когда выйдет ivy и среда выполнения i18n? Я имею в виду, что способ реализации i18n сейчас будет отличаться от того, что будет в будущем? Попытка спланировать некоторые спринты заранее и расставить приоритеты в работе. Спасибо

Мы не хотим вносить критические изменения, если можем этого избежать. Идентификаторы извлеченных переводов могут измениться, поскольку мы исправим ошибки, которые у нас были в течение длительного времени, но мы предложим инструмент миграции. Я не могу с уверенностью сказать, что он будет на 100% совместим, но ожидайте, что большинство вещей будет работать одинаково, с новыми опциями, которые можно использовать, если хотите.

@ocombe быстрый вопрос, если мы реализуем i18n на сегодняшний день (angular6), для которого потребуются разные сборки (по одной для каждого языка), будут ли потеряны усилия, когда выйдет ivy и среда выполнения i18n? Я имею в виду, что способ реализации i18n сейчас будет отличаться от того, что будет в будущем? Попытка спланировать некоторые спринты заранее и расставить приоритеты в работе. Спасибо

Привет, вы можете использовать веб-пакет для динамической загрузки файлов (в качестве временного обходного пути) с одной сборкой:
Пример можно найти здесь: https://github.com/angular/angular/issues/24549#issuecomment -402013622.

Вам нужно построить с --prod --aot=false, так как AOT=true удалит материал веб-пакета.

@ocombe Привет,

Вышел релиз-кандидат A7. Как и было обещано, протестируем перевод во время выполнения? Runtime i18n (one bundle for all locales with AOT) . Как я могу проверить это. Пожалуйста помоги

Спасибо

Я поддерживаю вопрос от @sheikalthaf, хотя версия 7 уже выпущена.

@sheikalthaf @Shuyinsama Как объяснялось в нескольких комментариях выше и в первом сообщении:
Для выполнения i18n требуется ivy, который будет выпущен независимо от v7. Некоторые части ivy уже находятся в версии 7 под пометкой, но это неполная функция, и вы не должны использовать ее в реальных приложениях. У нас пока нет даты выхода Айви.

@ocombe : Как насчет передачи динамического ключа i18n от родительского к дочернему компоненту.

Дочерний компонент:
<div i18n="{{labelTextKey}}">{{labelText}}</div>

Родительский компонент:
<app-input [labelText]="'Second name'" [labelTextKey]="'@<strong i="13">@LabelSecondName</strong>'" ..></app-input>

Я могу передать это, но поскольку перевод i18n происходит во время сборки, переменная в этом состоянии все еще пуста. Таким образом, никакого перевода не происходит.

Любое обновление для такого случая?

@bobKasbi

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

<app-input i18n-labelText="@@LabelSecondName" labelText="Second name"></app-input>

@cjsase : отлично работает. Огромное спасибо! Боролся почти 2 дня.

На основании этого: https://github.com/angular/angular/issues/21706#issuecomment -430435254

• Мы не должны ожидать плюща в v7. v8 запланирован на март/апрель 2019 года . Если нам не следует ожидать ivy в версии 7, есть ли рекомендации/консенсус относительно того, что использовать для интернационализации (i18n) до тех пор, пока ivy не будет выпущен в апреле 2019 года?

Это неверная информация. Основная команда никогда не говорила, что IVy будет выпущена в 2019 году. Вместо этого основная команда сказала (выделено мной):

он должен быть выпущен в любой второстепенной версии всякий раз, когда он был протестирован и подтвержден

Скажем, у меня есть приложение angular 7.1.0-beta.0 с включенным плющом. Возможно ли, чтобы у меня была настройка с динамическим изменением языка, выдаваемая спереди без обновления страницы?

если да то как? этот документ: https://github.com/angular/angular/blob/master/aio/content/guide/i18n.md
и этот документ: https://angular.io/guide/i18n

не показывать это?

где я могу узнать, как сделать современное/будущее приложение i18n-angular?

@tatsujb нет, это невозможно, и это невозможно даже с ivy и средой выполнения i18n. Вам придется перезагрузить приложение Angular, если вы хотите изменить язык, пока

хорошо, но документы относятся к химерной версии angular, например 4 минус.

Я не чувствую, что они применимы к моей настройке и не охватывают, как именно вы делаете изменение вступившим в силу.

Я так понимаю, изменение должно быть реализовано бэкэндом.

В моем случае мой angular обслуживается в производственном режиме бэкэндом java-spring. какие большие строки того, что произойдет, когда я нажму значок флага, чтобы изменить язык?

Вы ведете пользователя на www.yourdomain.com/cn/ , где все ваше приложение Angular скомпилировано на китайском языке. В итоге вы получите полностью скомпилированное приложение Angular для каждого языка, который вы хотите поддерживать.

@ocombe @santhony7 как насчет этого: https://github.com/actra-development-oss/ng-i18n-aot-loader ?

могу ли я попробовать это?

он плохо совместим с 7.1.0-beta.0 или прилично совместим?

@ocombe @santhony7 как насчет этого: https://github.com/actra-development-oss/ng-i18n-aot-loader ?

могу ли я попробовать это?

он плохо совместим с 7.1.0-beta.0 или прилично совместим?

Вместо этого я рекомендую использовать ngx-translate. Я использовал оба, и ngx-translate намного проще в обслуживании.

@digismack еще одно различие между ними, которое немного пугает, заключается в том, что ngx-translate отбрасывает все официальные материалы angular-i18n и вообще ничего из них не использует. это целая собственная независимая схема, и файлы json гораздо менее конкретны в отношении источников переводов.

также из двух демонстраций ngx-translate кажется намного медленнее, что вы имеете в виду, когда говорите, что его было легче поддерживать?

@tatsujb как разработчик ng-i18n-aot-loader я знаю, что это довольно сложно реализовать, по крайней мере, интегрировать загрузчики.
Все остальное — кусок пирога, поскольку следует оригинальной угловой парадигме i18n.

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

пытаясь реализовать ngx-translate, мне приходится переходить из одного переводимого места в другое. их сотни, мне немного смешно, что я не могу использовать свои теги i18n, которые я уже запланировал заранее.

Я начинаю думать, что доверять тебе было неправильным выбором, @digismack

@tatsujb За этим выпуском следят 58 человек. Лично я слежу за обновлениями от команды Angular относительно i18n. Я был бы признателен, если бы вы прекратили болтовню, если только она не связана с тем, что говорится в ОП:

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

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

Не в моих привычках писать/комментировать проблему... но я это сделаю!
Учитывая :
@gtbuchanan и CO относятся к типу людей А.
@tatsujb и другие люди, которые жалуются/комментируют/ожидают чего-то, относятся к типу людей B.

Типа А ты не устал повторять всегда одно и то же?!?! Для меня ты раздражаешь больше, чем тип Б.

из-за отсутствия функции i18n в angular Type B люди более разочарованы, чем вы, которые просто «подписываются» на проблему (если это для того, чтобы подружиться, заработать несколько лайков, зайдите на facebook, я не знаю, здесь не место для этого) , слова не поменяешь и ничего не придумаешь, говоря это!...)

Я думаю, что тип A может отказаться от подписки, дождаться обновления, быстро проверить журнал изменений или прочитать блог / новости, убедитесь, что команда angular поместит его большим шрифтом ARIAL 72pixel, чтобы они представили динамический перевод i18n из ts + runtime i18n: большая функция отсутствует в angular! они не придали этому большого значения, поэтому сегодня у нас нет правильного i18n, это стратегия Google или около того, и это не может измениться!

Люди B ждут эту функцию 2 года назад, https://github.com/angular/angular/issues/9104#issue -159302131 да, начиная с angular 2.X!

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

Тип B, пожалуйста, продолжайте жаловаться/комментировать, пока не сможете! это единственный лучший способ понять потребности людей!

Страйк Страйк лол

@tatsujb Все зависит от личных предпочтений. Когда я в последний раз реализовывал ng-i18n-aot-loader , мне пришлось запускать извлеченную сборку и настраивать конфигурацию веб-пакета, чтобы она заработала. Может быть, это уже не так. Однако запуск извлеченной сборки означал, что инструменты Angular CLI больше нельзя было использовать. Итак, в долгосрочной перспективе мне было проще реализовать ngx-translate и смириться с тем, что он работает немного по-другому.

@gtbuchanan Я чувствую вашу боль, но эта «болтовня» напрямую связана с объемом функций, упомянутых в сообщении ОП. Поскольку сроки для Runtime i18n (one bundle for all locales with AOT) продолжают смещаться, люди все еще приходят в эту тему, чтобы найти текущие решения.

@ocombe , сейчас мы собираемся начать новый проект, в котором мы будем получать переводы из базы данных.
Наши модули Angular будут загружаться лениво, и мы также хотели бы оставаться как можно ближе к тому, что Angular предлагает в отношении I18N.

Поскольку поддержка Angular I18N не вошла в последнюю версию, как планировалось, есть ли у вас какие-либо рекомендации для нас и других, которые сейчас собираются создавать новые проекты?

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

С другой стороны, поддержка I18N в Angular еще не готова к использованию в прайм-тайм.

Я действительно был бы признателен за некоторые подсказки, указывающие нам правильное направление о том, что использовать для предстоящего проекта — ngx-translate vs ?

Обязательные к приобретению:

• ленивая загрузка

Приятно иметь:

• выражения интенсивной терапии

Мерси

Для подписчиков этого выпуска @ocombe расскажет о времени выполнения i18n на angularconnect через пару часов. Я предполагаю, что там будут даны ответы по крайней мере на некоторые открытые вопросы. есть прямая трансляция

@ctaepper - большое спасибо за информацию!

@guygit это может быть ngx-translate или angular-l10n . вот таблица сравнения, созданная мной https://medium.com/@sergeyfetiskin/tools -to-translate-your-angular-app-c021e25ff26a

для наших приложений мы решили пойти по пути Angular, даже если у него есть некоторые ограничения.

@fetis Большое спасибо - посмотрю :-)

Интересует выбор файлов XLIFF для файлов перевода — Google Translate Toolkit, а также Flutter/Dart i18n поддерживают файлы ARB и не поддерживают XLIFF. Я слышал, что поддержка файлов ARB не планируется, но мне интересно, можно ли это рассмотреть снова. Или, если кто-то ( @ocombe ?) может указать, где Angular взаимодействует с файлами XLIFF, чтобы я мог посмотреть, насколько сложно будет интегрировать поддержку ARB.

(Для некоторого контекста мы собираемся использовать Flutter/Dart для наших мобильных приложений и Angular для нашего веб-приложения, и мы действительно хотели бы поделиться нашими файлами перевода как между мобильными устройствами, так и в Интернете, если это вообще возможно. Я рассматриваю возможность написания Преобразователь ARB -> XLIFF, если нет желания рассмотреть его включение в Angular.)

@localpcguy , если вы в конечном итоге напишете что-то вроде конвертера, вам может быть интересно внести свой вклад в https://github.com/translate/translate , который уже предлагает преобразование из/в множество форматов.

Кстати, несколько месяцев назад ocombe сказал, что он приложит все усилия для поддержки PO-файлов (и JSON?). Будем надеяться, что когда-нибудь это произойдет, потому что нам было трудно найти нестандартные инструменты для работы с XLIFF.

потому что нам было трудно найти нестандартные инструменты для работы с XLIFF.

@PowerKiKi это просто неправда. Практически любой онлайн-инструмент для управления переводами поддерживает формат XLIFF. И есть даже бесплатные настольные программы перевода, если вы не хотите редактировать .xliff вручную.

@fetis Ненавижу отходить от темы, но обнаружил довольно много проблем с использованием XLIFF с инструментами. Смотрите мой комментарий здесь: https://github.com/angular/angular/issues/20193#issuecomment -345755889

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

Кажется, вы знаете что-то, чего не знаем мы :)

Pootle использует https://github.com/translate/translate и отлично справляется с Gettext (po-файлы), но он не поддерживает заполнители/теги, и они ждут от кого-то вклада, чтобы добавить его.

Я был подписан на этот вопрос в течение долгого года или около того. Кажется, что прогресс в этом отношении не является приоритетом для команды Angular, и необходимость компилировать приложение один раз для каждого языка и выполнять динамические переводы неприемлема. Я рекомендую, если вы можете это сделать, создать собственный канал, который использует любую другую библиотеку i18n, которая вам нравится. Будучи чистым, этот канал будет одинаково эффективен для многократной компиляции приложения. Кроме того, используя i18n, который не зависит от Angular, вы сможете тривиально выполнять динамические переводы из кода. Еще одним преимуществом является то, что ваши переводы больше не будут зависеть от Angular, поэтому вы можете начать перенос некоторых компонентов на другие фреймворки, если хотите, или даже можете выбрать формат перевода и инструменты, которые вы предпочитаете, с полной свободой. Я использую https://airbnb.io/polyglot.js/ и очень доволен этим, и даже когда миграция моего приложения с Angular i18n на полиглот все еще продолжается, я не могу быть более доволен результатом и удалением зависимости с Angular i18n.

Извините тех, кто получит это как уведомление на вашу почту и не заботится о моем мнении, но, поскольку я так долго читал ваши уведомления, я чувствую, что должен попрощаться, прежде чем отписаться :)

Ваше здоровье!

Кажется, что прогресс в этом отношении не является приоритетом для команды Angular, и необходимость компилировать приложение один раз для каждого языка и выполнять динамические переводы неприемлема.

Время выполнения i18n является большим приоритетом для команды Angular. Однако проблема блокировки связана с новым средством визуализации Ivy. Пока проект идет хорошо, и мы, вероятно, можем ожидать Ivy для Angular 8. Я понимаю, что это сложная ситуация для всех участников. Планы есть, но они не могут быть реализованы, пока Айви не закончена.

Пожалуйста, ознакомьтесь с докладами на недавней конференции AngularConnect (2018 г.) в Лондоне, особенно с докладом «Runtime i18n» Оливье Комба и основным докладом второго дня Алекса Рикабо.

Действительно, мой опыт похож на @intellix.

XLIFF 1.2 уже 10 лет , но поддержка его в проектах с открытым исходным кодом кажется довольно плохой. Pootle не поддерживает держателей мест в соответствии с https://github.com/translate/pootle/issues/4762 и https://github.com/translate/pootle/issues/1811. Weblate также не поддерживает их , хотя PR может добавить поддержку в ближайшее время.

На рабочем столе Virtaal _поддерживает_ заполнители XLIFF, но последней версии 0.7.1 уже 6 лет, и, насколько я слышал, она больше не работает на последней версии macOS. К сожалению, это не производит впечатление хорошо поддерживаемого проекта, с несколькими очень старыми PR , которые все еще ждут объединения, несмотря на их кажущуюся простоту. И очень низкая активность коммитов за последние несколько лет .

Я только что узнал, что Poedit 2.2, выпущенный несколько дней назад, поддерживает XLIFF 1.2 и 2.0. К сожалению, я не могу проверить это, так как в данный момент при установке получаю сообщение об ошибке от snapcraft.io CDN. Но это может быть лучшим решением для пользователей настольных компьютеров.

@fetis , если вы нашли несколько проектов с открытым исходным кодом (или, по крайней мере, бесплатных для использования) для редактирования XLIFF 1.2 или, что еще лучше, XLIFF 2.0 с поддержкой заполнителей, пожалуйста, перечислите их здесь. Все остальное, что я тестировал, либо вообще не работало, либо ужасно сложно в использовании.

@intellix @PowerKiKi вот список того, что я знаю. Наша цель — платформа онлайн-переводов, где мы можем сотрудничать с переводчиками/коллегами из разных стран. Проходить процесс установки настольного программного обеспечения для каждого соавтора и управлять синхронизацией файлов XLIFF — это не наш выбор. Итак, я не тестировал настольные инструменты, я тестировал платформы.

Приложения
ОмегаТ
https://омегат.org/

Собственный хостинг
https://weblate.org/en/ +платный хостинг
https://pootle.translatehouse.org/
https://pontoon.mozilla.org/

Платформы
Краудин
https://crowdin.com/
поддержка интерфейса командной строки

WebTranslateIt
https://webtranslateit.com/
поддержка интерфейса командной строки

Трансифекс
https://www.transifex.com/

PhraseApp
https://phraseapp.com/

локализовать
https://localise.co/
поддержка интерфейса командной строки

_Думаю, мы закончим с Lokalise для наших проектов, так как он обеспечивает достаточную функциональность по доступной цене._

~POEditor~
https://poeditor.com/pricing/
Заявленная поддержка XLIFF не работает с форматом Angular.

Если вы ищете решение с открытым исходным кодом, этот список может быть мне полезен https://opensource.com/article/17/6/open-source-localization-tools .

Боковые узлы
Я не видел онлайн-платформы, поддерживающей XLIFF 2.0, и это стало для меня большим сюрпризом. XLIFF 1.2 официально помечен как устаревший, и никто в отрасли не поддерживал v2.

Рад слышать, что POEdit объявил о поддержке XLIFF, я использовал его для файлов .po, и это было приятно.

PS Мне очень жаль создавать здесь оффтоп, но в то же время получение XLIFF-файла из вашего приложения — это только часть пути, вам нужно перевести и поддерживать его на протяжении всего жизненного цикла вашего приложения. Так что это важное обсуждение. Я бы предложил переехать куда-нибудь, я могу разместить этот список как статью на Medium, и мы можем продолжить обсуждение там.

@localpcguy существует множество форматов, но все зависит от того, сколько из них мы можем поддерживать. Написание и поддержка сериализатора требует времени. Xliff 2 был добавлен в качестве PR кем-то другим, поэтому мы добавили поддержку (иначе мы бы не потратили время на ее поддержку).
Нам нужен сериализатор для двух вещей: извлечения и слияния.
Я не говорил об этом в Angular Connect, но я надеюсь, что мы сможем использовать внешний сериализатор. Это должно быть очень легко сделать во время выполнения (слияние) с ivy, но извлечение по-прежнему сложно, потому что сериализатор необходимо обновлять, когда мы вносим изменения в компилятор.
У меня есть несколько идей, как это сделать, но мне нужно будет поговорить об этом с командой, как только Айви приземлится. Что бы я действительно хотел сделать, так это по крайней мере добавить поддержку JSON, чтобы я мог переписать ngx-translate с помощью Angular i18n (и потому, что этого хотят многие люди).

Спасибо @ocombe (и всем остальным, мне нравится видеть разные взгляды). Похоже, что #14185 был упомянутым вами PR, это все еще хорошая отправная точка, если я хочу посмотреть на добавление поддержки ARB? Это что-то, что потенциально может быть объединено, если оно отправлено?

@localpcguy у нас завтра встреча, на которой мы обсудим это (и другие вещи), я дам вам знать, как все пройдет

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

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

Ну это было бы круто :+1:

да, у вас не будет доступа к глубокой оптимизации (замените строки во время сборки, чтобы создать один пакет для каждого языка, что означает, что переводы будут разделены кодом с вашими компонентами), но вы можете использовать любое решение для ленивой загрузки, которое вы хотите, пока вы загружаете все переводы при запуске приложения (они должны быть загружены синхронно до создания компонента)
вы также можете в конечном итоге кодировать их вручную и загружать их с маршрутизатором асинхронно при загрузке нового компонента, это будет зависеть от вас, используя новые функции ленивой загрузки, которые предоставляет ivy (Джейсон сделал демонстрацию этого в Angular Connect)

можем ли мы ожидать бета-демонстрацию (не файлы, а только видео или прямую трансляцию) переключения языка на лету на Ivy? Попытка составить предфинальный плющ POC может быть отличным способом обнаружить заграждения на линии.

не то чтобы я не согласен с подходом ожидания более укоренившегося каменного плюща, прежде чем вкладывать пот разработчика в live-i18n, я думаю, что небольшой POC с одним человеком — это небольшое количество пота для огромной отдачи в виде дальновидность и потенциально может избежать переноса live-i18n на 2020 год.

Служба времени выполнения для внешних пользователей еще не готова, у нас есть только код, который использует замыкание ( goog.getMsg ), потому что это то, что нам нужно для тестирования ivy с приложениями Google.
Я буду работать над этим в ближайшие месяцы. Это означает, что вы, вероятно, еще не можете использовать i18n с ivy.
Код для среды выполнения i18n был слит только вчера, а код компилятора для i18n должен быть слит в ближайшие несколько дней (мы к этому приближаемся!). Затем мы будем работать над новым сервисом для внешних людей, включая новые загрузчики, о которых я говорил чуть выше, и сервис для использования переводов в вашем коде.

Что касается переключения языка на лету, то все равно потребуется полная перезагрузка приложения или, возможно, изменение маршрута (что очистит все существующие компоненты). Я бы пока не пробовал работать над POC.

Что касается переключения языка на лету, то все равно потребуется полная перезагрузка приложения или, возможно, изменение маршрута (что очистит все существующие компоненты). Я бы пока не пробовал работать над POC.

это справедливо, ... однако не требует полной перезагрузки приложения (или чего-либо, что обеспечивает бесшовность в глазах конечного пользователя, AKA не теряет ни магазин, ни аутентификацию, ни URL-адрес (ну... не учитывая /en/... ) и все с разумной задержкой) ....это все же план, да?

@tatsujb Перезагрузка приложения не перезагружает страницу, StackBlitz перезагружает приложение при каждом редактировании, вы чувствуете, что это заметно для ваших глаз?

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

так что с этой правильной настройкой; сохранить значения переменных и аутентификацию (а также количество прокрутки на прокручиваемых элементах div) останутся?

@tatsujb Пока они хранятся вне экземпляра, созданного Angular, например, в лексической переменной или свойстве окна.

@trotyl Как перезагрузить приложение без страницы?

@saithis Вы всегда принудительно загружаете приложение с помощью platformBootstrap().bootstrapModuleFactory() (или другого эквивалента), вы можете вызывать его в любое время в любом месте, в вызове нет никакой магии (за исключением того, что в настоящее время Angular CLI имеет некоторые ограничения для замены кода, больше не должно быть проблема в Айви).

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

РЕДАКТИРОВАТЬ: в случае, если кто-то это сделает, также необходимо уничтожить загрузочный NgModuleRef , чтобы предотвратить утечку памяти. Это вопросы не по теме, и их лучше обсудить на другом канале, лучше следить за обсуждением i18n здесь.

@trotyl Спасибо, я не знал, что начальная загрузка снова работает.

@ocombe не могли бы вы удалить спам здесь? и мой комментарий в том числе.

1. to @fetis : такие люди, как вы, должны отписаться от выпуска и подписаться на выпуск
   

2. @Andrulko : нам все равно

3. to @ angular : как я уже сказал, я прекрасно понимаю, что здесь жалуются! например, мы хотели ivy для v7, а не для vX, или не продавайте большое улучшение для v7, пока вы не можете за него ответить, или вы добавите его в 7.x, просто чтобы уложиться в срок... это несправедливо! да вариант должен быть ничего не анонсировать и никто не будет жаловаться это тоже плохая идея, вам нужно найти свое место в фреймворке. да, мы ждем правильного i18n, начиная с v2, в этом обязательном аспекте для большого приложения вы не можете продавать угловой готовый для большого приложения, такого как международное веб-приложение, которое содержит 50000 строк, конечно, вам, конечно, не нравится читать это, но это без сострадания и с хорошим вера, имхо, если мы не рассматриваем i18n и медленное время сборки/разработки для всех остальных аспектов, я могу сказать, что angular — это круто. определенное направление должно измениться наверху, я, конечно, обращаюсь к лицам, принимающим решения. Большое исключение для нас (которых критикуют), потому что из большого Google мы не могли совершить такую ​​​​большую ошибку. я вижу, что разработчикам Google нравятся исключительные люди - безошибочно умные люди, этого не должно происходить с опытными разработчиками и с командой разработчиков, такой как Google! мое глобальное мнение: не продавайте angular 100% для большого приложения, когда компания выбирает его, а затем продает/объясняет частной компании, что такое открытый исходный код!

4. @ все специально для тех, кто не работает в коммерческой компании: мне не нравится мой комментарий, потому что я, конечно, не уважаю открытый исходный код?!?!, лол, иди, скажи это моему боссу, чтобы он подождал... подождал... после выбора angular, потому что мы верим он готов (100%, а не 80%) для большого приложения... мы зависим!

это мой последний комментарий здесь, потому что мы покидаем корабль! отписаться + не выбирать angular в моем следующем проекте (можно сказать, что вы победитель, проекту с открытым исходным кодом не нужны такие люди, как мы)

Такая страсть! Просто для баланса... мы переписали наше приложение на Angular 6, интернационализировали на 6 языках и почувствовали лишь незначительные неудобства. Конечно, более быстрое время сборки и переводы на лету, безусловно, были бы хороши, но не конец света для нас. 98% фреймворка, который не является i18n, — это круто. Отличная работа, ребята! Ждем новых функций.

У нас также есть фантастический опыт работы с Angular для нашего нового корпоративного портала. i18n — это последняя недостающая функция, которая нам нужна, поскольку в Швейцарии мы должны поддерживать четыре языка. Я думаю, что проблема здесь с коммуникацией. Что касается планирования проекта, если бы год назад у нас была лучшая оценка выпуска i18, мы могли бы запланировать его и рассмотреть другие возможности. Тем не менее, мы с нетерпением ждем любых обновлений. :-)

В защиту angular вы можете достаточно просто использовать его в производстве, как это (лучшее решение, которое я нашел)

1. Оберните переведенный переменный текст в собственный компонент, чтобы переместить куда-нибудь логику перевода

parent-component.component.html

<app-route-translation
  [routeData]="routeData"
></app-route-translation>

route-translation.component.html

<span
  i18n="route text|Navigation text for route@@routeText"
>{
  routeData.langKey, select,

  home-1 {Home 1}
  home-1-1 {Home 1-1}
  home-1-2 {Home 1-2}
  home-2 {Home 2}
  home-2-1 {Home 2-1}
  home-2-2 {Home 2-2}
  home-root {Home root}
  lazyPage {Lazy page}
  notFound {404}

  other {Other}
}</span>

1. Настройте папки конфигурации сборки в angular.json, например

"prod-en": {
  ...
   "outputPath": "dist/en/",
  ...
},
"prod-ru": {
  ...
   "outputPath": "dist/ru/",
  ...
}

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

FROM node:8 as build-stage
WORKDIR /app
COPY angular-util .
RUN npm install
RUN npm run ng build -- --configuration=prod-en
RUN npm run ng build -- --configuration=prod-ru

FROM nginx
WORKDIR /usr/share/nginx/html
COPY --from=build-stage /app/dist .
COPY nginx.conf /etc/nginx/conf.d/default.conf

1. Используйте этот nginx.conf для обслуживания приложения на поддоменах (например, en.site-name.com, ru.site-name.com), где ru в set $subdomain ru; следует заменить на локаль по умолчанию.

server {
  listen 80;
  set $subdomain ru;
  if ($host ~ ^(\w+)\.) {
    set $subdomain $1;
  }
  location / {
    root /usr/share/nginx/html/$subdomain;
    try_files $uri $uri/ /index.html =404;
  }
}

Подробнее см. здесь
https://github.com/ivanivanyuk1993/angular-util/tree/master/src/app/util/shared/route-list
https://github.com/ivanivanyuk1993/titans-shoulders-project/tree/master/container-description/ui-container-description

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

Всем привет,

Я использую переводы i18n для своего проекта. У меня есть сомнения в следующем:

1. Можно ли создавать разные исходные файлы xlf для разных библиотек (созданные с помощью команды ng generate library libraryName)?
2. При использовании интернационализации для выбора или множественного числа сгенерированный исходный файл xlf создает идентификатор трансмодуля для различных альтернатив. Можно ли также предоставить идентификатор через шаблон для различных альтернатив? (как показано на рисунке ниже)
   

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

@learnersLicense :

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

1. Я не думаю, что это возможно. Вы можете называть заполнители со специальными комментариями: <div i18n>Some value: {{ valueA // i18n(ph="PH_A") }}</div> , но я не думаю, что это работает с выражениями ICU, @AndrewKushnir ?
   Вы можете сделать запрос функции для этого или, возможно, добавить комментарий к https://github.com/angular/angular/issues/24080 , который кажется похожим (добавить desc/значение к выражениям ICU)

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

Один из способов обойти это:
1) извлеките библиотеку i18n в xliff и переведите
2) отправить файлы xliff с пакетом библиотеки

3) потребитель также извлекает свои собственные файлы xliff
4) потребитель загружает xliff в парсер xml. отбрасывает любые трансмодули, происходящие из node_modules
5) потребитель объединяет xliff с библиотекой xliff

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

Возможно, я неправильно понимаю это утверждение, но я знаю, что при настройке переводов для приложений моей компании, когда я создаю свои файлы xlf , они включают ключи, указанные в шаблонах других проектов. На ум приходит https://github.com/ng-bootstrap/ng-bootstrap.

На данный момент это не представляется возможным:

<my-button i18n-title="@@SHARED_GO_LABEL" [title]="'Go'" [button-style]="'primary'" (click)="navigateToForm()"></my-button>

В рамках этих изменений это будет исправлено (или я что-то не так делаю)?

@mikejr83

Это возможно. Вам просто нужно присвоить базовое значение title как title="Go" , а не [title]="'Go'"

спасибо @ocombe и @ewok-janitor за ваши ответы и предложения. 👍

@ocombe есть ли ориентировочная дата, когда могут быть доступны переводы для библиотеки?

Нет даты пока. Для первого выпуска ivy мы просто пытаемся добиться паритета функций. Мы будем работать над новыми функциями (включая переводы кода и поддержку библиотек) сразу после (или на самом деле мы начнем работать над этим раньше, но это не будет завершено, когда ivy будет выпущен в альфа-версии). Он будет доступен до того, как ivy станет стандартным.

Есть ли уже исправление для файлов xliff? https://github.com/angular/angular/issues/17506
Использовать формат вообще невозможно, пока ссылки не исправлены.

@ocombe Есть ли планы по поддержке перевода маршрутов?

это запрашивалось несколько раз да, это не ближайший план, но это в списке того, что нужно сделать

Привет, есть ли какая-нибудь документация по использованию среды выполнения i18n, когда плющ выпущен в бета-версии?

@marcelnem , если вы проверите этот URL, все пункты документации ожидают рассмотрения.

https://is-angular-ivy-ready.firebaseapp.com/#/статус

@ocombe отличная работа, которую вы сейчас делаете в Google. Angular i18n с самого начала должен был быть чем-то вроде ngx-translate. Мне было интересно, будет ли руководство по миграции, автоматизированный инструмент, сравнение функций... для перехода с ngx-translate на стиль Angular i18n после выпуска Angular 8/9?

привет окомб
Необходимо проконсультироваться с вами относительно этой функции, той, которую вы указали выше.
Среда выполнения i18n (один пакет для всех локалей с AOT) - [работает над этим] >> Это все еще в процессе или уже нет

Не могли бы вы сообщить мне, какие-либо обходные пути, если они все еще находятся в стадии разработки?
Спасибо

@ocombe , вы писали выше, что языковые пакеты должны загружаться кружевной загрузкой. Будет ли также возможно загружать языковые пакеты непосредственно в index.html? Потому что у нас есть случай, когда наше приложение работает на AWS Lambda, а скомпилированные файлы angular хранятся в корзине S3. На самом деле это уже обходной путь, который вообще работает, но мы не можем использовать кружевную загрузку, потому что Angular не может загружать файлы с другого хоста. Поэтому все файлы, которые нужны Angular, уже должны быть включены в index.html (куда мы добавляем хост S3 через скрипт).

@ nidhi8953 это все еще WIP, он будет доступен с ivy, пока он работает только внутри Google (потому что мы используем Closure Compiler для внутренних переводов). Служба времени выполнения, которая будет обрабатывать переводы, во многом является экспериментальной для внешнего мира. Если вы хотите проверить несколько вещей, вы можете посмотреть этот пример: https://github.com/angular/angular/blob/master/packages/core/test/bundling/hello_world_i18n/index.ts , но вы должны знать, что функции все еще закрыты по какой-то причине, они будут переименованы и изменены в самом ближайшем будущем. Текущая цель состоит в том, чтобы начать работу над солидным набором API-интерфейсов после выхода версии 8 (в конце месяца) и повторять это для всей версии 8 до тех пор, пока не выйдет версия 9, после чего API следует считать стабильным.

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

@ocombe Можем ли мы использовать Ivy (в настоящее время 8.0.0-rc.3) и реализовать i18n, используя метод множественных сборок Angular 7? Или мне нужно придерживаться Angular 7, пока не будут выпущены API-интерфейсы i18n для Ivy? Если возможно, я бы очень хотел воспользоваться преимуществами Ivy, в то же время используя старый способ i18n, пока не будет доступен новый метод времени выполнения.

Обновление: после того, как вы попробовали это, ни извлечение ng xi18n (см. #https://github.com/angular/angular-cli/issues/14225), ни сборка с i18n не имеют никакого эффекта. Файл .xlf не экспортируется и слова не переводятся. Но с параметром enableIvy, установленным в false в tsconfig.app.json, оба прекрасно работают с версией 8.0.0-rc.3. Это означает, что я могу следовать пути обновления Angular, не потерять i18n, получить некоторые новые преимущества, такие как дифференциальная загрузка, и быть готовым включить Ivy, как только i18n заработает.

@jacobbowdoin , как вы узнали, не работает с включенным плющом, но работает, если он не активирован.
Я хотел, чтобы старая система извлечения/загрузки работала с ivy, но, поскольку это было бы просто временным, команда не определила это как приоритет (что понятно, приоритетом является заставить работать обязательные вещи в первую очередь).

Привет, @ocombe , мы хотим разработать i18n сейчас, поэтому мы не можем ждать runtime-i18n. Вы все еще рекомендуете использовать ngx-translate? Есть ли смысл использовать его с i18n-polyfill? Упростит ли использование i18n-polyfill переход на runtime-i18n?

Если вы используете ngx-translate, не используйте i18n-polyfill. Его имеет смысл использовать только в том случае, если вы используете angular i18n для шаблонов.
ngx-translate по-прежнему актуален и прост в использовании. Вам не нужно создавать всю инфраструктуру для поддержки нескольких сборок (по одной на каждый регион).

Привет @ocombe , есть ли какое-либо обновление статуса:

-Время выполнения i18n
-Использовать строки перевода вне шаблона - #11405

В настоящее время мы обсуждаем, стоит ли нам ждать переводов исходного кода или использовать i18n-polyfill (мы уже начали с i18n). Мы можем легко подождать несколько недель, поэтому были бы признательны за приблизительные сроки. Большое спасибо!

@halilovicedvin , как только ivy будет использоваться по умолчанию в приложениях Google, мы начнем работать над сервисом i18n времени выполнения для внешних пользователей, так что где-то между скоро и v9
Я бы не рассчитывал на это до конца лета, потому что люди возьмут несколько выходных.

@halilovicedvin мы начали с i18n с i18n-polyfill несколько недель назад, и он отлично работает. Я надеюсь, что runtime-i18n будет использоваться так же, как и i18n-polyfill.

@vekunz Я тоже надеялся, что если мы будем использовать ngx-translate с i18n-polyfill , мы сможем легче перейти на runtime-i18n, но после комментария @ocombe (https://github.com/angular/angular/issues /16477#issuecomment-498239301) Я не уверен, что дополнительные усилия по настройке полифилла оправданы. Может быть, мы просто будем использовать только ngx-translate.

@vekunz каков ваш опыт в настройке?

@marcelnem вы не можете использовать ngx-translate с i18n-polyfill. i18n-polyfill предназначен только для использования с angular-i18n.

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

@vekunz Теперь я понимаю, спасибо. Я не уверен, какова цель i18n-polyfill. Вам все еще нужно создавать приложение несколько раз и развертывать его несколько раз в http://myapp/en , http://myapp/de , http://myapp/fr ,... как с официальным angular i18n?

@marcelnem да, вам также нужно несколько сборок с i18n-polyfill. Цель состоит в том, что с angular-i18n вы можете использовать переводы в настоящее время только внутри html-шаблонов, а не внутри вашего машинописного кода. i18n-polyfill расширяет angular-i18n, чтобы использовать переводы и внутри вашего машинописного кода.
С выходом Angular 9 (осенью) angular-i18n также будет поддерживать переводы внутри машинописного текста, но пока для этого нам нужен i18n-polyfill.

@vekunz , не могли бы вы рассказать об этом подробнее: «Даже документация не совсем верна, я очень быстро понял, что нужно изменить». Я, вероятно, посмотрю на i18n-polyfill на следующей неделе, поэтому любая информация будет оценена. Спасибо

@halilovicedvin @marcelnem Я создал документ pastebin, в котором описываю его, потому что это не основная тема этого выпуска GitHub https://pastebin.com/Xib6X6E9

@ocombe Используя инструмент xi18n, могу ли я ограничить входной путь только папкой src (для создания переводов), а не всем проектом/репозиторием?

@ocombe поддерживает ли Ivy несколько локалей с Angular 8 (только определение локали, а не языковой файл; например, для каналов даты)? Потому что другая команда в настоящее время использует Angular с ngx-translate, но одному стороннему компоненту нужна правильная локаль. Одним из вариантов было бы использование JIT-компилятора в режиме prod, но это не очень приятно. Но также они не могут скомпилировать новый пакет для каждого языка, потому что это было бы слишком много.

@vekunz нет, вы не можете установить несколько локалей, вам нужно установить локаль для каждого скомпилированного пакета (его можно установить в файле конфигурации cli)
Я знаю, это не то, что ты хотел услышать, но пока так.

@ocombe Можете ли вы сказать что-нибудь, я знаю, что команда Angular не считает это проблемой, но как вы думаете, Angular позволит нам в обозримом будущем изменить язык во время выполнения без перезагрузки приложения, поэтому имея перевод в один пакет и иметь возможность загружать правильные переводы и связывать их с текстовыми литералами?

Наличие одного пакета — да, но переводы должны быть загружены в boostrap (когда загружается приложение). С существующей архитектурой было бы очень сложно «горячо» перезагрузить переводы без перезагрузки компонентов, которые уже используют переводы.
Я не говорю, что это невозможно, но, к сожалению, не вижу этого в обозримом будущем.

Спасибо @ocombe за быстрый ответ :) Продолжайте в том же духе :+1:

Где-то была презентация @ocombe с какой-то конференции angular (думаю AngularConnect), где он рассказывал про i18n и Ivy, и там очень хорошо описал, почему это так сложно. Могу попробовать найти видео.

Кажется, я нашел это https://www.youtube.com/watch?v=miG-ghJhFPc

Для людей, ожидающих выполнения i18n с ivy, текущий план для v9 состоит в том, чтобы переводы работали с ivy, но только как шаг сборки (как сейчас с механизмом просмотра). Это означает, что на данный момент все еще будет 1 сборка/локаль, и не будет переводов кода (только переводы шаблонов).

облом. Что ж, для чего это стоит, спасибо за ваш труд!

@ocombe , вы по-прежнему будете поддерживать полифилл для переводов кода во время выполнения?

если он сломается, да, я не буду добавлять в него что-то новое.

Это немного отстойно, что i18n так долго был гражданином 2-го сорта... Не все работают в родной англоязычной среде. ):

Ну, я согласен, я пытаюсь найти несколько компаний, которые спонсируют меня, чтобы я мог разрабатывать новые мощные решения i18n для Angular (у меня есть масса идей).
Если вы думаете о людях, которым это может быть интересно, дайте мне знать в Твиттере (@ocombe) или по электронной почте ([email protected]) 🙂

@ocombe Я также хотел бы поблагодарить вас за вашу работу. 💚 Немного неожиданная новость, что ты вынужден покинуть команду. Как вы сказали I had to ... , это побуждает меня прямо спросить вас, что было основной причиной. Терпеть не могу эти косвенные намеки и догадки, поэтому такой прямой вопрос к вам.

Я был внешним подрядчиком, работающим с командой Angular, а не штатным сотрудником Google, и поэтому мой контракт может закончиться в любой момент в зависимости от того, что нужно команде.
Они набирают новых людей внутри, чтобы помочь с проектом, и я уверен, что они найдут подходящих людей, которые помогут с i18n и другими темами, поэтому вам не нужно беспокоиться о будущем Angular :visage_légèrement_souriant: это просто временная неудача

@ocombe Спасибо за объяснение.

Может ли кто-нибудь сказать мне, как я могу использовать i18n (i18n-polyfill) вне класса, например перечисления или массивы const или что-то вроде файлов .model.ts?

Что касается констант, я все же помещаю их в класс. Я не знаю альтернативы :/

@ocombe Большое спасибо за всю вашу тяжелую работу с i18n для Angular с ngx-translate, i18npolyfill и с командой Angular.
Мы ежедневно используем вашу работу для предоставления переводов нашим пользователям, как того требует любое нетривиальное приложение.
Желаю удачи в том, что вы делаете, продвигаясь вперед.

Что касается констант, я все же помещаю их в класс. Я не знаю альтернативы :/

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

экспорт класса Пример {
конструктор (частный i18n: I18n) {}
статическая переменная = i18n('текст'); // Я не могу использовать i18n здесь, так как это не статический класс Пример
}

Печальные новости... это "ослабляет" Angular... Как и говорят другие, остается только большое спасибо @ocombe за отличную работу, удачи!

Мне любопытно, каковы недостатки использования ngx-translate? Кажется, он способен именно на ту функциональность, которую ищут люди.

Я бы сказал, что недостатки следующие:

• увеличивает размер пакета (внешняя библиотека + переводы в виде внешних файлов вместо замены кода во время сборки)
• не официальный (если я умру, то библиотека будет прекращена, а уровень поддержки не тот)
• не поддерживает xliff/xmb (но поддерживает json и другие форматы через плагины, и для его поддержки можно сделать плагин xliff/xmb)
• могут быть некоторые ошибки при ленивой загрузке/разделении переводов (мне так и не удалось это исправить)
• синтаксис более сложен по сравнению с официальной реализацией
• производительность (первоначальная загрузка переводов может привести к исчезновению текста на 1 секунду и большему потреблению памяти, потому что мне нужно отслеживать содержимое во время выполнения, чтобы увидеть, изменилось ли что-то)

При этом, кажется, что это достаточно хорошо для многих людей 🙂

Любопытно, как angular продвигает и инвестирует в доступность, но не включает языки в этот пакет. Действительно чувствуется, что это решение принято в одноязычной среде.

Исходя из среды, в которой нам обычно приходится взаимозаменяемо обслуживать 3-4 языка, я терпеливо ждал выпуска этой функции с момента ее объявления с ее явными преимуществами по сравнению с использованием внешней библиотеки. С этой новостью мне придется полностью пересмотреть нашу стратегию управления переводами.

@ocombe Нет шансов, что Google наймет вас не в качестве подрядчика?😉

@DmitryEfimenko В настоящее время мы используем ngx-translate и вполне им довольны.

@ocombe , какова вероятность того, что Google примет эту функцию от внешнего разработчика/сообщества? Я думаю, что мы ждем слишком долго.

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

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

@ocombe @IgorMinar Я хотел бы предложить волонтерскую работу для Ivy i18n, пожалуйста, дайте мне знать, если есть шансы.

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

Я готов внести свой вклад, но совершенно не знаю масштаба и сложности задач. Можем ли мы принять список в исходном сообщении в качестве нашей спецификации/требований?

Нет, этот список устарел.
Я сообщу команде, что вы двое заинтересованы, чтобы мы могли посмотреть, как это организовать.

@ocombe Думаю, нас больше, чем двое.

Что нам нужно от команды Angular:

• список требований/некоторая спецификация
• приблизительная оценка сложности
• 1-2 ментора для общения

с этим сообществом можно было организовать разработку и разделить задачи

Есть то, о чем я знаю на https://hackmd.io/UfFN_wyVT-Ob1p70nA3N_Q?view

@fetis Возможно, не стоит слишком сильно разделять работу, общение и обмен контекстом также обходятся дорого, особенно для некоторых основных работ с высокой вероятностью конфликтов.

Все еще удивлен, что XLIFF указан как плюс (точнее, его отсутствие для ngx-translate является минусом). Google Translate и другие службы Google, похоже, используют файлы ARB, которые представляют собой JSON-представление строк перевода. Например, мы создали наши мобильные приложения с помощью Flutter/Dart, где INTL реализован с помощью файлов ARB. Было бы неплохо, если бы команда Angular при просмотре учитывала это для лучшего взаимодействия с другими элементами экосистемы Google.

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

Я согласен, но я не думаю, что все это может быть доставлено одним человеком в разумные сроки. Размах слишком велик

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

Я согласен, но я не думаю, что все это может быть доставлено одним человеком в разумные сроки. Размах слишком велик

@fetis Я могу работать с тобой. Мы очень хотим использовать angular i18n в наших проектах, но он очень ограничен.

Я сообщу команде, что вы двое заинтересованы, чтобы мы могли посмотреть, как это организовать.

@ocombe какие-либо отзывы от команды Angular?

Я дал им знать, и они казались заинтересованными, но им нужно придумать конкретный план для всего этого, прежде чем они смогут принять внешнюю помощь (иначе вы, вероятно, не будете работать над тем, что необходимо).
@petebacondarwin с этого момента возглавит

Привет @ocombe , я просматривал комментарии и примерно понял, что по-прежнему нет возможности создавать динамические идентификаторы для тега i18n, пока мы используем их в * ngFor. Есть ли другой вариант или обходной путь? Или мне нужно использовать только ngx-translate.

@swapnilvaidankar Я не думаю, что есть обходной путь, нет

@swapnilvaidankar - можете ли вы объяснить, что вы имеете в виду?

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

Как мы знаем, для перевода статического текста на любой другой язык мы должны использовать атрибут i18n в теге элемента HTML, как показано ниже:

<h1 i18n = "Card Header | Title for the under construction card@@constructionheader">Under Construction</h1>

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

  <trans-unit id="constructionheader" datatype="html">
    <source>Under Construction</source>
    <target>En construction</target>
    <context-group purpose="location">
      <context context-type="sourcefile">src/app/app.component.html</context>
      <context context-type="linenumber">3</context>
    </context-group>
    <note priority="1" from="description"> Title for the under construction card</note>
    <note priority="1" from="meaning">Card Header </note>
  </trans-unit>

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

Я пробовал так,

• 
  {{ товар }}
  

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

  <trans-unit id="product" datatype="html">
    <source><x id="INTERPOLATION" equiv-text="{{ product }}"/></source>
    <context-group purpose="location">
      <context context-type="sourcefile">src/app/product/product.component.html</context>
      <context context-type="linenumber">6</context>
    </context-group>
    <note priority="1" from="description"> product name from List</note>
    <note priority="1" from="meaning">product name </note>
  </trans-unit>

Проблема здесь, если вы видите идентификатор втег только "продукт". Однако я ожидал, что идентификаторы должны генерироваться динамически в соответствии со списком продуктов, которые будут доступны в раскрывающемся списке.

Не уверен, как добиться этого при работе с динамическим контентом или списком контента.

Извините за обширное объяснение.
Я надеюсь, что вы поняли проблему здесь.

Спасибо,
Свапнил

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

Атрибуты @swapnilvaidankar i18n предназначены для перевода статического текста, а не динамического контента. В вашем примере «продукты» либо исходят из вашего исходного кода (определены в вашем файле ts), и вам нужно использовать ngx-translate (или перевели названия продуктов непосредственно в файле ts), либо исходят из запроса Http. то переведенные названия продуктов должны быть предоставлены вашим сервером.

Я не думаю, что нам нужен новый выпуск для этого. Это просто запрос на оперативные переводы в файлах TS, который уже запрашивался много раз.

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

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

@fetis Да, эту проблему я видел много раз во многих местах, но не нашел подходящего решения. Я также наткнулся на ngSwitch, но в моем случае это не подходящее решение. Однако спасибо за обходной путь.

@ocombe Я считаю, что мне нужно опубликовать это как проблему где-нибудь еще, чтобы обсудить то же самое, а не здесь. 👍

Спасибо всем за ответы.

@petebacondarwin @swapnilvaidankar вот проблема https://github.com/angular/angular/issues/11405 , которую вы ищете
начиная с 2.0.0-rc.6 (!) кстати

Привет @ocombe , эта проблема все еще актуальна? Похоже, Ivy будет использоваться по умолчанию в Angular 9, поэтому мне интересно, каков статус i18n? Не могли бы вы оценить, когда он может быть готов к производству? С угловым 9, 10, 11? Если не с Angular 9, будет ли Angular 9 (и Ivy) поставляться без i18n или будет использовать старый i18n?

Дополнительную информацию о текущем состоянии можно найти в этой проблеме (https://github.com/angular/angular/issues/11405). Комментарии, которые стоит прочитать в этом выпуске о текущем состоянии:

• https://github.com/angular/angular/issues/16477#issuecomment-512290696
• https://github.com/angular/angular/issues/16477#issuecomment-506378004
• https://github.com/angular/angular/issues/16477#issuecomment-512548506

Также это стоит проверить.

Хотя мы переключаем переключатель в v9, чтобы по умолчанию использовать ivy, мы ожидаем, что может быть ряд сценариев, которые не полностью работают, и что эти проекты пока будут придерживаться view-engine.
Мы работаем над запуском i18n для версии v9.0.0, но это будет сложно.

Каков текущий статус «Время выполнения i18n (один пакет для всех локалей)»?

@Ivajkin - извините, что эта проблема не обновляется.

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

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

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

Все это находится в разработке для v9.0.0.

Посетите https://github.com/angular/angular/tree/master/packages/localize , чтобы узнать, где мы находимся.

@petebacondarwin Не могли бы вы немного рассказать о новом переводе во время компиляции? Позволит ли это нам создать единый пакет (с AOT), работающий для всех языков?

В новом подходе вместо того, чтобы выполнять перевод внутри компилятора Angular, мы просто «помечаем» сообщения, которые необходимо перевести, с помощью глобального обработчика шаблонных строковых тегов $localize . Эти помеченные строки выдерживают все виды связывания и минимизации, так что в конце вашего конвейера сборки они все еще существуют и могут быть обнаружены. Эти файлы могут быть пакетом вашей библиотеки, который вы отправляете какой-либо другой команде для включения в свое приложение!

Теперь у нас есть несколько вариантов:

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

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

Вариант исполнения б) пожалуйста. Мы могли бы загружать переводы в виде файлов JSON и переключать языки во время выполнения, как в настоящее время мы делаем это с помощью ngx-translate .

Спасибо за объяснение. Я понимаю, что подход а) более «угловой», но большим преимуществом подхода б) (и ленивой загрузки в целом) также является возможность динамически определять/изменять переводы пользователями (измененные переводы для приложений можно было бы использовать сразу) . Если я правильно понимаю, любое небольшое изменение перевода в подходе а) будет означать новую перестройку.

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

Возможно, вы также подумали о возможности того, что по умолчанию при загрузке будет использоваться подход а). Если возникнет запрос на перевод во время выполнения (например, серверная часть начнет отправлять более новые переводы), отмеченные блоки (содержащие статический текст до сих пор) начнут сканироваться и динамически заменяться, как в подходе б). Таким образом, b) будет активирован только в случае необходимости, и все переводимые части будут подготовлены в соответствии с процедурой a). Я понимаю, что такой подход был бы более обременительным, чем сам подход б) и, безусловно, напрямую не осуществим таким образом, но это было бы ближе к реальным потребностям пользователей.

К перечисленным вами вариантам я готов пожертвовать примерно 25% производительности приложения в определенных случаях, чтобы добиться такой динамической функциональности (конечно, я бы не стал использовать этот динамический подход везде). Таким образом, если бы локализованный шаблон AOT отрисовывался за 0,4 секунды, в случае динамического шаблона, если бы он был сгенерирован за 0,5 секунды, я бы по-прежнему считал его приемлемым в приложениях, где мне нужны такие немедленные реакции на изменение перевода.

@demisx оба подхода будут доступны с v9, но сначала будет полностью поддерживаться только вариант а) (для ретросовместимости), для варианта б) могут быть разработаны новые вещи, прежде чем он будет полностью одобрен командой Angular.
Моя библиотека Locl предоставит несколько помощников для варианта b), когда будет выпущена версия 9, чтобы каждый мог ее использовать, пока команда Angular не заполнит этот пробел.

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

Переведенные сообщения являются статическими по отношению к строкам с тегами $localize . Таким образом, компонент необходимо будет повторно визуализировать. И в зависимости от кэширования шаблонов в IVY может оказаться, что повторного рендеринга недостаточно.

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

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

Запуск ng xi18n в Angular 9 RC1 возвращает «Извините, но i18n еще не реализован в Ivy», но журнал изменений указывает, что сейчас реализована _some_ поддержка i18n. Я предполагаю, что файлы перевода должны быть обновлены вручную?

@ neil-119 В настоящее время извлечение не поддерживается в режиме плюща. Вам все еще нужно отключить плющ, чтобы запустить извлечение. Но затем вы можете снова включить его для использования извлеченных файлов перевода.

Я надеюсь, что планируется включить извлечение в финальную версию v9.

@ neil-119 Angular CLI должен автоматически использовать VE для извлечения. Вам не нужно ничего делать, чтобы это сработало. Мы также проверяем это, поэтому я удивлен, что оно сломано. Можете ли вы открыть вопрос с репликой, пожалуйста?

В настоящее время извлечение не поддерживается в ivy-mode.

или нет, это шоу-стоппер. В настоящее время у нас есть автоматизированный процесс извлечения строк. Как мы можем перейти на Ivy, если мы не можем автоматически извлекать переводы?
Манипулировать sconfig.json every time ? Это не звучит хорошо для меня.

@fetis - я был неправ. Если вы используете интерфейс командной строки, то вызов ng xi18n должен работать должным образом, даже если включен ivy.

@petebacondarwin спасибо. Я собираюсь попробовать Ivy в наших текущих проектах, так что надеюсь, что скоро подтвержу это.

Привет, я пытался использовать в своем компоненте (angular 9.0.0-rc.1)

$localize `some string to localize`;

найден как doc в исходном коде @angular/localize/init.

Когда я пытаюсь построить как обычно для своего языка, я получаю эту ошибку
No translation found for "4145296873012977836" ("some string to localize").

Как я могу предоставить перевод для этой строки?
Я ожидаю, что ng xi18n сгенерирует файл .xlf с этим текстом из кода компонента. Это правильно или я что-то упускаю?

Привет @ Ks89 - извлечение сообщений из кода приложения (а не из шаблонов) не поддерживается для v9.
Но вы можете обойти это, если вы подлый. 4145296873012977836 — это идентификатор сообщения, поэтому, если вы предоставите перевод в файле перевода с этим идентификатором, он будет использоваться при переводе.

@petebacondarwin, когда эта функция будет добавлена ​​в Angular?
Я думаю, что действительно важно сделать переводы во время выполнения в компоненте действительно полезными.

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

Спасибо за ответ

Я ожидал этого в 9.1

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

@petebacondarwin Angular 9 теперь выпущен с новой функцией тега $localize, но без извлечения сообщений. Ранее вы сказали, что мы можем ожидать этого в Angular 9.1. Верен ли этот прогноз и можем ли мы ожидать, что $localize API будет стабильным?

Вы можете извлекать переводы из шаблонов.
Если вы хотите использовать $localize в своем коде, вам следует взглянуть на Locl: https://github.com/loclapp/locl/
@locl/cli позволит вам извлечь из кода и шаблонов

@vekunz - прогноз еще в силе. Более того, как указывает @ocombe , текущий механизм извлечения перевода CLI отлично работает для любого перевода, который находится в шаблоне Angular (т.е. материал, отмеченный тегами i18n ). Единственное, что вы сейчас не можете извлечь с помощью основных инструментов, — это вызовы $localize в вашем собственном коде (например, в сервисе или компоненте).

Сам по себе вызов $localize является стабильным API.

Инструмент, который выполняет переводы и извлечение (в частности, во время компиляции), по-прежнему не является общедоступным. Но это не проблема, если вы не планируете создавать собственные инструменты вокруг этого (как @ocombe делает в Locl!).

Спасибо, @petebacondarwin , благодаря этому мы могли дублировать тексты из кода в «скрытый» шаблон компонента для извлечения. Тогда и извлечение, и перевод должны работать, не так ли?

@ocombe Учитывая прогноз, что извлечение работает с Angular 9.1, наш менеджер не стал бы платить за ваше решение. Тем более, что нам не нужно живое переключение языков и перевод маршрутов.

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

Да, действительно, этот обходной путь будет работать на данный момент.

Я в замешательстве: будет ли перевод во время выполнения также возможен в 9.1? Или просто извлечение вне шаблонов? Или ничего из этого?

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

@JustDoItSascha
Я создал простую демонстрацию, которая демонстрирует перевод во время выполнения.
https://stackblitz.com/edit/ivy-vjqzd9?file=src%2Fapp%2Fapp.component.ts

Привет! Я пытаюсь вызвать loadTranslations в main.ts, потому что строки переводятся, пока JavaScript анализирует импорт, но этого недостаточно.

main.ts импортирует AppModule, который импортирует AppComponent (где я использую $localize ).

Чтобы заставить его работать, я делаю:

loadTranslations(......);
import('./app/app.module').then(m => platformBrowserDynamic(). bootstrapModule(m.AppModule);

Теперь это работает, но приводит к тому, что пакет Angular «complier.js» включается в пакет поставщика.

Любой способ избежать этого? Спасибо

В настоящее время loadTranslations необходимо вызвать перед запуском приложения, поэтому это можно сделать в polyfills.ts . И если вы хотите загрузить другой набор переводов, вам придется перезагрузить страницу. Если вы хотите немного больше понять, почему, я написал https://blog.ninja-squad.com/2019/12/10/angular-localize/ , чтобы объяснить это.

В настоящее время loadTranslations необходимо вызвать перед запуском приложения, поэтому это можно сделать в polyfills.ts .

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

@vekunz это веская причина пока не использовать мою библиотеку 😊 что , как говорится, Locl - это не только извлечение, я намерен добавить множество других инструментов для упрощения i18n

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

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

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

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

Изменения, которые мы внесли в v9, касаются перевода на основе $localize . Основная цель этого состояла в том, чтобы отделить перевод от компилятора Angular, чтобы он позволил ряд приятных улучшений:

Первая из них, доступная сразу всем пользователям версии 9, заключается в ускорении генерации переведенных приложений. Раньше весь конвейер сборки нужно было запускать для каждого языка, на который вы хотели перевести свое приложение. Теперь основная компиляция вашего приложения должна быть запущена только один раз, а окончательный процесс перевода, который значительно короче, выполняется для каждого языка на выходе сборки. Для поддержки этого есть новый пакет @angular/localize , изменения внутри компилятора Angular и целая куча работы внутри Angular CLI, чтобы сделать его максимально плавным и прозрачным.

Во-вторых, поскольку теги $localize можно оставлять в распространяемом коде, теперь также можно выполнять перевод в браузере (во время выполнения, а не во время компиляции). Это то, что мы подразумеваем в основной структуре Angular как перевод во время выполнения. Но обратите внимание, что окончательный результат этого фактически такой же, как перевод во время компиляции. Перевод происходит только один раз; если вы хотите изменить язык во время выполнения, вы должны перезапустить все приложение (например, через перезагрузку). Это имеет то преимущество, что позволяет проекту развернуть один дистрибутив с многочисленными файлами перевода, что полезно в небольшом числе случаев использования, когда вы не хотите заранее создавать все различные переводы. Есть некоторые сложные проблемы с загрузкой переводов достаточно рано, как указано здесь @ocombe и другими. Вы можете рассмотреть https://www.locl.app/ для получения дополнительной помощи в этом.

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

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

Наконец, обратите внимание, что динамическое изменение переведенных строк во время выполнения специально не поддерживается (по замыслу) основной структурой Angular. Включение переведенных строк в систему обнаружения изменений Angular создало бы слишком большую нагрузку для большинства приложений и снизило бы производительность. Из моего взаимодействия с сообществом я практически не видел реальных сценариев, в которых это действительно необходимо, помимо перезапуска приложения при смене языка. Если это требование для вашего приложения, вы можете добиться этого, используя специально созданный конвейер для ваших строк в шаблонах, который извлекает переводы и, возможно, даже вызывает $localize на лету для перевода, но это не похоже на это было бы очень эффектно. В противном случае вы могли бы рассмотреть более динамичный подход, такой как https://netbasal.gitbook.io/transloco/.

Основными изменениями, которые появятся в следующей второстепенной версии Angular, будет улучшенное извлечение перевода, которое сможет идентифицировать и извлекать локализованные строки из кода TS — в настоящее время извлечение CLI обрабатывает только локализованные строки в шаблонах.

Изменения для улучшения перевода во время выполнения, как описано выше, появятся не раньше, чем после версии 9.1.

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

Я могу ошибаться, но только в этой ветке многие люди явно проявляли интерес к возможности менять язык вживую, во время выполнения, без необходимости пересобирать или перезагружать приложение. Или у всех здесь разное определение runtime translation ?

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

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

Вопрос: зачем пользователю переключать языки при переходе к определенной форме в вашем приложении?

Я не думаю, что живое переключение также необходимо. Как часто вы меняете язык сайта? Обычно один раз, максимум. И в этот раз перезагрузка страницы не так критична. Как сказал @petebacondarwin , почти все сценарии для живого переключения не имеют отношения к реальным сценариям, а просто «приятно иметь».

Или у всех здесь разное определение перевода во время выполнения?

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

Фактическое переключение языков после загрузки страницы приятно иметь.

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

Вопрос: зачем пользователю переключать языки при переходе к определенной форме в вашем приложении?

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

У меня есть важный вопрос: могут ли файлы перевода загружаться асинхронно? Все мои переводы хранятся в базе данных, так как важно иметь возможность обновлять их без перестройки.

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

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

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

Технически вы можете перезагрузить все приложение и оставить пользователя там, где он был.
Вам «просто» нужно иметь управляемое состоянием приложение (с ngxs, ngrx или любой другой библиотекой управления состоянием), которое где-то хранится и извлекается при запуске.

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

@petebacondarwin Я должен сказать, что согласен с тобой. Я не знаю реальных конечных пользователей (кроме тестировщиков на этапе разработки), которые постоянно переключают приложение между языками при его использовании. Конечно, они делают это, вероятно, в начале, если они как-то открывают его в другом, но позже, это редкий случай.

Или у всех здесь разное определение перевода во время выполнения?

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

Фактическое переключение языков после загрузки страницы приятно иметь.

Я не уверен, что делают ваши клиенты, но «редактирование переводов в реальном времени на рабочем веб-сайте» не похоже на обычный сценарий.

Я не думаю, что смена языка в прямом эфире (_без перезагрузки страницы_) будет таким нарушением условий сделки.
Изменение языка для пользователя происходит только один раз;

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

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

В конечном счете, для меня это сводится к трем вещам;

1. Извлечение переводов из шаблонов и файлов TS.
   
   
   
   • Обновить ресурс исходного языка.
   
   
   • Также обновить перевод (_если у меня несколько языков, fr, en, de... Я хочу, чтобы все они были обновлены новыми ключами перевода и удаленными._)
   
   
2. Одна сборка для всех переводов (_Хорошо иметь 1 сборку для каждого перевода, если это не умножает время сборки._)
3. Получение доступных языков и изменение языка с помощью перезагрузки.

@Карасуни
Вы можете получать переводы асинхронно и только потом загружать приложение angular.
См. мой комментарий выше о том, как асинхронно загрузить app.module с помощью import(...) .

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

в наши дни быть двуязычным или трехъязычным более чем обычным явлением (за исключением США, никакого вреда не имелось в виду).

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

даже ngx-translate от ocombe, который должен быть равнозначным примером для вас, ребята, «переводов с низкой производительностью», работал достаточно быстро для обычного пользователя.

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

со всем сказанным, я не могу согласиться с этим:

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

Википедия — наихудший пример этого, потому что разные языки статьи на самом деле являются независимыми статьями. Обычно вам не нужны разные языки одного и того же сайта. Даже если вы работаете на четырех языках.
И если вам действительно нужно живое переключение, вы можете использовать либо обходной путь с пользовательским каналом перевода, о котором упоминал @petebacondarwin , либо новый инструмент от @ocombe.

Итак, я не думаю, что это действительно лучшее место для обсуждения. Я обеспокоен тем, что (хотя до сих пор все было очень разумно), мы можем скатиться к негативной дискуссии. Боюсь, что в обозримом будущем фреймворк Angular не предоставит живого решения для переключения языков из коробки.

Я чувствую, что ценность этого вопроса исчерпала себя. Я переместил открытые проблемы и PR, которые указаны в описании этой проблемы, на https://github.com/angular/angular/milestone/101 , и я собираюсь закрыть и заблокировать этот PR.

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