Eu gostaria de ver a capacidade de fazer ligações dinâmicas no modo aot. Existem dois casos de uso em particular para comprovar por que isso deve ser adicionado ao roteiro.

O primeiro é o caso de uso básico em que você não deseja aplicativos separados para cada idioma. Isso requer algum tipo de lógica de redirecionamento fora do aplicativo e não permite a alteração dinâmica do idioma sem um recarregamento completo do site.

O segundo é o caso em que você está incorporando o aplicativo no celular usando o cordova. Até onde eu sei, sua escolha é jit, deixando o site mais lento, criando um aplicativo separado para cada idioma ou incluindo todos os idiomas no aplicativo (o que obviamente o sobrecarrega). Nenhuma dessas opções são boas. Parece que o Ionic não usa i18n, e me pergunto se esse é o motivo.

@jlutz777 esses são 2 casos de uso válidos, esse assunto foi discutido internamente ultimamente e eu tenho defendido isso também. Ainda não é possível, dado como o i18n e o AoT funcionam em Angular, mas pode ser no futuro assim que obtivermos o novo processo de compilação do AoT na v5.
Vou adicioná-lo ao roteiro uma vez/se tivermos algo oficial e concreto sobre isso.

Estou trabalhando no aplicativo Electron + Angular 2 e agora estou tentando adicionar suporte para localização para vários idiomas usando o recurso i18n com Angular. Na verdade, a extração de string de modelo e a conversão em diferentes formatos de arquivo de idioma estão claramente documentadas, embora eu ainda não consiga esclarecer e procurar:

• Posso mudar de idioma dinamicamente? ou preciso construir o aplicativo separadamente para um idioma diferente.
• Posso gerenciar/consolidar todas as strings em um só lugar (na forma de par chave/valor), para que eu possa alterar
  a string em um lugar para ser efetuada em vários lugares?
• Posso acessar o arquivo localizado de qualquer lugar que não seja o modelo para obter uma string de idioma específica com
  chave fornecida? (o mesmo que perguntei acima).

Os pontos 2 e 3 serão resolvidos com o recurso "Usar strings de tradução fora de um modelo - #11405".
Para o ponto 1, veja a resposta que dei a @jlutz777 acima. Por enquanto, você ainda precisa criar o aplicativo em vários idiomas ou usar o JIT, que pode carregar traduções dinamicamente no bootstrap (não está alternando em tempo de execução, mas ainda é melhor do que ter que agrupá-lo x vezes).

a linguagem de interface do usuário usada em um aplicativo deve ser algo que não exija a criação de várias versões do mesmo aplicativo. isso não deve de forma alguma ser um problema de "compilador". se for, então o compilador é falho. os problemas devem ser fazer o design do aplicativo de forma que o texto possa ser carregado de um arquivo de dados em tempo de execução. isso deve ser feito com um módulo/biblioteca que possa ser carregado e usado como qualquer outro. não faça disso uma função de compilador.

@figuerres é algo que será alterado no futuro, sem promessas ainda, mas estamos cientes desse problema e estamos analisando possíveis soluções, usar um arquivo externo é uma delas

Oi @ocombe - Parece que provavelmente usaremos i18n em Angular para nosso aplicativo. Há algum recurso nos documentos que você acha que pode se tornar obsoleto ou sofrer alterações importantes nos próximos meses? Qualquer informação seria muito apreciada. E obrigado novamente pelo DVD!

Oi @rjsteinert! Feliz em saber disso!
Há apenas uma mudança de última hora planejada para agora, é a geração automática de IDs. O método mudará e os IDs não corresponderão mais, mas haverá uma ferramenta de migração cli para atualizar seus arquivos de tradução (e um parâmetro que você pode usar para migrar apenas quando estiver pronto).

Eu pesquisei muito sobre esse tópico hoje e estou querendo saber se poderia haver uma solução "simples" como substituir as tags i18n por uma chamada para um serviço em vez da tradução?

Atual:
<span i18n>Hello world</span> => renderizado para <span>Hello world</span>

Minha ideia:
<span i18n>Hello world</span> => renderizado para <span>{{i18nservice.translate('pass-in-the-generated-message-id')}}</span>

Desta forma, a tradução real poderia ser feita dinamicamente em AOT, pois o serviço poderia ser preenchido a partir i18nservice.setLocale('de-DE') uma API, arquivo etc.
A extração de texto com a ferramenta xi18n ainda funcionaria como antes e poderíamos aproveitar os ids de mensagem gerados de qualquer maneira para usar como índice para o serviço de tradução.
A implementação atual também funcionaria perfeitamente, pois o ngc poderia simplesmente procurar um sinalizador "--use-i18nservice" e compilar como até agora.

Um problema que posso identificar atualmente é a injeção do i18nservice em cada componente, pois ele precisa existir no contexto dos componentes para ser chamado, mas isso deve ser solucionado de uma maneira ou de outra.

Algum pensamento sobre isso?

É uma das coisas que estamos considerando sim, ainda existe o problema de como tratar blocos de código dentro dessas traduções quando o compilador não está disponível em tempo de execução (AOT). Isso significaria que não podemos usar componentes/diretivas/tubos angulares dentro de traduções...

Sim, não pensei nisso.
Atualmente, estou desenvolvendo um POC/solução alternativa que inline todas as traduções no HTML na etapa de compilação (webpack), envolvendo-as em contêineres ng com ng-switch.
Para atributos i18n, está usando uma diretiva configurando-os em nativeElement.
As próprias traduções também são "renderizadas" para substituir todos os marcadores de posição <x id=".. "/> .

É feio, mas funciona... mal posso esperar para que o ng o suporte nativamente.
Publicará o POC ainda esta semana, talvez possa ser útil para sua futura concepção.

Eu criei uma "solução" que atende às minhas necessidades até que haja uma implementação.
O pré-carregador agora renderiza HTML para todas as localidades antes de passar para o compilador, funciona como um encanto até agora.

Repo: https://github.com/actra-development-oss/ng-i18n-aot-loader
NPM: https://www.npmjs.com/package/@actra-development-oss/ng -i18n-aot-loader

possivelmente um componente pode ter um atributo que diga ao sistema/compilador que ele precisa de um serviço.
esse serviço então pega e id e uma localidade e retorna o texto/marcação localizada.
todo o texto localizado é armazenado no servidor como recursos que o serviço pode ler.

se um componente não tiver o atributo no locale run-time.
se o componente o tiver, ele chamará obter os dados localizados em tempo de execução.
o compilador apenas cria os arquivos de dados e conecta o serviço.

isso me parece uma boa maneira de lidar com a necessidade mais comum da maioria dos aplicativos e não exigir que os sites criem e mantenham várias cópias do mesmo aplicativo.

Eu também tive essa ideia.
O problema é que as traduções podem conter ligações e, portanto, abririam o sistema para injeção de código ao carregar arquivos de tradução de recursos externos.
Além disso, um compilador seria necessário para resolver essas ligações dinamicamente, dependendo da tradução.

IMHO uma solução válida poderia ser a maneira que eu implementei como POC (veja o comentário acima) para traduções inline em tempo de compilação, apenas de uma maneira mais elegante e integrada.
Ambos os problemas mencionados acima seriam eliminados, a única desvantagem que posso imaginar é possivelmente o tamanho do pacote, que cresceria para "pacote simples" + (traduzido html-size * locales).
Isso poderia ser reduzido por apenas ng-switch ing o i18n -tagged html em vez de todo o documento, mas ainda há um problema para i18n-* -tags.

bem aqui está a coisa; às vezes você tem limites....

do ponto de vista prático, pode ser melhor não ter isso, você pode ter um pedaço de texto que pode ser dado em vários idiomas. fim da história.

você precisa ter um pedaço vinculado a dados? ok mas isso não está dentro do texto internacionalizado, tem que ser separado. você ainda pode usar html e css para estilizar e formatar o resultado. mas você não pode incorporá-los ou combiná-los de todas as maneiras possíveis.
como dizer que uma tag div ou ap pode ter vários intervalos, um intervalo é o texto e outro intervalo é uma data vinculada, o intervalo de texto está vinculado ao serviço de localidade i18n, a data está vinculada a algum serviço de data, os dois intervalos estão em um tag de parágrafo que os formata.

Mantenha-o simples, faça funcionar para 95% de todos os usuários primeiro e depois descubra os casos extremos.

Não vejo isso como um caso extremo, é um negócio normal.
Angular é uma estrutura de nível empresarial, então muitos, se não todos, os usuários do i18n exigirão ligações, ou pelo menos pluralização e seleções, dentro de textos.

<span i18n>Hello, {user.gender, select, m {Mr.}, f {Ms.}} {{user.name}}</span>
Como você resolveria isso com strings separadas?
Resposta simples: você não pode, como você não pode conhecer as regras do idioma de destino, nem todo idioma segue o formato 'saudação', 'gênero', 'nome'.

Separar esses pedaços seria:

• matar contexto, o tradutor não entenderia o significado da frase completa
• mesclar os pedaços na ordem certa por CSS não é possível, você teria que especificar regras para cada tradução, então o cara do CSS precisa conhecer os idiomas de destino ou o cara da tradução precisa saber CSS, nem é aceitável.

O core i18n funciona em angular conforme o esperado e é utilizável para aplicativos de nível empresarial, a única coisa que falta aparentemente é a compatibilidade AOT, então não entendo o seu ponto de vista por que um sistema poderoso e funcional deve ser substituído por algo que não seja metade dessa capacidade exigindo várias vezes o trabalho para fazê-lo.

Temos uma reunião amanhã para encontrar uma solução para este problema.

@ocombe fico feliz em ouvir isso, espero que isso leve a algumas coisas boas para uma versão futura do Angular , aqui no trabalho estamos realmente amando como a maior parte funciona para nossas necessidades de desenvolvimento!

@ocombe , é possível alterar o idioma sem refazer o documento inteiro? Eu explico :
Estou na página chamada "sobre", mas quando mudo o idioma, sou redirecionado para a página de entrada principal do meu aplicativo.

Enquanto trabalhava no meu aplicativo i18n, também me deparei com o "bug" conhecido de que folhas de estilo externas de, por exemplo, @angular/material (residindo em node_modules) não puderam ser resolvidas e, portanto, a ferramenta ng-xi18n falhou.
Eu implementei um "ignore missing files"-HostContext para a ferramenta de extração, também como POC, mas adicionei como PR # 17845 para vinculá-lo ao repositório principal.

@ocombe , como você parece ser muito ativo neste tópico, você se importaria de dar uma olhada no PR e dar feedback?

Obrigado, vou dar uma olhada.

Já faz alguns dias procurando uma maneira de implementar a internalização em todo o projeto incluindo dados dinâmicos, mas não encontrei nada de concreto. Você pode me sugerir algo mais que pelo menos me ajude por enquanto. Obrigada.

Olá @ocombe! Podemos ter um acompanhamento sobre o ponto levantado por @jlutz777 (sobre ligações dinâmicas, portanto, não tendo um aplicativo por idioma)?

Muito obrigado pelo seu trabalho!

@vicb está trabalhando nisso agora, será em 5.x (não 5.0, mas provavelmente 5.1)

@ocombe A lista de verificação deve ser atualizada? Eu posso ver alguns deles já foram mesclados em versões mais recentes. E isso refletirá melhor seu trabalho duro. 😃

sim, boa ideia, vou atualizar
editar: atualizado

Runtime i18n (um pacote para todas as localidades com AOT) - [trabalhando nele]

Onde está a questão / PR / discussão associada?

Seria legal ter uma API para estender formatos de data nomeados (por exemplo ultraLongDate ) para que o pipe de data nativo estivesse ciente disso e o pipe de data personalizado não fosse necessário.

Apenas curioso sobre o progresso em "Runtime i18n (um pacote para todas as localidades com AOT)."

Minha equipe tem vários aplicativos grandes com mais de 60 idiomas. No momento, executamos N builds em paralelo, de modo que N é o número de idiomas. Isso consome muitos recursos, como você pode imaginar, especialmente considerando que os aplicativos são bastante grandes e são implantados várias vezes ao dia em vários ambientes.

O que eu espero é:

1. Algum ETA aproximado no tempo de execução i18n
2. Confirmação de que o runtime i18n fará uma única compilação para todos os idiomas
3. Se cada idioma produzido será ou não carregado com preguiça ou em um único pacote massivo

@chcaru enquanto espera que o ng forneça uma solução "nativa" dê uma olhada em https://github.com/actra-development-oss/ng-i18n-aot-loader/
Ele fornece exatamente o que você está pedindo, uma compilação AOT com várias localidades.

@chcaru :
1/ ETA aproximado é Angular v6 (o primeiro beta deve ser até o final de janeiro eu acredito? não tenho certeza), a boa notícia é que as traduções de código devem seguir rapidamente após as traduções em tempo de execução, pois quase todo o trabalho será feito
2/ sim
3/ traduções devem ser separadas do pacote, você poderá carregar lentamente o que você precisa antes do bootstrap, ou apenas agrupar tudo em um, também queremos suportar traduções de carregamento lento para módulos, mas não tenho certeza de quando isso acontecerá estar disponível

@ocombe até que o angularv6 seja lançado, a opção mais séria para carregar traduções dinamicamente e/ou criar um aplicativo multilíngue com um único pacote é ngx-translate.

Você tem algumas dicas para ajudar as pessoas que estão começando a usar o ngx-translate para migrar facilmente quando o angularv6 estiver fora?
Alguma ponte entre as duas aplicações?

Na verdade não, o código é bem diferente... veremos quando a v6 sair com esses recursos se estou motivado para trabalhar em uma ferramenta de migração

Olá, obrigado pela transparência dos próximos recursos.

Seria muito útil saber as respostas para as seguintes perguntas:

1. Alguma ideia de quão diferente será o novo fluxo de trabalho i18n diferente do atual descrito em https://angular.io/guide/i18n ?

2. Os atributos i18n e i18n-*, por exemplo, i18n-title com id personalizado opcional, ainda estarão disponíveis nos modelos?

3. Os comandos a seguir ainda funcionarão?

ng serve --aot --locale fr

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

1. como as unidades trans do messages.xlf extraídas dos templates serão mescladas com as usadas no código?

1. Faremos a experiência de atualização o mais suave possível, provavelmente o que funcionou antes ainda funcionará depois, pelo menos, até a v7.
2. Os atributos do i18n permanecerão os mesmos
3. a extração deve ser a mesma
4. essa é provavelmente a única parte que vai mudar, ainda não sei como, então prefiro não dizer coisas que podem mudar, mas as mensagens serão mescladas em tempo de execução quando as visualizações forem criadas (então entre bootstrap e a visualização que aparece no a tela)

Seguindo o comentário do @Toub , para este período de transição, estaríamos interessados ​​em ter feedbacks para a seguinte abordagem (misturando o atributo i18n e ngx-translate) que queremos implementar. Nosso objetivo é minimizar mais atualizações a serem feitas no código quando o novo suporte i18n estiver pronto.

(Observe que queremos localidades dinâmicas, ou seja, não um aplicativo gerado por localidade)

• Usaremos o atributo i18n para podermos aproveitar a ferramenta de extração angular.
• Com base na ferramenta extraída, podemos converter arquivos xliff (ou com outros formatos) para conteúdos com formatos que podem ser usados ​​pelo ngx-translate (json ou po)
• Vamos aproveitar o atributo translate em elementos usando o i18n para aplicar traduções (extraídas anteriormente)

Aqui está uma amostra:

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

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

Obrigado por seus feedbacks!

Você poderia abrir um problema no ngx-translate para isso? Eu acho que a melhor coisa provavelmente seria atualizar a lib para suportar os atributos "i18n" como uma alternativa para "traduzir"

@ocombe obrigado pela sugestão! Acabei de adicionar um problema para isso no ngx-translate ...

@ocombe o problema que posso ver é que os atributos i18n / i18n-* são removidos em tempo de execução (https://github.com/angular/angular/issues/11042). Existe uma maneira de mantê-los?

Eu verifiquei e, a menos que eu esteja enganado, eles só são removidos se você usar o Angular i18n (o que significa que você carrega as traduções quando está fazendo a compilação).

@ocombe eu entendo mas não carrego as traduções pois estou usando o Angular CLI e iniciei o aplicativo com ng serve ...

@ocombe , nossa empresa logo fará um esforço para oferecer suporte a i18n usando a estratégia de vários aplicativos por localidade atualmente prescrita. Também estamos planejando incluir a localidade no URL e definir o href base no aplicativo. Depois que o recurso i18n de tempo de execução estiver concluído, quais alterações precisaríamos fazer com nossa estratégia de localidade de URL? Existe uma maneira melhor de começarmos a evitar uma grande refatoração assim que o runtime i18n for lançado? Obrigado pelo seu trabalho em tudo isso.

⬆️ deve dizer "vai começar em breve"

um aplicativo/locale ainda deve estar funcionando como está agora (menos a pequena alteração para carregar o arquivo de localidade no bootstrap se você não estiver usando o cli)

Alguém poderia me direcionar em qual arquivo os atributos i18n são removidos do template durante o pacote?

cc @ocombe

Foi alterado em 4.2.6 (PR https://github.com/angular/angular/issues/17999)

Oi! Acompanho este tópico há muito tempo. Vi que saiu o primeiro beta para v6. Eu li o changelog, mas não vi nada relacionado a esse problema de longa data. Alguma novidade nessa frente? Ou, pelo menos, há alguma garantia de que a interface será semelhante ao seu polyfill?

Obrigado pelo seu trabalho!

Vai estar em um dos últimos betas, ou talvez RC (eu sei, eu sei...).
A interface será semelhante a goog.getMsg do encerramento, pois é isso que o google usa internamente para traduções de código: https://developer.pubref.org/static/apidoc/global/closure/goog/getMsg.html
Mas podemos estar usando um wrapper, então talvez mude a interface do Angular, ainda não tenho certeza.
No meu polyfill eu uso uma interface parecida, mas com a possibilidade de definir id, description & meaning se necessário, e acredito que vamos precisar disso de uma forma ou de outra (seja via parâmetros, ou via decorador)

Obrigado por todo o seu trabalho duro! Estamos nos preparando para uma reescrita completa de todo o nosso aplicativo 1.x a partir de abril. Existe alguma coisa que podemos/devemos fazer para nos preparar para essas mudanças? Agora estamos planejando usar 6.x. Obrigado novamente!

@ocombe Apenas curioso quando "Ignorar espaços à esquerda e à direita" chegará?

Eu preciso atualizar o roteiro, mas está um pouco confuso agora (mesmo para mim). Esse recurso em particular claramente não é uma prioridade, não espere que trabalhemos nele tão cedo

@ocombe Sim, isso seria ótimo. Nós também estamos muito interessados ​​no tempo de execução i18n, pois é o único ponto de bloqueio para nós. Você poderia dar um palpite sobre sua conclusão em %?

Muito obrigado pelo seu trabalho árduo!

@ocombe

Esse recurso em particular claramente não é uma prioridade, não espere que trabalhemos nele tão cedo

Você poderia esclarecer de qual recurso você está falando aqui? Não quero fazer suposições.

@ofuangka o recurso "Ignorar espaços à esquerda e à direita" não é uma prioridade.
@Karamuto difícil de adivinhar por enquanto, estamos trabalhando nisso agora

@ocombe
Você poderia compartilhar seu marco sobre o Runtime i18n (um pacote para todas as localidades com AOT)

Agora decidimos usar as ferramentas xi18n ou usar bibliotecas de terceiros para um grande projeto multilíngue.
Esperamos poder usar ferramentas canônicas, mas cientes de que são muito cruas.

Também gostaríamos de poder dividir arquivos xlf (um arquivo por módulo), é possível?

acima, acima
o runtime i18n será lançado em Angular 6?

obrigado e feliz codificação!

Perdendo a esperança aqui, que isso seja concluído a tempo, pois não resta muito tempo e não houve realeses até agora em relação a esse recurso.

O lançamento da versão 7 seria muito tarde para nós.

@Karamuto #22654
Eu acho que será lançado na v6, mas eles têm que terminar Ivy primeiro.

Devemos ter um hello world funcionando esta semana, mas com recursos mínimos (sem suporte de UTI, por exemplo).
Mas como foi lançado com ivy que está atrás de uma bandeira, continuaremos trabalhando nele e lançaremos assim que terminarmos um novo recurso, não há necessidade de esperar pela v7

@ocombe
Isso parece ótimo! Não precisa ser completo com UTI desde o início. Se ele avançar nas últimas versões da v6, isso é completamente bom para nós.

Obrigado pelo ótimo trabalho novamente!

@Karamuto veja #22654 para uma prévia!

Pergunta idiota: Existe uma maneira de ter uma diretiva i18n para entradas baseadas em string para componentes personalizados. Um exemplo ao encaminhar rótulos aria:

Eu envolvo um botão personalizado que faz coisas legais:

O modelo de botão personalizado apenas faz:

Já existe uma maneira de fazer isso?

@kekraft Acho que com entradas estáticas você pode usar a sintaxe do atributo i18n:

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

No componente:

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

@ocombe você precisa de contribuidores para realizar qualquer trabalho do i18n em tempo de execução ?

Isso ! v6 publicado ~~~
alguma atualização aqui?

o exemplo i18n angular 6 está aqui
https://github.com/angular/angular/pull/23660

@sandangel você quis dizer simplesmente "tudo" ou "tudo o que é verificado", dos planos no início deste tópico?
Estava realmente ansioso para ter um único aplicativo, acho que isso é uma das coisas mais importantes. Foi para o #23660 que você vinculou e chegou a https://pr23660-e12f469.ngbuilds.io/guide/i18n
Mas aí ainda diz:

Ao internacionalizar com o compilador AOT, você deve pré-compilar um pacote de aplicativo separado para cada idioma e servir o pacote apropriado com base na detecção de idioma do lado do servidor ou nos parâmetros de URL.

É possível ter um único aplicativo para vários idiomas ou ainda não?

@MrCroft parece que o tempo de execução i18n ainda está em andamento. Eu li como você mais algumas opções, mas não um pacote para todas as localizações :(

Temos um hello world funcionando, mas é apenas para o novo renderizador (ivy) e como o ivy não está pronto para o horário nobre, você terá que esperar por isso, infelizmente :(

@ocombe então, a menos que não tenhamos Ivy em produção (provavelmente por volta da v7), não teremos traduções em tempo de execução. isso é correto?

@ocombe o hello world e as coisas da ivy estão disponíveis publicamente? Seria legal tentar entender essa nova implementação do i18next😃

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

@fetis sim :(
@feloy sim, o simples olá mundo está aqui: https://github.com/angular/angular/tree/master/packages/core/test/bundling/hello_world_i18n mas muito mínimo
você pode encontrar os testes aqui: https://github.com/angular/angular/blob/master/packages/compiler/test/render3/r3_view_compiler_i18n_spec.ts
e alguma refatoração + extração aqui: https://github.com/angular/angular/pull/22931

@ocombe estamos tentando implementar o i18n em nosso aplicativo, mas sempre que leio sobre isso vejo que precisamos de um arquivo messages.xlf por idioma. Isso não se tornaria uma sobrecarga para manter considerando aplicativos complexos com várias telas voltadas para o cliente etc. Estou olhando para ver se podemos dividir o arquivo de mensagens por componente ou por módulo? Isso já é suportado?

@stickler-v este arquivo é apenas o transporte de suas strings para seu software de tradução. não considere traduzi-lo manualmente.

Entendo, onde temos texto real em diferentes idiomas? Precisamos gerenciar esse texto manualmente em contraste com tradutores fazendo isso.

Desculpe, mas estou um pouco perdido. Com base na documentação original aqui https://angular.io/guide/i18n. src/app/app.component.html terá apenas texto em inglês. messages.fr.xlf é o arquivo que tem texto em francês, mas é gerado automaticamente e não é aconselhável tocá-lo.

Se eu quiser ter app.component.html renderizado usando texto em francês em vez de inglês, onde eu especificaria mensagens em francês "Bonjour" etc. ?

@stickler-v é realmente offtopic, por favor, crie uma pergunta no StackOverflow. Terei prazer em responder lá.

Você pode por favor não discutir isso aqui, não é o tópico aqui, obrigado
Quanto à sua pergunta @stickler-v, um arquivo por módulo / componente não é possível no momento, pode ser no futuro, mas não está na lista de coisas em que estamos trabalhando agora

Algum plano para oferecer suporte a traduções de rotas?

Desculpe se isso já foi respondido, mas as traduções em JS são possíveis com esta versão ou ainda é apenas modelos?

@santhony7 Ainda não é possível, pois Ivy não está pronta.

Uma pergunta que tenho sobre a intenção/funcionalidade do runtime i18n aqui é se isso significa que essencialmente poderemos selecionar o idioma em tempo de execução e "invertê-lo" sem recarregar o aplicativo, como era a funcionalidade no antigo ng-translate para AngularJS e em ngx-translate ? Ou isso significa algo totalmente diferente?

Não, você terá que recarregar o aplicativo para alterar o idioma.

Com o i18n atual, quando você cria e fornece suas traduções, substituímos as strings no código do pacote, o que significa que o pacote está localizado.
Runtime i18n significa que os arquivos de tradução são carregados quando o aplicativo é iniciado e não em tempo de compilação como é agora.
Por causa disso, você poderá carregar lentamente os arquivos de tradução antes que o aplicativo seja iniciado, o que significa que o pacote é separado do idioma, você obtém apenas um pacote para seu aplicativo.
Você também pode optar por ter um pacote por idioma e agrupar o arquivo de idioma com seu aplicativo (como estamos fazendo agora), você evitará o atraso necessário para carregar o arquivo de traduções com preguiça.
Em um caso, você faz uma solicitação http extra, e no outro não, mas não acho que haverá uma diferença grande o suficiente para justificar ter um pacote por idioma.

Vantagens do tempo de execução i18n:

• detecte o lado do cliente de idioma e carregue lentamente o arquivo de traduções que você deseja
• como o código é independente do idioma, você obtém um pacote para todos os idiomas
• bibliotecas também podem ser compatíveis com "i18n"
• como carregamos as traduções em tempo de execução, temos tudo o que precisamos para fornecer um serviço que também possa fazer traduções no seu código (não apenas nos templates)
• poderíamos dividir as traduções por módulo (provavelmente não disponível no início)

Desvantagens:

• traduzir em tempo de execução tem um pequeno custo quando as traduções são extraídas e transformadas em nós html, mas esperamos que você não perceba isso porque o ivy será muito mais rápido que o renderizador atual
• a inicialização do aplicativo é atrasada pelo tempo que leva para carregar lentamente as traduções ou seu pacote é um pouco maior (se você agrupar as traduções)
• temos que adicionar os serializadores ao seu pacote de aplicativos para poder ler as traduções, e isso é muito código (provavelmente poderíamos "pré-compilar" as traduções em algum tipo de json para evitar isso, ainda não decidimos )

Teoricamente, você pode alterar o idioma sem recarregar o aplicativo inteiro, mas terá que recriar os componentes existentes porque os modelos são gerados quando o componente é criado ou você pode vincular o serviço ao seu modelo (em vez de usar i18n atributos) e seria atualizado quando você alterasse o idioma. Seria possível escrever uma biblioteca que funcionasse como ngx-translate, mas usasse Angular i18n internamente e permitisse alterar o idioma em tempo de execução. Ele usaria mais memória para manter os modelos em sincronia com o idioma, como é o caso do ngx-translate. Provavelmente escreverei uma biblioteca como esta.

também para as pessoas pensarem é que algumas mudanças de um idioma para outro podem ser pequenas outras podem ser grandes, digamos que passar de inglês para espanhol pode ser "pequeno", mas de inglês para chinês ou árabe será grande.
para esclarecer para alguns idiomas, não é apenas o texto, você também pode precisar criar um layout diferente para acomodar esse idioma e suas regras de alinhamento, da esquerda para a direita ou da direita para a esquerda e outros detalhes.

então, para a maioria do uso no mundo real, eu esperaria que o aplicativo tivesse no aplicativo carregar uma etapa de detecção de idioma que levará ao carregamento dos recursos corretos e alguns layouts.

@ocombe Muito obrigado por esclarecer! Implementei o atual Angular i18n em nosso aplicativo e encontrei um problema devido a alterações/requisitos desconhecidos. Também estou usando a biblioteca https://github.com/ngx-translate/i18n-polyfill em conjunto para ajudar a preencher a lacuna atual.

Embora os vários pacotes sejam um pequeno aborrecimento, você pode contornar isso com bastante facilidade atualmente. O problema em particular é o potencial de ter um componente (e todos os componentes filho dele) para ser exibido em um idioma diferente do idioma usado atualmente.

Francamente, ainda não tenho certeza se ngx-translate pode ajudar a fazer isso para mim, mas gostaria de enviar uma mensagem a você sobre as próximas alterações apenas para ter certeza de ter o máximo de informações possível antes de fazer qualquer pivô.

Não temos nenhum plano para oferecer suporte a aplicativos traduzidos em vários idiomas ao mesmo tempo, pode ser possível no futuro se pudermos carregar traduções/módulos, mas seria um efeito colateral da arquitetura, não algo que especificamente tentou alcançar.

Existe algum ETA para Ivy + runtime i18n?
Entendo perfeitamente se não for o caso, mas preciso saber se (dado o prazo do meu projeto atual) posso esperar ou preciso começar a usar uma das soluções atuais e adiar a migração para o runtime i18n para uma versão futura .

Não vou tentar dar um prazo exato, todas as vezes que tentei deu errado :D
Não será antes da v7 agora (estará disponível antes como beta)

Não tem problema, todos nós sabemos como as estimativas estão sempre erradas. :D
Você acha que será mais fácil migrar do atual i18n (+ i18n-polyfill) para o runtime 18n ou do ngx-translate ?

provavelmente do i18n atual, mas escreverei uma versão do ngx-translate que usa os internos do Angular i18n, se for possível (ainda não tenho certeza)

Oi, Eu tentei percorrer este segmento para entender o estado atual. O código de tradução ngx é atualmente a "solução alternativa" mais viável para um único aplicativo com localização dinâmica?

Oi, é possível alterar a localização em tempo de execução usando ngx-translate/i18n-polyfill?

@suchg Não em tempo de execução. Você pode fazer traduções em tempo de execução, mas não pode alterar a localidade usada.

@mjschranz obrigado pela resposta rápida
até mesmo as traduções em tempo de execução estão bem por enquanto. você pode compartilhar qualquer exemplo para o mesmo.
Eu tentei o exemplo compartilhado em https://github.com/ngx-translate/i18n-polyfill e mudei no idioma do navegador chrome, mas sem sorte.
existe algum método específico para tradução ??

Por favor, mantenha a discussão aqui sobre Angular, não sobre bibliotecas externas. Se você precisar de ajuda com isso, poste as mensagens em seus repositórios do github

Ei, existem outros problemas de rastreamento ou documentos de design sobre como o recurso será no futuro? Talvez possamos ajudar na implementação ou nos preparar para garantir que a transição na v7 seja a mais tranquila possível.

Olá, atualmente estou executando o Angular 5 e precisamos adicionar vários idiomas ao nosso projeto.
Eu adicionei uma solução que funciona para mim agora, que é quase elegante. https://github.com/angular/angular/issues/24549.

Idealmente, eu gostaria de carregar lentamente os arquivos de idioma com base em um serviço de sniffer de país (com base em uma pesquisa de mapa de nome de host).
Se isso fosse possível em Angular 6, seria ótimo.

@mattiLeBlanc Como você resolve mensagens dinâmicas, por exemplo, mensagens de componentes ou serviços?

@zverbeta Por favor, desculpe-me por não entender completamente o Angular Core ou o contexto desta discussão. Eu só posso abordá-lo do meu contexto para começar.

Em resposta à sua pergunta, eu diria que estamos interessados ​​apenas em carregar lentamente os arquivos de tradução (xlf) de uma maneira agradável, com base em uma localidade que pode ser deduzida da URL ou de um parâmetro de consulta de idioma. (Atualmente, uso um mapa de URL para decidir qual é a localidade).

Uma mensagem de um componente ou serviço não é marcada como marcamos a marcação com i18n. Tenho alguma experiência com i18n para Wordpress e PHP. Lá usamos a abordagem __( 'text' to translate, 'text domain' ) para obter a tradução correta. Este __() também pode ser verificado pelo comando CLI que cria o arquivo de mensagem.

Este é um dos problemas que você se refere?

Uma coisa que notei com este bloco de marcação por exemplo (porque eu era preguiçoso e não queria adicionar i18n em cada subelemento):

<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>

que copia todo o bloco div no meu message.xlf.
Isso é muita poluição de marcação. (É claro que eu poderia usar i18n em cada tag que contém texto.)

Para este exemplo, usar o comando _e() funcionaria muito bem, eu acho. Você envolveria seu texto com o comando echo e todo esse texto embrulhado será coletado. Você pode se livrar de toda essa cópia de marcação no xml.
Se você precisar adicionar algo dinâmico a essa string, poderá canalizá-lo com espaços reservados na string (como faria com sprintf . Algo como

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

onde fruit é uma variável com valor __( 'apple') ou __( 'pear) .
Os 3 pedaços de texto acabariam no XML e podem ser traduzidos separadamente.

Isso serviria para alguma coisa? É bem parecido com a adição do atributo i18n, percebo depois de ler novamente :)

Finalmente, olhando para alguns dos formatos. XLIFF 2 parece muito bom, um pouco mais limpo que 1.2. O XMB parece uma documentação confusa e horrível que parece ter sido estilizada em 1995.
Percebi ao usar o XLIFF 2 que o texto TARGET não foi renderizado como na versão 1.2.

Vocês viram os arquivos .pot e .mo? Formato bastante simples e também usado por traduzido com a ferramenta POEdit.

eu preciso converter meu aplicativo em inglês e espanhol usando o botão de alternância. Fez todas as alterações, arquivo de trabalho separadamente. Eu criei duas compilações em .dist/en e dist/es. Alguém pode me dizer, o que eu preciso fazer para implantação e como alternar entre ambas as compilações?

O que eu preciso fazer ao clicar no botão de alternância

@shobhit12345 poste sua solicitação de assistência em https://stackoverflow.com

@zverbeta a solução que postei em #24549 não funciona quando construo com --prod . Meio óbvio já que estou usando require que provavelmente não está disponível?
Sem o sinalizador --prod, a solução funciona porque inclui código relacionado ao webpack?

@mattiLeBlanc Encontrei esta lib https://github.com/ngx-translate/i18n-polyfill e resolveu meu problema com texto dinâmico

Oi, como podemos traduzir valores dinâmicos (interpolação) usando 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>

Ei! Existe algum lugar onde possamos acompanhar e/ou ajudar nas tarefas que estão sendo trabalhadas? (os que estão trabalhando nela )

Alguma atualização em um prazo para o lançamento de uma versão beta do runtime i18n?

@marcelnem , não consigo encontrar o comentário, mas iirc ocombe mencionou que o tempo de execução i18n é mesclado para ivy, então você provavelmente pode testá-lo no v7 beta com a bandeira ivy

A parte do tempo de execução está concluída, mas não a parte do compilador, o que significa que você ainda não pode testá-la com o ivy

Olá, estou trabalhando com Angular 6 i18n. Estou trabalhando com vários idiomas, o que significa que segui o livro de receitas:
https://v2.angular.io/docs/ts/latest/cookbook/i18n.html#!

Minha implementação atual está usando AOT, então eu gerei um arquivo messages.xlf e um messages.pt.xlf. Tudo está funcionando bem, quando eu corro

ng serve --configuration=pt

Recebo textos traduzidos como esperado. Mas eu sinto que há algo muito errado com a maneira como ele funciona. Provavelmente estou perdendo alguma coisa. Pelo que entendi, toda vez que adiciono uma nova string a ser traduzida e a marco com o atributo i18n, preciso gerar novamente o arquivo messages.xlf rodando "ng xi18n" e depois atualizar manualmente o messages.pt.xlf. O arquivo xlf também contém o número da linha onde está a fonte, então parece que se eu alterar a linha, também precisarei gerar novamente o arquivo e atualizar manualmente meu arquivo pt.

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

Isso não parece inteligente, vai me dar muito trabalho extra para mantê-lo funcionando. Você entende minha preocupação? Estou esquecendo de algo?
Eu sei que o Angular 7 i18n terá uma grande atualização com a incorporação da Ivy, devo esperar por isso?

Cumprimentos,
Fábio

ps Eu realmente espero que isso não seja off-topic, mas se você acha que é, por favor me dê pelo menos uma direção. Onde eu deveria estar perguntando isso, por exemplo? Ou se houver um link que possa responder minhas dúvidas.

@fabiopcarvalho Uma coisa que percebi é que é aconselhável usar IDs personalizados para cada tradução para facilitar o acompanhamento das alterações no layout HTML.

Mas sim, você precisará atualizar rotineiramente o arquivo de traduções.

@fabiopcarvalho eu uso o xliffmerge para me ajudar na junção das traduções

Perfeito, eu usei essa ferramenta e funcionou muito bem. Eu também estou usando os ids e
eles ajudam.
Obrigado pela resposta !!

Na quinta-feira, 30 de agosto de 2018, Pedro Romero [email protected] escreveu:

@fabiopcarvalho https://github.com/fabiopcarvalho eu uso xliffmerge
https://github.com/martinroob/ngx-i18nsupport para me ajudar com a mesclagem
das traduções

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/angular/angular/issues/16477#issuecomment-417407822 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AWOWQ6vpjOb0Ntgpv7TUngRrBBsUIkVjks5uWCV7gaJpZM4NOSBk
.

Permitir mensagens ICU em atributos é fundamental para acessibilidade porque o atributo aria-label é muito usado em acessibilidade. Existe algum problema para acompanhamento?

Eu não acho que há um problema para isso, você poderia abrir um? Estou trabalhando em expressões ICU para ivy agora, então adicionei um TODO, mas uma solicitação de recurso seria melhor

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

Perfeito obrigado (a pesquisa do Github é muito ruim!)!

Seremos capazes de carregar lentamente os arquivos de tradução de uma fonte externa, por exemplo, via HTTP com a nova versão do i18n?

@ocombe como você disse que está trabalhando no Runtime i18n (um pacote para todas as localidades com AOT). já faz mais de um ano que estamos esperando. quando podemos esperar que esse recurso chegue na versão angular 7?

@Sef1995 é uma das coisas que queremos habilitar
@AhmadShahid exigirá o ivy, que será lançado independentemente da v7 e o ivy não estará pronto para o lançamento da v7. Algumas partes do ivy já estão na v6 por trás de um sinalizador, mas não é um recurso completo e você não deve usá-lo em um aplicativo do mundo real. Ainda não temos uma data de lançamento para Ivy.

@ocombe uma pergunta rápida, se implementarmos o i18n a partir de hoje (angular6), o que exigirá compilações diferentes (um para cada idioma), o esforço será perdido quando o ivy sair e o tempo de execução do i18n? Quero dizer, a maneira como o i18n seria implementado agora será diferente do que está por vir? Tentando planejar alguns sprints com antecedência e priorizar o trabalho. Obrigado

Não queremos criar mudanças de ruptura se pudermos evitá-las. Os ids das traduções extraídas podem mudar à medida que corrigimos bugs que temos há muito tempo, mas ofereceremos uma ferramenta de migração. Não posso dizer com certeza que será 100% compatível, mas espero que a maioria das coisas funcione da mesma forma, com novas opções disponíveis para uso, se você quiser.

@ocombe uma pergunta rápida, se implementarmos o i18n a partir de hoje (angular6), o que exigirá compilações diferentes (um para cada idioma), o esforço será perdido quando o ivy sair e o tempo de execução do i18n? Quero dizer, a maneira como o i18n seria implementado agora será diferente do que está por vir? Tentando planejar alguns sprints com antecedência e priorizar o trabalho. Obrigado

Oi, você pode usar o webpack require para carregar arquivos dinamicamente (como uma solução temporária) com uma compilação:
Exemplo pode ser encontrado aqui: https://github.com/angular/angular/issues/24549#issuecomment -402013622

Você tem que construir com --prod --aot=false, já que AOT=true removerá o material do webpack.

@ocombe Olá,

O release candidate A7 saiu, conforme prometido, vamos testar a tradução em tempo de execução?. Runtime i18n (one bundle for all locales with AOT) . Como posso testar isso. Por favor ajude

Obrigado

Eu apoio a pergunta do @sheikalthaf, embora a v7 já tenha sido lançada.

@sheikalthaf @Shuyinsama Como explicado alguns comentários acima e na primeira mensagem:
O tempo de execução i18n requer o ivy, que será lançado independentemente da v7. Algumas partes do ivy já estão na v7 atrás de um sinalizador, mas ele não está completo e você não deve usá-lo em um aplicativo do mundo real. Ainda não temos uma data de lançamento para Ivy.

@ocombe : Que tal passar a chave i18n dinâmica do componente pai para o filho.

Componente filho:
<div i18n="{{labelTextKey}}">{{labelText}}</div>

Componente pai:
<app-input [labelText]="'Second name'" [labelTextKey]="'@<strong i="13">@LabelSecondName</strong>'" ..></app-input>

Eu posso passar, mas como a tradução do i18n acontece em tempo de compilação, a variável está nesse estado ainda vazia. Então, portanto, nenhuma tradução ocorre.

Alguma atualização para esse caso?

@bobKasbi

você não precisa da tag i18n no componente filho, basta usá-la no pai assim:

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

@cjsase : funcionando muito bem. Muito obrigado! Estava lutando com quase 2 dias.

Com base nisso: https://github.com/angular/angular/issues/21706#issuecomment -430435254

• Não devemos esperar ivy na v7. A v8 está planejada para março/abril de 2019 . Se não devemos esperar o ivy na v7, existe uma recomendação/consenso sobre o que usar para internacionalização (i18n) até que o ivy seja lançado em abril de 2019?

Esta é uma informação incorreta. A equipe principal nunca disse que o IVy seria lançado em 2019. Em vez disso , a equipe principal disse (ênfase minha):

deve ser lançado em qualquer versão menor , sempre que for testado e validado

Digamos que eu tenha um aplicativo angular 7.1.0-beta.0 com ivy habilitado, é possível que eu tenha uma configuração com uma alteração dinâmica de idioma emitida pela frente sem atualização de página?

se sim como? este documento: https://github.com/angular/angular/blob/master/aio/content/guide/i18n.md
e este documento: https://angular.io/guide/i18n

não apresentam isso?

onde posso aprender como fazer um aplicativo i18n-angular moderno/futuro?

@tatsujb não, não é possível, e não será possível mesmo com ivy & runtime i18n. Você terá que recarregar seu aplicativo Angular se quiser alterar o idioma, por enquanto

ok, mas os documentos meio que se aplicam a uma versão quimérica de angular como 4 menos.

Eu não sinto que eles se aplicam à minha configuração nem cobrem exatamente como você faz a alteração entrar em vigor.

Estou assumindo que a mudança terá que ser imposta pelo back-end.

No meu caso, meu angular é servido no modo de produção por um backend java-spring. quais são as grandes linhas do que vai acontecer quando eu pressionar o ícone da bandeira para mudar o idioma?

Você leva o usuário para www.seudominio.com/cn/ onde tem todo o seu aplicativo Angular compilado em chinês. Você acaba com um aplicativo Angular compilado inteiro para todos os idiomas que deseja oferecer suporte.

@ocombe @santhony7 e isso: https://github.com/actra-development-oss/ng-i18n-aot-loader ?

eu poderia tentar isso?

é mal compatível com 7.1.0-beta.0 ou decentemente compatível?

@ocombe @santhony7 e isso: https://github.com/actra-development-oss/ng-i18n-aot-loader ?

eu poderia tentar isso?

é mal compatível com 7.1.0-beta.0 ou decentemente compatível?

Eu recomendo usar ngx-translate em vez disso. Eu usei os dois e o ngx-translate é muito mais fácil de manter.

@digismack outra diferença entre os dois, que é um pouco assustadora, é que o ngx-translate descarta todas as coisas oficiais do angular-i18n e não usa nada disso. é todo o seu próprio circuito independente e os arquivos json são muito menos específicos sobre as fontes das traduções.

também das duas demos ngx-translate parece muito mais lento, o que você quer dizer quando diz que era mais fácil de manter?

@tatsujb como desenvolvedor do th ng-i18n-aot-loader, sei que é bastante difícil de implementar, pelo menos integrando os carregadores.
Todo o resto é moleza, pois segue os paradigmas angulares originais do i18n.

Deve funcionar com a v7, desde que não haja alterações significativas nas estruturas de tags ou similares.

tentando implementar o ngx-translate estou tendo que ir traduzível por local traduzível. há centenas, é um pouco ridículo para mim não poder usar minhas tags i18n com as quais já havia planejado.

Estou começando a achar que confiar em você foi a escolha errada, @digismack

@tatsujb Existem 58 pessoas acompanhando esta edição. Pessoalmente, estou seguindo para atualizações da equipe Angular em relação ao i18n. Eu apreciaria se você interrompesse a conversa, a menos que esteja relacionado ao que o OP afirma:

Se você deseja que novos recursos do i18n sejam adicionados ao Angular, não hesite em perguntar abaixo e informarei se isso é viável e se você deve abrir um problema para isso.
Se você tiver um bug, abra um problema (não há necessidade de discutir sobre isso aqui).

Se você tiver problemas com outras bibliotecas, sugiro fazer uma pergunta no StackOverflow.

Não é meu hábito escrever/comentar assunto... mas vou!
Considerando :
@gtbuchanan e CO são do tipo A de pessoa.
@tatsujb e outras pessoas que reclamam/comentam/esperam coisas são do tipo B de pessoa

Tipo A você não está cansado de repetir sempre as mesmas coisas?!?! Para mim você é mais irritante que o tipo B.

devido a falta de recurso do i18n no angular Tipo B as pessoas ficam mais frustradas do que você que apenas "se inscreve" em um problema (se for para fazer amigos, ganhe alguns likes vá no facebook eu não sei, aqui não é lugar para isso , você não vai mudar de palavra ou inventar algo dizendo isso!...)

Acho que o tipo A pode cancelar a inscrição, aguardar a atualização, verificar o changelog rapidamente ou ler o blog / notícias, certifique-se de que a equipe angular o colocará em fonte grande ARIAL 72pixel que eles introduzem tradução dinâmica i18n de ts + tempo de execução i18n: grande recurso ausente em angular! eles não consideraram isso muito, então não temos o i18n correto hoje, isso é estratégia do google ou algo assim e isso não pode mudar!

Pessoas B esperam esse recurso há 2 anos, https://github.com/angular/angular/issues/9104#issue -159302131 sim desde angular 2.X !

Eu só quero dizer por favor respeite o tipo B frustrado e não seja mau. Se ninguém reclamar muito do i18n, acho que a melhoria do i18n não será considerada nos próximos anos, isso também é open source! reclamem críticos! estratégia pode mudar! então deixe as pessoas reclamarem, cancelar a inscrição, você é melhor que os outros, você pode encontrar suas informações sem se inscrever nesta edição!

Digite B, por favor, continue reclamando/comentando até que você possa! é a única melhor maneira de entender a necessidade das pessoas!

greve greve lol

@tatsujb Tudo se resume a preferência pessoal. Quando implementei ng-i18n-aot-loader pela última vez, tive que executar uma compilação ejetada e personalizar a configuração do webpack para que funcionasse. Talvez isso não seja mais o caso. No entanto, executar uma compilação ejetada significava que as ferramentas Angular CLI não eram mais utilizáveis. Então, achei mais fácil a longo prazo implementar ngx-translate e lidar com o fato de que funciona um pouco diferente.

@gtbuchanan Eu sinto sua dor, mas essa "conversa" está diretamente relacionada ao escopo dos recursos mencionados no post do OP. Como o prazo para Runtime i18n (one bundle for all locales with AOT) continuou a cair, as pessoas ainda estão acessando este tópico para procurar soluções atuais.

@ocombe , estamos prestes a iniciar um novo projeto agora, onde obteremos as traduções de um banco de dados.
Nossos módulos Angular serão carregados lentamente e também gostaríamos de ficar o mais próximo possível do que o Angular oferece em relação ao I18N.

Como o suporte Angular I18N não chegou à versão mais recente conforme planejado - você tem alguma recomendação para nós e outros que estão prestes a criar novos projetos agora?

Por exemplo, até que o I18N esteja pronto, poderíamos usar o ngx-translate, mas li em algum lugar nas questões do github desse projeto, que ele não suportará carregamento lento, o que seria uma rolha de exibição para nós.

Por outro lado, o suporte I18N do Angular ainda não está pronto para o horário nobre.

Eu realmente apreciaria algumas dicas nos apontando na direção certa sobre o que usar para o próximo projeto - ngx-translate vs ?

Deve ter:

• carregamento lento

Bom ter:

• Expressões de UTI

Merci

Para os seguidores desta edição, @ocombe falará sobre o tempo de execução i18n no angularconnect em algumas horas. Presumo que pelo menos algumas das perguntas em aberto serão respondidas lá. há uma transmissão ao vivo disponível

@ctaepper - muito obrigado pela informação!

@guygit isso pode ser ngx-translate ou angular-l10n . aqui está a tabela de comparação criada por mim https://medium.com/@sergeyfetiskin/tools -to-translate-your-angular-app-c021e25ff26a

para nossos aplicativos, decidimos seguir o caminho Angular, mesmo que tenha algumas limitações.

@fetis Muito obrigado - vou dar uma olhada :-)

Querendo saber sobre a escolha de arquivos XLIFF para os arquivos de tradução - o Google Translate Toolkit e o Flutter/Dart i18n suportam arquivos ARB e não suportam XLIFF. Ouvi dizer que o suporte a arquivos ARB não está planejado, mas me pergunto se isso é algo que pode ser considerado novamente. Ou se alguém ( @ocombe ?) pudesse apontar onde o Angular interage com os arquivos XLIFF para que eu possa ver o quão difícil seria integrar o suporte ARB.

(Para algum contexto, usaremos Flutter/Dart para nossos aplicativos móveis e Angular para nosso aplicativo web, e realmente gostaríamos de compartilhar nossos arquivos de tradução entre dispositivos móveis e web, se possível. Estou pensando em escrever um Conversor ARB -> XLIFF se não houver interesse em considerar sua inclusão no Angular.)

@localpcguy se você acabar escrevendo um tipo de conversor, você pode estar interessado em contribuir para https://github.com/translate/translate que já está oferecendo conversão de/para muitos formatos.

Em uma nota lateral, ocombe disse há alguns meses que ele se esforçaria para oferecer suporte a arquivos PO (e JSON?). Espero que isso aconteça em algum momento, porque tivemos dificuldade em encontrar ferramentas ockay-ish para trabalhar com o XLIFF.

porque tivemos dificuldade em encontrar ferramentas ockay-ish para trabalhar com o XLIFF.

@PowerKiKi isso simplesmente não é verdade. Quase todas as ferramentas de gerenciamento de tradução online suportam o formato XLIFF. E existem até programas de tradução de desktop gratuitos se você não quiser editar .xliff manualmente

@fetis Eu odeio sair do tópico, mas encontrei muita dor em relação ao uso do XLIFF com ferramentas. Veja meu comentário aqui: https://github.com/angular/angular/issues/20193#issuecomment -345755889

Por favor, forneça referências a essas ferramentas, porque ainda não encontramos nada de bom e ainda temos que encontrar algo que suporte XLIFF 2. Smart Cat parece bonito, mas atualizar strings nele me faz querer avaliar meus olhos.

Parece que você sabe algo que não sabemos :)

Pootle usa https://github.com/translate/translate e foi muito bom com Gettext (arquivos po), mas não suporta placeholders/tags e eles estão esperando uma contribuição de alguém para adicioná-lo

Eu assino esta edição por um longo ano ou assim. Parece que o progresso nesse sentido não é uma prioridade para a equipe Angular, e ter que compilar o aplicativo uma vez para cada idioma e passar por aros para fazer traduções dinâmicas não é aceitável. Eu recomendo, se você puder fazer isso, criar um pipe personalizado que use qualquer outra biblioteca i18n que você desejar. Sendo puro, esse pipe será igualmente eficiente para compilar o aplicativo várias vezes. Além disso, usando um i18n que não depende de Angular, você poderá fazer traduções dinâmicas de código de maneira trivial. Outra vantagem é que suas traduções não vão mais depender do Angular, então você pode começar a migrar alguns componentes para outros frameworks se desejar, ou ainda pode escolher o formato de tradução e ferramentas que preferir com total liberdade. Estou usando https://airbnb.io/polyglot.js/ e muito feliz com isso, e mesmo quando a migração do meu aplicativo do Angular i18n para o polyglot ainda está acontecendo, não posso estar mais feliz com o resultado e a remoção da dependência com Angular i18n.

Desculpem aqueles que vão receber isso como uma notificação no seu e-mail e não se importam com a minha opinião, mas como faz tanto tempo lendo suas notificações, sinto que tenho que dizer adeus antes de cancelar a inscrição :)

Saúde!

Parece que o progresso nesse sentido não é uma prioridade para a equipe Angular, e ter que compilar o aplicativo uma vez para cada idioma e passar por aros para fazer traduções dinâmicas não é aceitável.

O tempo de execução i18n é uma grande prioridade para a equipe Angular. No entanto, o bloqueio emite o novo renderizador Ivy. O progresso do projeto é bom até agora e provavelmente podemos esperar Ivy para Angular 8. Eu entendo que esta é uma situação difícil para todos os envolvidos. Existem planos, mas eles não podem ser implementados enquanto Ivy não estiver concluído.

Por favor, veja as palestras da recente conferência AngularConnect (2018) em Londres, especialmente "Runtime i18n" de Olivier Combe e a palestra do Dia 2 de Alex Rickabaugh.

De fato, minha experiência é semelhante à @intellix.

O XLIFF 1.2 tem 10 anos , mas o suporte para ele em projetos de código aberto parece ser bastante pobre. O Pootle não oferece suporte a titulares de palce de acordo com https://github.com/translate/pootle/issues/4762 e https://github.com/translate/pootle/issues/1811. Weblate também não os suporta , embora um PR possa adicionar suporte em breve .

Na área de trabalho, o Virtaal _não_ suporta espaços reservados XLIFF, mas a versão mais recente 0.7.1 tem 6 anos e não funciona mais no macOS mais recente pelo que ouvi. Infelizmente não dá a impressão de um projeto bem conservado, com alguns PR muito antigos que ainda estão esperando para serem fundidos apesar de sua aparente simplicidade. E uma atividade de commit muito baixa nos últimos anos .

Acabei de descobrir que o Poedit 2.2 lançado há alguns dias suporta XLIFF 1.2 e 2.0. Infelizmente, não posso testá-lo, pois recebo um erro do snapcraft.io CDN ao instalar no momento. Mas esta pode ser a melhor solução para usuários de desktop.

@fetis se você encontrou alguns projetos de código aberto (ou pelo menos de uso gratuito) para editar XLIFF 1.2, ou melhor ainda XLIFF 2.0, com suporte para espaços reservados, liste-os aqui. Todo o resto que testei não estava funcionando ou era extremamente complexo de usar.

@intellix @PowerKiKi aqui está a lista do que eu sei. Nosso alvo é uma plataforma de tradução online, onde podemos colaborar com tradutores/colegas de diferentes países. Passar pelo processo de instalação de software de desktop para cada colaborador e gerenciar a sincronização de arquivos XLIFF não é uma escolha para nós. Então, não testei ferramentas de desktop, mas sim plataformas.

Formulários
OmegaT
https://omegat.org/

Auto-hospedado
https://weblate.org/en/ +hospedagem paga
https://pootle.translatehouse.org/
https://pontoon.mozilla.org/

Plataformas
Crowdin
https://crowdin.com/
Suporte CLI

WebTranslateIt
https://webtranslateit.com/
Suporte CLI

Transifex
https://www.transifex.com/

PhraseApp
https://phraseapp.com/

Localizar
https://lokalise.co/
Suporte CLI

_Acho que terminaremos com o Lokalise para nossos projetos, pois fornece funcionalidade suficiente com preço acessível._

~Editor de PO~
https://poeditor.com/pricing/
O suporte declarado a XLIFF não funciona com o formato Angular

Se você está procurando uma solução de código aberto, esta lista pode ser útil https://opensource.com/article/17/6/open-source-localization-tools

Nós laterais
Não vi uma plataforma online que suporte XLIFF 2.0 e foi uma grande surpresa para mim. O XLIFF 1.2 está oficialmente marcado como obsoleto e ninguém na indústria deu suporte para a v2.

Feliz em saber que o POEdit declarou suporte a XLIFF, usei-o para arquivos .po e isso foi bom.

PS Lamento muito fazer um offtopic aqui, mas ao mesmo tempo obter o arquivo XLIFF do seu aplicativo é apenas parte da jornada, você precisa traduzi-lo e mantê-lo durante o ciclo de vida do aplicativo. Então é uma discussão importante. Sugiro mudar para algum lugar, posso colocar esta lista como um artigo do Medium e podemos manter a discussão lá.

@localpcguy existem muitos formatos, mas tudo se resume a quantos podemos suportar. Escrever e manter um serializador leva tempo. Xliff 2 foi adicionado como PR por outra pessoa, é por isso que adicionamos o suporte (caso contrário, não teríamos tido tempo para apoiá-lo).
Precisamos de um serializador para duas coisas: extração e mesclagem.
Eu não falei sobre isso no Angular Connect, mas minha esperança é que possamos usar um serializador externo. Deve ser muito fácil fazer isso em tempo de execução (merge) com ivy, mas a extração ainda é complicada porque o serializador precisa ser atualizado quando fazemos alterações no compilador.
Eu tenho algumas idéias sobre como fazer isso, mas vou ter que falar com a equipe sobre isso quando a hera pousar. O que eu realmente adoraria fazer seria pelo menos adicionar suporte a JSON para que eu possa reescrever ngx-translate usando Angular i18n (e porque muitas pessoas querem isso).

Obrigado @ocombe (e todas as outras entradas, gosto de ver as várias visualizações). Parece que #14185 foi o PR que você mencionou, ainda é um bom ponto de partida se eu quiser adicionar suporte ARB? Isso é algo que poderia ser mesclado se enviado?

@localpcguy , temos uma reunião amanhã onde discutiremos isso (e outras coisas), vou deixar você saber como foi

ok, então aqui está o que achamos que funcionaria: para a extração, vamos extrair strings em algum tipo de formato json (pode até ser ARB, já que é um formato json oficial para traduções) que qualquer um pode pegar e pós-processar para qualquer formato que você queira usar (json é realmente fácil de usar), e para o tempo de execução, forneceremos algum tipo de interface que você pode usar para escrever seu próprio carregador que entende seu formato.

Então, isso significa que somos livres para usar qualquer tipo de formato para traduções, desde que possamos fornecer um carregador para o aplicativo?

Bem, isso seria incrível :+1:

sim, você não teria acesso a otimizações profundas (substituir as strings em tempo de compilação para criar um pacote por idioma, o que significa que as traduções seriam divididas em código com seus componentes), mas você poderia usar qualquer tipo de solução de carregamento lento que desejar, contanto que você carregue todas as traduções quando o aplicativo for iniciado (elas precisam ser carregadas de forma síncrona antes que um componente seja criado)
você também pode, eventualmente, dividi-los manualmente e carregá-los com o roteador de forma assíncrona ao carregar um novo componente, isso depende de você, usando as novas funcionalidades de carregamento lento que a ivy fornece (Jason fez uma demonstração disso no Angular Connect)

podemos esperar uma demonstração beta (não arquivos apenas um vídeo ou transmissão ao vivo) de troca de idioma em tempo real no Ivy? tentar montar uma hera pré-final do POC pode ser uma ótima maneira de detectar as barragens da linha.

não que eu discorde da abordagem de esperar por uma hera de pedra mais firme antes de colocar o suor do desenvolvedor no live-i18n, acho que um POC em pequena escala de um homem é uma pequena quantidade de suor para um retorno imenso na forma de previsão e poderia potencialmente evitar que o live-i18n fosse empurrado para 2020.

O serviço de runtime para usuários externos ainda não está pronto, só temos o código que usa closure ( goog.getMsg ) porque era isso que precisávamos para testar o ivy com aplicativos do Google.
Eu vou estar trabalhando nisso agora para os próximos meses. Isso significa que você provavelmente ainda não pode usar i18n com ivy.
O código para o runtime i18n foi mesclado ontem, e o código do compilador para i18n deve ser mesclado nos próximos dias (estamos chegando lá!). Em seguida, trabalharemos no novo serviço para pessoas externas, incluindo os novos carregadores dos quais falei acima, e o serviço para usar traduções em seu código.

Quanto a mudar o idioma em tempo real, ainda exigiria uma recarga completa do aplicativo, ou talvez uma mudança de rota (que limparia todos os componentes existentes). Eu não tentaria trabalhar em um POC ainda.

Quanto a mudar o idioma em tempo real, ainda exigiria uma recarga completa do aplicativo, ou talvez uma mudança de rota (que limparia todos os componentes existentes). Eu não tentaria trabalhar em um POC ainda.

isso é justo, ... no entanto, não requer uma recarga completa do aplicativo (ou qualquer coisa que alcance a perfeição aos olhos do usuário final, AKA não perdendo loja, nem autenticação, nem url (bem ... não contabilizando /en/... ) e tudo dentro de um atraso razoável) ....ainda é o plano, certo?

@tatsujb Recarregar o aplicativo não é recarregar a página, o StackBlitz recarrega o aplicativo a cada edição, você sente que é observável aos seus olhos?

Recarregar o aplicativo significa desmontar o aplicativo e montá-lo na mesma posição, equivalente a uma transição SSR-CSR (é CSR-CSR), e não deve haver tarefas assíncronas no processo de inicialização subsequente se uma arquitetura de cache adequada estiver sendo considerada.

então com esta configuração correta; armazenar valores de variáveis ​​e autenticação (assim como a quantidade de rolagem em divs roláveis) permaneceriam?

@tatsujb Desde que sejam armazenados fora da instância criada pelo Angular, por exemplo, na variável léxica ou na propriedade da janela.

@trotyl Como você recarrega o aplicativo sem a página?

@saithis Você sempre inicializa o aplicativo por platformBootstrap().bootstrapModuleFactory() (ou outro equivalente) imperativamente, você pode chamá-lo a qualquer hora em qualquer lugar, não há mágica na chamada (exceto que o Angular CLI atualmente tem alguma limitação para substituição de código, não deve mais ser um problema em Ivy).

Bootstrap ansiosamente na hora da invocação do script e mantê-lo para sempre (não desmonte) é apenas uma prática comum para SPA, mas ninguém está forçando você a fazer isso.

EDIT: no caso de alguém fazer isso, também é necessário destruir o NgModuleRef inicializado para evitar vazamento de memória. Estas são questões fora do tópico e melhor serem discutidas em outro canal, melhor acompanhar a discussão do i18n aqui.

@trotyl Obrigado, eu não sabia que o bootstraping funciona novamente.

@ocombe você poderia por favor remover o spam aqui? e meu comentário também.

1. para @fetis : pessoas como você devem deixar de seguir o problema e se inscrever para o lançamento
   

2. para @Andrulko : não nos importamos

3. to @ angular : como disse eu entendo perfeitamente as reclamações aqui! como queríamos ivy para v7 e não para vX ou não vendesse grandes melhorias para v7 enquanto você não pudesse responder por isso ou colocaria em 7.x apenas para respeitar seu prazo... isso não é justo! sim, a opção deveria ser não anunciar nada e ninguém reclamará, isso também é uma má ideia, você precisa fazer o seu lugar na estrutura. sim, esperamos i18n correto desde a v2, neste aspecto obrigatório para big app você não poderia vender angular pronto para big app como internacional webapp que contém 50000strings, é claro que você certamente não gosta de ler isso, mas é sem compaixão e com bom fé, imho, se não considerarmos o i18n e o tempo de compilação / desenvolvimento lento para todos os outros aspectos, posso dizer que o angular é incrível. certa direção deve mudar no topo, estou falando com os decisores, é claro. alta exceção de nós (que criticam) porque do big-google não poderíamos cometer grandes erros como este. eu vejo os desenvolvedores do google como excepcionais - pessoas inteligentes sem erro, essas coisas não deveriam acontecer para desenvolvedores experientes e para devteam como o google! minha opinião global não vende angular 100% para grandes aplicativos quando a empresa o escolhe, então venda / explique à empresa privada o que é código aberto!

4. @ tudo especialmente para quem não trabalha em empresa de negócios: não gosto do meu comentário porque eu certamente não respeito open source?!?!, lol vai dizer isso ao meu chefe para esperar.. esperar... depois de escolher angular porque acreditamos está pronto (100% não 80%) para grandes aplicações... dependemos!

este é o meu último comentário aqui porque saímos do navio! cancelar inscrição + não escolher angular no meu próximo projeto (você poderia dizer que você é o vencedor, o projeto de código aberto não precisa de pessoas como nós)

Tanta paixão! Apenas para equilibrar... reescrevemos nosso aplicativo em Angular 6, internacionalizado em 6 idiomas, e sentimos apenas pequenos inconvenientes. Claro, tempos de construção mais rápidos e traduções em tempo real certamente seriam bons, mas não o fim do mundo para nós. Os 98% do framework que não é i18n é incrível. Ótimo trabalho caras! Ansioso para novos recursos.

Também temos uma experiência fantástica com o Angular para nosso novo portal corporativo. O i18n é o último recurso que falta, pois, na Suíça, temos que suportar quatro idiomas. Acho que o problema aqui é com a comunicação. Para o planejamento do projeto, se tivéssemos uma estimativa melhor do lançamento do i18 há um ano, poderíamos ter planejado e considerado outras possibilidades. Dito isto, estamos ansiosos para ouvir quaisquer atualizações. :-)

Em defesa do angular, você pode usá-lo de maneira simples em produção assim (melhor solução que encontrei)

1. Envolva o texto da variável traduzida no próprio componente para mover a lógica de tradução para algum lugar

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. Configure pastas de configuração de compilação em angular.json como

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

1. Configure o arquivo de compilação do docker como este para compilar o aplicativo para diferentes idiomas

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. Use este nginx.conf para servir o aplicativo em subdomínios (como en.site-name.com, ru.site-name.com), onde ru em set $subdomain ru; deve ser substituído por sua localidade padrão

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;
  }
}

Para mais detalhes veja aqui
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

Gostaria de um polegar para cima para este comentário. Pode não ser perfeito, mas ainda é o post mais útil sobre este tópico que encontrei na web

Olá a todos,

Estou usando traduções i18n para meu projeto. Tenho dúvidas na seguinte área:

1. É possível gerar diferentes arquivos de origem xlf para diferentes bibliotecas (criadas usando o comando ng generate library libraryName)?
2. Ao usar a internacionalização para select ou pluralization , o arquivo de origem xlf gerado cria o ID trans-unit para as diferentes alternativas. É possível fornecer um id via template para diferentes alternativas também? (conforme mostrado na imagem abaixo)
   

Por favor, você pode me ajudar com algumas respostas.

@learnersLicense :

1. Você deve ser capaz de extrair um arquivo de tradução por projeto que o cli manipula. Dito isto, as traduções não funcionam com bibliotecas no momento (o que significa que alguém que consome sua biblioteca não poderá carregar suas traduções para essa biblioteca). Está no topo da nossa lista de tarefas para os próximos recursos que implementaremos (com traduções de código)

1. Não acho que seja possível. Você pode nomear espaços reservados com comentários especiais: <div i18n>Some value: {{ valueA // i18n(ph="PH_A") }}</div> mas não acho que funcione com expressões ICU, @AndrewKushnir ?
   Você pode fazer uma solicitação de recurso para isso ou talvez adicionar um comentário a https://github.com/angular/angular/issues/24080 que parece ser semelhante (adicione desc / meaning às expressões ICU)

alguém que consome sua biblioteca não poderá carregar suas traduções para essa biblioteca

Uma maneira de contornar isso é:
1) extraia a biblioteca i18n para xliff e traduza
2) enviar arquivos xliff com pacote de biblioteca

3) o consumidor também extrai seus próprios arquivos xliff
4) o consumidor carrega o xliff no analisador xml. descarta todas as unidades trans que se originam de node_modules
5) o consumidor concatena seu xliff com a biblioteca xliff

o que significa que alguém que consome sua biblioteca não poderá carregar suas traduções para essa biblioteca

Talvez eu esteja entendendo mal essa afirmação, mas sei que com a configuração de traduções para os aplicativos da minha empresa quando crio meus arquivos xlf eles incluem chaves especificadas nos modelos de outros projetos. Um que vem à mente é https://github.com/ng-bootstrap/ng-bootstrap

Isso não parece possível no momento:

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

Dentro do escopo dessas mudanças, isso será resolvido (ou estou fazendo algo errado)?

@mikejr83

Isso é possível. Você só precisa atribuir o valor base de title como title="Go" e não [title]="'Go'"

obrigado @ocombe e @ewok-janitor por suas respostas e sugestões. 👍

@ocombe existe alguma data provisória de quando as traduções para a biblioteca podem estar disponíveis?

Sem data por enquanto. Para a primeira versão do ivy, estamos apenas tentando ter paridade de recursos. Trabalharemos nos novos recursos (incluindo traduções de código e suporte a bibliotecas) logo em seguida (ou, na verdade, começaremos a trabalhar neles antes, mas não serão concluídos quando o ivy for lançado em alfa). Ele estará disponível antes que o ivy se torne o padrão.

Já existe uma correção para os arquivos xliff? https://github.com/angular/angular/issues/17506
É impossível usar o formato enquanto as referências não forem fixas.

@ocombe Algum plano para oferecer suporte a traduções de rotas?

já foi solicitado algumas vezes sim, não é um plano imediato mas está na lista de coisas a fazer

Oi, existe alguma documentação sobre como usar o runtime i18n quando o ivy é lançado na versão beta?

@marcelnem , se você verificar esta URL, todos os pontos de documentação estão pendentes.

https://is-angular-ivy-ready.firebaseapp.com/#/status

@ocombe ótimo trabalho que você está fazendo no Google agora. Angular i18n deveria ter sido 'algo' como ngx-translate desde o início. Eu queria saber se haverá um guia de migração, ferramenta automatizada, comparação de recursos... para migrar do estilo ngx-translate para o Angular i18n assim que o Angular 8/9 for lançado?

oi ocombe
Preciso verificar com você sobre este recurso, o que você declarou acima
Runtime i18n (um pacote para todas as localidades com AOT) - [trabalhando nele] >> Isso ainda está em andamento ou está fora

Você poderia me informar, qualquer solução alternativa, se ainda está em andamento
Obrigado

@ocombe você escreveu acima que os pacotes de idiomas devem ser carregados por lacy loading. Também será possível carregar os pacotes de idiomas diretamente no index.html? Porque temos o caso em que nosso aplicativo é executado no AWS Lambda e os arquivos angulares compilados são armazenados em um bucket do S3. Na verdade, já é uma solução alternativa que isso funcione, mas não podemos usar o carregamento laçado porque o Angular não pode carregar os arquivos de outro host. Portanto, todos os arquivos que o Angular precisa já devem estar incluídos no index.html (onde adicionamos o host S3 por meio de um script).

@nidhi8953 ainda é WIP, estará disponível com ivy, por enquanto só funciona dentro do google (porque usamos o Closure Compiler internamente para as traduções). O serviço de tempo de execução que lidará com as traduções é muito experimental para o mundo exterior. Se você quiser testar algumas coisas, veja este exemplo: https://github.com/angular/angular/blob/master/packages/core/test/bundling/hello_world_i18n/index.ts mas você deve saber disso as funções ainda são privadas por um motivo, elas serão renomeadas e alteradas em um futuro muito próximo. O objetivo atual é começar a trabalhar em um conjunto sólido de APIs assim que a v8 for lançada (no final do mês) e iterar em torno disso por toda a v8 até a v9, ponto em que a API deve ser considerada estável

@vekunz se seguirmos nossos planos atuais, deve ser possível sim, já que você precisa ter o arquivo de tradução carregado no bootstrap do seu aplicativo de qualquer maneira

@ocombe Podemos usar Ivy (atualmente 8.0.0-rc.3) e implementar i18n usando o método Angular 7 de várias compilações? Ou preciso ficar com o Angular 7 até que as APIs i18n para Ivy sejam lançadas? Se possível, eu adoraria tirar proveito do Ivy e, ao mesmo tempo, usar a maneira antiga de i18n até que o novo método de tempo de execução esteja disponível.

Atualização: Depois de experimentar, nem a extração de ng xi18n (consulte #https://github.com/angular/angular-cli/issues/14225) nem a construção com i18n surtem efeito. Nenhum arquivo .xlf é exportado e nenhuma palavra é traduzida. Mas com a opção enableIvy definida como false em tsconfig.app.json, ambos funcionam muito bem com a versão 8.0.0-rc.3. Isso significa que posso seguir o caminho de atualização do Angular, não perder o i18n, obter alguns dos novos benefícios, como carregamento diferencial, e estar pronto para ativar o Ivy assim que o i18n funcionar.

@jacobbowdoin , como você descobriu, não funciona com ivy, mas funciona se não estiver ativado.
Eu queria fazer o antigo sistema de extração/carregamento funcionar com o ivy, mas como seria apenas temporário, não foi determinado como prioridade pela equipe (o que é compreensível, fazer as coisas obrigatórias funcionarem primeiro é a prioridade).

Oi @ocombe , queremos desenvolver o i18n agora, então não podemos esperar pelo runtime-i18n. Você ainda recomendaria usar ngx-translate? Faz sentido usá-lo com i18n-polyfill? O uso do i18n-polyfill facilitará a migração para o runtime-i18n?

Se você usar ngx-translate, não use i18n-polyfill. Só faz sentido usá-lo se você usar o angular i18n para os modelos.
ngx-translate ainda é relevante e fácil de usar. Você não precisa colocar toda a infraestrutura no local para dar suporte a várias compilações (uma por localidade).

Oi @ocombe , existe alguma atualização de status no:

-Tempo de execução i18n
-Use strings de tradução fora de um template - #11405

No momento, estamos debatendo se devemos esperar pelas traduções do código-fonte ou usar o i18n-polyfill (já começamos com o i18n). Podemos facilmente esperar algumas semanas, então um cronograma aproximado seria apreciado. Muito obrigado!

@halilovicedvin assim que o ivy for o padrão nos aplicativos do Google, começaremos a trabalhar no serviço i18n de tempo de execução para usuários externos, então em algum lugar entre breve e v9
Eu não contaria com isso até depois do verão porque as pessoas vão tirar alguns dias de folga

@halilovicedvin começamos com i18n com i18n-polyfill algumas semanas atrás e funciona muito bem. Espero que o runtime-i18n seja usado da mesma maneira que o i18n-polyfill

@vekunz Eu também esperava que, se usarmos ngx-translate com i18n-polyfill , poderemos migrar mais facilmente para o runtime-i18n, mas após o comentário de @ocombe ( https://github.com/angular/angular/issues /16477#issuecomment-498239301) Não tenho certeza se o esforço adicional para configurar o polyfill é justificado. Talvez usemos apenas ngx-translate sozinho.

@vekunz qual é a sua experiência em configurá-lo?

@marcelnem você não pode usar ngx-translate com i18n-polyfill. i18n-polyfill é apenas para uso com angular-i18n.

A configuração do i18n-polyfill foi realmente muito fácil. Mesmo a documentação não está exatamente correta, descobri muito rápido o que mudar.

@vekunz eu entendo agora, obrigado. Não tenho certeza de qual é o objetivo do i18n-polyfill. Você ainda precisa compilar o aplicativo várias vezes e implantá-lo várias vezes em http://myapp/en , http://myapp/de , http://myapp/fr ,... como com o angular i18n oficial?

@marcelnem sim, você também precisa de várias compilações com i18n-polyfill. O objetivo é que, com o angular-i18n, você possa usar traduções atualmente apenas dentro de modelos html e não dentro do seu código datilografado. i18n-polyfill estende o angular-i18n para usar traduções dentro do seu código datilografado também.
Com o Angular 9 (chegando no outono), o angular-i18n também suportará traduções dentro do texto datilografado, mas enquanto isso precisamos do i18n-polyfill para isso.

@vekunz você pode detalhar um pouco mais sobre isso: "Mesmo a documentação não está exatamente correta, descobri muito rápido o que mudar". Eu provavelmente estou olhando para i18n-polyfill na próxima semana, então qualquer informação seria apreciada. THX

@halilovicedvin @marcelnem Criei um documento pastebin onde descrevo, porque não é o tópico principal deste problema do GitHub https://pastebin.com/Xib6X6E9

@ocombe Usando a ferramenta xi18n, posso restringir o caminho de entrada apenas para a pasta src (para gerar as traduções) em vez de todo o projeto/repositório?

@ocombe o Ivy suporta várias localidades com Angular 8 (apenas a definição de localidade, não o arquivo de idioma; por exemplo, para pipes de data)? Porque uma outra equipe usa Angular atualmente com ngx-translate, mas um componente de terceiros precisa da localidade correta. Uma opção seria usar o compilador JIT no modo prod, mas isso não é muito bom. Mas também eles não podem compilar um novo pacote para cada idioma, porque isso seria demais.

@vekunz não, você não pode definir várias localidades, você precisa definir a localidade para cada pacote compilado (pode ser definido no arquivo de configuração cli)
Eu sei que não é o que você queria ouvir, mas por enquanto é assim

@ocombe Você pode dizer algo, eu sei que a equipe do Angular não identifica isso como um problema, mas você acha que o Angular nos permitirá em um futuro próximo alterar o idioma em tempo de execução sem recarregar o aplicativo, então ter a tradução em um único pacote e ter a possibilidade de carregar as traduções certas e vinculá-las aos literais do texto?

Ter um bundle sim, mas as traduções terão que ser carregadas no boostrap (quando o app carregar). Com a arquitetura existente seria muito complicado recarregar as traduções "a quente" sem recarregar os componentes que já usam as traduções.
Não estou dizendo que isso é impossível, mas infelizmente não vejo isso acontecendo no futuro próximo.

Obrigado @ocombe pela resposta rápida :) Continue com o bom trabalho :+1:

Houve em algum lugar uma apresentação do @ocombe de alguma conferência angular (acho que AngularConnect) onde ele falou sobre i18n e Ivy, e lá ele descreveu muito bem, por que isso é tão complicado. Posso tentar encontrar o vídeo.

Acho que encontrei https://www.youtube.com/watch?v=miG-ghJhFPc

Para as pessoas que esperam pelo tempo de execução i18n com ivy, o plano atual para v9 é ter traduções trabalhando com ivy, mas apenas como uma etapa de construção (como está agora com o mecanismo de visualização). Isso significa que ainda será 1 build/locale por enquanto, e não haverá traduções de código (apenas traduções de template).

Desapontamento. Bem, pelo que vale a pena, obrigado pelo seu trabalho duro!

@ocombe você ainda manterá o polyfill para traduções de código em tempo de execução?

se quebrar sim, não vou adicionar coisas novas a ele

É meio chato que i18n tenha sido um cidadão de 2ª classe por tanto tempo... Nem todo mundo trabalha em um ambiente de idioma nativo inglês. ):

Bem, eu concordo, estou tentando encontrar algumas empresas para me patrocinar para que eu possa desenvolver novas e poderosas soluções i18n para Angular (tenho muitas idéias).
Se você pensar em pessoas que estariam interessadas, me avise no Twitter (@ocombe) ou por e-mail ([email protected]) 🙂

@ocombe eu gostaria de agradecer pelo seu trabalho também. 💚 É uma notícia um pouco surpreendente que você tenha que deixar o time. Como você disse I had to ... , isso me orienta a perguntar diretamente qual foi o principal motivo. Eu odeio essas dicas indiretas e suposições, então é por isso que uma pergunta tão direta para você.

Eu era um contratado externo trabalhando com a equipe Angular e não um funcionário em tempo integral do Google e, como tal, meu contrato pode terminar a qualquer momento, dependendo do que a equipe precisa.
Eles estão recrutando novas pessoas internamente para ajudar no projeto e estou confiante de que eles encontrarão as pessoas certas para ajudar com i18n e outros tópicos, então você não precisa se preocupar com o futuro do Angular :visage_légèrement_souriant: é apenas um revés temporário

@ocombe Obrigado pela sua explicação.

Alguém pode me dizer como posso usar i18n (i18n-polyfill) fora da classe como enums ou const arrays ou algo como arquivos .model.ts?

Para constantes, eu ainda as coloco em uma classe. Não conheço nenhuma alternativa :/

@ocombe Muito obrigado por todo o seu trabalho duro com i18n para Angular com ngx-translate, i18npolyfill e com a equipe Angular.
Usamos seu trabalho diariamente para fornecer traduções aos nossos usuários, conforme exigido por qualquer aplicativo não trivial.
Boa sorte no que você fizer daqui para frente.

Para constantes, eu ainda as coloco em uma classe. Não conheço nenhuma alternativa :/

Hmm.. se eu movê-los para a classe, então eu preciso tornar a variável como estática para ser usada. Mas não posso usar i18n para uma variável estática.

classe de exportação Exemplo {
construtor (i18n privado: I18n) {}
variável estática = i18n('texto'); // Não posso usar i18n aqui, pois não é estático da classe Exemplo
}

Triste notícia... isso "enfraquece" o Angular... Como os outros dizem, resta apenas o grande agradecimento ao @ocombe pelo ótimo trabalho, boa sorte!

Estou curioso, quais são as desvantagens de usar ngx-translate? Parece que é capaz exatamente da funcionalidade que as pessoas procuram

Eu diria que as desvantagens são as seguintes:

• aumenta o tamanho do pacote (lib externa + traduções como arquivos externos em vez de substituir o código em tempo de compilação)
• não oficial (se eu morrer, a lib será descontinuada e não o mesmo nível de suporte)
• não suporta xliff/xmb (mas suporta json e outros formatos através de plugins, e pode-se fazer um plugin xliff/xmb para suportá-lo)
• pode ter alguns comportamentos de bugs ao carregar / dividir as traduções com preguiça (nunca consegui consertar isso)
• a sintaxe é mais complicada em comparação com a implementação oficial
• desempenho (carregamento inicial das traduções pode fazer o texto desaparecer por 1s, e mais pressão de memória porque tenho que monitorar o conteúdo em tempo de execução para ver se algo mudou)

Dito isto, parece ser bom o suficiente para muitas pessoas 🙂

É curioso como o angular promove e investe em acessibilidade, mas não inclui idiomas nesse pacote. Realmente parece que esta é uma decisão tomada a partir de um ambiente monolíngue.

Vindo de um ambiente onde normalmente temos que servir 3-4 idiomas de forma intercambiável, tenho esperado pacientemente o lançamento deste recurso desde seu anúncio com suas claras vantagens sobre o uso de uma biblioteca externa. Com esta notícia, terei que reconsiderar completamente nossa estratégia de gerenciamento de traduções.

@ocombe Sem chance de que o Google não o contrate como contratado?😉

@DmitryEfimenko Estamos usando o ngx-translate atualmente e estamos muito felizes com isso.

@ocombe qual é a chance de o Google aceitar esse recurso de um desenvolvedor/comunidade externo? Acho que estamos esperando demais.

se você é sério com isso e quer gastar tempo trabalhando nisso, então eu diria que as chances são altas de que eles aceitem ajuda para trabalhar nesse recurso

se você é sério com isso e quer gastar tempo trabalhando nisso, então eu diria que as chances são altas de que eles aceitem ajuda para trabalhar nesse recurso

@ocombe @IgorMinar Eu gostaria de fornecer algum trabalho voluntário para Ivy i18n, por favor me avise se houver algumas chances.

se você é sério com isso e quer gastar tempo trabalhando nisso, então eu diria que as chances são altas de que eles aceitem ajuda para trabalhar nesse recurso

Estou disposto a contribuir, mas não conheço absolutamente o escopo e a complexidade das tarefas. Podemos considerar a lista na mensagem original como nossa especificação/requisitos?

Não, esta lista agora está obsoleta.
Avisarei à equipe que vocês dois estão interessados ​​para que possamos ver como organizar isso.

@ocombe acho que somos mais de 2.

O que precisamos das equipes Angular são

• uma lista de requisitos/alguma especificação
• estimativa aproximada de complexidade
• 1-2 mentores para comunicação

com essa comunidade poderia organizar o desenvolvimento e dividir tarefas

Há o que estou ciente em https://hackmd.io/UfFN_wyVT-Ob1p70nA3N_Q?view

@fetis Pode não ser uma boa ideia dividir muito o trabalho, a comunicação e o compartilhamento de contexto também custam muito, especialmente para alguns trabalhos principais com alta chance de conflitos.

Ainda surpreso, o XLIFF é listado como um profissional (ou melhor, a falta dele para o ngx-translate é um contra). O Google Translate e outros serviços do Google parecem estar usando arquivos ARB, que é uma representação JSON de strings de tradução. Por exemplo, construímos nossos aplicativos móveis com Flutter/Dart, onde o INTL é implementado com arquivos ARB. Seria bom se a equipe do Angular, ao analisar isso, levasse isso em consideração para uma melhor interoperabilidade com outros itens no ecossistema do Google.

Pode não ser uma boa ideia dividir muito o trabalho, a comunicação e o compartilhamento de contexto também custam muito, especialmente para alguns trabalhos centrais com alta chance de conflitos.

Concordo, mas não acho que tudo isso possa ser entregue por uma pessoa em um tempo razoável. O escopo é muito grande

Pode não ser uma boa ideia dividir muito o trabalho, a comunicação e o compartilhamento de contexto também custam muito, especialmente para alguns trabalhos centrais com alta chance de conflitos.

Concordo, mas não acho que tudo isso possa ser entregue por uma pessoa em um tempo razoável. O escopo é muito grande

@fetis eu posso trabalhar com você. Nós realmente queremos usar o angular i18n em nossos projetos, mas é muito limitado.

Avisarei à equipe que vocês dois estão interessados ​​para que possamos ver como organizar isso.

@ocombe algum feedback da equipe Angular?

Eu os avisei e eles pareciam interessados, mas eles precisam apresentar um plano concreto para tudo isso antes de poderem aceitar ajuda externa (caso contrário, você provavelmente não trabalhará no que é necessário).
@petebacondarwin assumirá a partir de agora

Oi @ocombe , eu estava analisando os comentários e entendi aproximadamente que ainda não há provisão para criar IDs dinâmicos para a tag i18n enquanto os usamos em *ngFor. Existe alguma outra opção ou solução alternativa? Ou eu tenho que ir apenas com ngx-translate.

@swapnilvaidankar Eu não acho que exista uma solução alternativa, não

@swapnilvaidankar - você pode explicar o que quer dizer com isso?

crie IDs dinâmicos para a tag i18n enquanto os usamos em *ngFor

Como sabemos, para traduzir o texto estático para qualquer outro idioma, temos que usar o atributo i18n na tag do elemento HTML como abaixo,

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

que gera o trecho de arquivo xlf como abaixo e podemos definir o destino para qualquer idioma. Aqui eu traduzi para o francês como abaixo,

  <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>

Mas no caso da lista suspensa, parece difícil usar o atributo i18n.
Por exemplo, se eu quiser mostrar a lista de produtos como cartão de visita, folhetos e folhetos na lista suspensa ou lista simples, como posso gerar o id dinâmico para otag, portanto, posso traduzir os nomes dos produtos para francês ou qualquer outro idioma.

ja tentei assim,

• 
  {{ produtos }}
  

que gera o snippet de arquivo xlf como abaixo e não tenho certeza de como usá-lo para traduzir o nome do produto para outros idiomas usandomarcação

  <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>

O problema aqui, se você pode ver o id emtag é apenas 'produto'. No entanto, eu esperava que os ids fossem gerados dinamicamente, de acordo com a lista de produtos que estarão disponíveis na lista suspensa.

Não tenho certeza de como conseguir isso sempre que lidar com conteúdo dinâmico ou lista de conteúdo.

Desculpe a extensa explicação.
Espero que você tenha entendido a questão aqui.

Obrigado,
Swapnil

Você pode abrir um problema para isso, por favor? Não é realmente o tópico aqui e se mais alguém estiver procurando a mesma coisa, será mais fácil encontrá-lo

Os atributos @swapnilvaidankar i18n destinam-se à tradução de texto estático, não ao conteúdo dinâmico. No seu exemplo, os "produtos" são provenientes de seu código-fonte (são definidos em seu arquivo ts) e você precisa usar ngx-translate (ou ter nomes de produtos traduzidos diretamente no arquivo ts) ou são provenientes de uma solicitação Http em seguida, os nomes de produtos traduzidos devem ser fornecidos pelo seu back-end.

Eu não acho que precisamos de um novo problema para isso. É apenas solicitar traduções em tempo de execução em arquivos TS que já foram solicitados várias vezes.

@swapnilvaidankar se o número de opções for limitado e você já souber, você pode criar um componente com ngSwitch simples que renderiza o texto. Usamos essa solução alternativa, funciona como um encanto.

@fetis - o problema é que é muito fácil que essas questões gerais sejam desviadas para discussões sobre coisas específicas. Criar um novo problema fornece um novo tópico para continuar essa discussão sem distrair este.

@fetis Sim, esse problema eu já vi muitas vezes em muitos lugares, mas não encontrei nenhuma solução adequada. Também me deparei com o ngSwitch, mas não uma solução adequada no meu caso. No entanto, obrigado pela solução alternativa.

@ocombe Acredito que preciso postar isso como um problema em algum outro lugar para discutir o mesmo e não aqui. 👍

Obrigado a todos pelas respostas.

@petebacondarwin @swapnilvaidankar aqui está o problema https://github.com/angular/angular/issues/11405 que você está procurando
desde 2.0.0-rc.6 (!) btw

Olá @ocombe , este problema ainda está atualizado? Parece que Ivy será o padrão no Angular 9, então eu me pergunto qual é o status do i18n? Você poderia por favor estimar quando poderia estar pronto para produção? Com Angular 9, 10, 11? Se não for com o Angular 9, o Angular 9 (e o Ivy) serão enviados sem i18n ou usarão o antigo i18n?

Algumas informações adicionais sobre o estado atual podem ser encontradas nesta questão (https://github.com/angular/angular/issues/11405). Comentários que vale a pena ler nesta edição sobre o estado atual:

• 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

Também vale a pena conferir isso .

Embora estejamos mudando a opção na v9 para que o padrão seja usar o ivy, esperamos que haja vários cenários que não estejam funcionando totalmente e que esses projetos permaneçam com o mecanismo de visualização por enquanto.
Estamos trabalhando para colocar o i18n em funcionamento para a versão v9.0.0, mas será apertado.

Qual status atual em "Runtime i18n (um pacote para todas as localidades)"?

@Ivajkin - desculpe que este problema não esteja sendo atualizado.

"Runtime i18n" é um recurso comumente solicitado, mas pode significar coisas diferentes para pessoas diferentes.
Na nova abordagem i18n $localize , será possível fazer a tradução real em tempo de execução.

O tempo de execução pode ser bastante complicado se você não estiver apenas traduzindo todas as mensagens possíveis antes da inicialização do aplicativo Angular. Se você estiver fazendo isso, a nova abordagem para a tradução de tempo de compilação pode ser o que você precisa.

No novo i18n, a tradução acontece no final do pipeline de compilação - não no compilador Angular - isso significa que você deve poder fornecer mensagens não traduzidas em bibliotecas etc. e só fazer a tradução quando compilar o aplicativo final.

Isso tudo está em andamento para a v9.0.0.

Confira https://github.com/angular/angular/tree/master/packages/localize para ver onde estamos.

@petebacondarwin Você se importaria de elaborar um pouco sobre a nova tradução em tempo de compilação? Isso nos permitirá construir um único pacote (com AOT) que funcione para todas as localidades?

Na nova abordagem, em vez de fazer a tradução dentro do compilador Angular, nós simplesmente "marcamos" as mensagens que precisam ser traduzidas por meio de um manipulador de tags de string global $localize templated . Essas strings marcadas sobrevivem a todos os tipos de agrupamento e minificação, de modo que, no final do pipeline de construção, elas ainda estão lá e podem ser descobertas. Esses arquivos podem ser o pacote de sua biblioteca que você envia para alguma outra equipe para incluir em seu aplicativo!

Agora temos algumas opções:

a) execute uma ferramenta que identifique estaticamente essas mensagens marcadas e as substitua por traduções. Isso remove efetivamente as referências $localize do JavaScript e deixa você com um pacote de código mínimo para distribuição. Essa ferramenta de "compile time inlining" pode fazer várias traduções e gerar uma cópia do seu pacote para cada idioma que você está traduzindo. Como ele pode ser executado no final do pipeline de compilação, evita a execução de outros aspectos de sua compilação para todos os idiomas suportados.

b) permitir que as tags $localize acabem no código que é executado no navegador e usar uma implementação de $localize para traduzir as mensagens em tempo de execução. A desvantagem dessa abordagem é que a carga útil para o navegador é maior, pois deve conter as chamadas $localize , mas também a implementação de tradução $localize . Além disso, você deve enviar as próprias traduções para o navegador. Um benefício dessa abordagem pode ser o suporte ao carregamento lento de traduções em tempo de execução. Mas é discutível que fazer a tradução no servidor http (ou servidor de compilação) torna a experiência de tempo de execução mais eficiente.

Opção de tempo de execução b) por favor. Poderíamos carregar traduções como arquivos JSON e alternar idiomas em tempo de execução, como fazemos atualmente com ngx-translate .

Obrigada pelo esclarecimento. Eu entendo que a abordagem a) é mais "Angular", mas a grande vantagem da abordagem b) (e carregamento lento em geral) também é a capacidade de definir / alterar traduções dinamicamente pelos usuários (traduções modificadas para aplicativos podem ser usadas imediatamente) . Se entendi corretamente, qualquer pequena mudança na tradução na abordagem a) significaria uma nova reconstrução.

Esta é a mesma vantagem que mudar de páginas geradas estaticamente com componentes Angular predefinidos para templates gerados pelo usuário contém os componentes angulares definidos pelo programador conforme desejado pelo usuário (o template definido desta forma também seria carregado do banco de dados... )

Você também pode ter pensado na possibilidade de que, por padrão, a abordagem a) seria usada ao carregar. Se surgir uma solicitação de tradução em tempo de execução (por exemplo, o back-end começará a enviar traduções mais recentes), os blocos marcados (contendo texto estático até agora) começarão a ser rastreados e substituídos dinamicamente, como na abordagem b). Então b) só seria ativado se necessário e todas as partes traduzíveis serão preparadas de acordo com o procedimento a). Entendo que tal abordagem seria mais onerosa do que a abordagem b) em si e certamente não é diretamente viável dessa maneira, mas estaria mais próxima das necessidades reais dos usuários.

Para as opções que você listou, estou disposto a sacrificar cerca de 25% do desempenho do aplicativo em certos casos para obter essa funcionalidade dinâmica (é claro que não usaria essa abordagem dinâmica em todos os lugares). Portanto, se o modelo localizado do AOT fosse renderizado em 0,4 segundo, no caso de um modelo dinâmico, se ele fosse gerado em 0,5 segundo, eu ainda o consideraria aceitável em aplicativos em que preciso de respostas imediatas à mudança de tradução.

@demisx ambas as abordagens estarão disponíveis com a v9, mas apenas a opção a) será totalmente suportada no início (para retrocompatibilidade), novas coisas podem ser desenvolvidas para a opção b) antes de ser totalmente endossada pela equipe Angular.
Minha biblioteca Locl fornecerá alguns ajudantes para a opção b) quando a v9 for lançada para que qualquer pessoa possa usá-la, até que a equipe Angular preencha essa lacuna

Esteja ciente de que essa tradução em tempo de execução não seria "reativa" no sentido de que uma vez que um componente fosse renderizado, não seria possível alterar seu texto dinamicamente, mesmo que uma nova tradução fosse carregada.

As mensagens traduzidas são estáticas em relação às strings marcadas $localize . Portanto, o componente precisaria ser renderizado novamente. E dependendo do cache de templates no IVY pode ser que uma nova renderização não seja suficiente.

Essa é uma das razões pelas quais a tradução em tempo de execução é difícil de implementar, pois seu comportamento não seria necessariamente intuitivo.

Em relação à abordagem híbrida de começar com uma tradução estática na compilação e adicionar a tradução em tempo de execução posteriormente. Isso poderia ser viável se o tempo de compilação embutido não removesse as tags $localize , mas apenas atualizasse as partes literais de string modeladas. No entanto, isso resultaria no custo do tempo de compilação mais o custo extra do tamanho do pacote.

A execução de ng xi18n no Angular 9 RC1 retorna "Lamentamos, mas o i18n ainda não está implementado no Ivy", mas o log de alterações indica que há _some_ i18n suporte implementado agora. Presumo que os arquivos de tradução precisam ser atualizados manualmente por enquanto?

@neil-119 Atualmente, a extração não é suportada no modo ivy. Você ainda precisa desabilitar o ivy para executar a extração. Mas então você pode reativá-lo para consumir os arquivos de tradução extraídos.

Espero que esteja planejado incluir a extração na versão final da v9.

@neil-119 Angular CLI deve usar automaticamente o VE para extração. Você não precisa fazer nada para que isso funcione. Também testamos isso, então estou surpreso que esteja quebrado. Você pode abrir um problema com um repro por favor?

Atualmente a extração não é suportada no modo ivy.

ou não, é uma rolha de show. Atualmente, temos um processo automatizado com extração de strings. Como podemos migrar para Ivy, se não podemos extrair traduções automaticamente?
Manipular sconfig.json every time ? Isso não soa bem para mim.

@fetis - eu estava incorreto. Se você estiver usando a CLI, chamar ng xi18n deve funcionar conforme o esperado, mesmo quando o ivy estiver ativado.

@petebacondarwin obrigado. Vou experimentar Ivy em nossos projetos atuais, então espero confirmar isso em breve

Olá, tentei usar no meu componente (angular 9.0.0-rc.1)

$localize `some string to localize`;

encontrado como doc no código-fonte de @angular/localize/init.

Quando tento construir como de costume para o meu idioma, recebo este erro
No translation found for "4145296873012977836" ("some string to localize").

Como posso fornecer uma tradução para essa string?
O que eu espero é que ng xi18n gere o arquivo .xlf com também este texto do código do componente. Está certo ou está faltando alguma coisa?

Oi @ Ks89 - a extração de mensagens do código do aplicativo (em vez de modelos) não é compatível com a v9.
Mas você pode contornar isso se for sorrateiro. O 4145296873012977836 é o id da mensagem, portanto, se você fornecer uma tradução em seu arquivo de tradução com esse ID, ele será usado na tradução.

@petebacondarwin quando esse recurso será adicionado ao Angular?
Eu acho que é realmente importante tornar as traduções de tempo de execução em componentes realmente úteis.

Quando envio meu arquivo .xlf para um tradutor, espero adicionar todas as strings rapidamente e aplicar o resultado ao aplicativo com muita facilidade.

obrigado pela resposta

Eu esperaria isso em 9.1

Se tivermos uma maneira de forçar a renderização de todo o aplicativo, não importa o que ChangeDetectionStrategy seja para cada componente, será muito fácil resolver esses problemas dinâmicos.

@petebacondarwin Angular 9 agora é lançado com a nova função de tag $localize, mas sem extração das mensagens. Você disse antes que poderíamos esperar isso no Angular 9.1. Essa previsão ainda é válida e podemos esperar que a API $localize fique estável?

Você pode extrair traduções de modelos.
Se você quiser usar $localize no seu código também, dê uma olhada no Locl: https://github.com/loclapp/locl/
@locl/cli permitirá que você extraia de código e modelos

@vekunz - a previsão ainda é válida. Além disso, como @ocombe aponta, o mecanismo de extração de tradução CLI atual funciona muito bem para qualquer tradução que esteja dentro de um modelo Angular (ou seja, coisas marcadas pelas tags i18n ). A única coisa que você não pode extrair usando as ferramentas principais agora são chamadas para $localize dentro de seu próprio código (por exemplo, em um serviço ou componente).

A própria chamada $localize é uma API estável.

As ferramentas que fazem traduções e extração (especificamente em tempo de compilação) ainda não são públicas. Mas isso não é uma preocupação, a menos que você esteja planejando construir suas próprias ferramentas em torno disso (como @ocombe está fazendo no Locl!).

Obrigado @petebacondarwin , com isso, conseguimos duplicar os textos do código em um template de componente "oculto" para extração. Então a extração e a tradução devem funcionar, não é?

@ocombe Com a previsão de que a extração funcione com Angular 9.1, nosso gerente não pagaria pela sua solução. Especialmente porque não precisamos de troca de idiomas ao vivo e rotas traduzidas.

poderíamos duplicar os textos do código em um modelo de componente "oculto" para extração

Sim, de fato, essa solução alternativa funcionaria por enquanto.

Estou confuso: a tradução em tempo de execução também será possível em 9.1? Ou apenas a extração fora dos modelos? Ou nenhum desses?

Para mim, as traduções em tempo de execução seriam um recurso matador. Para implantar vários pacotes e forçar o usuário a recarregar a página inteira não é uma boa usabilidade, eu acho.

@JustDoItSascha
Eu criei uma demonstração simples, que demonstra a tradução em tempo de execução.
https://stackblitz.com/edit/ivy-vjqzd9?file=src%2Fapp%2Fapp.component.ts

Oi! Estou tentando chamar loadTranslations em main.ts porque as strings são traduzidas enquanto o JavaScript analisa as importações, mas isso não é suficiente.

main.ts importa AppModule que importa AppComponent (onde estou usando $localize ).

Para fazer funcionar estou fazendo:

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

Agora isso funciona, mas faz com que o pacote "complier.js" do Angular seja incluído no pacote do fornecedor.

Alguma forma de evitar isso? Obrigado

Atualmente, loadTranslations precisa ser chamado antes do início do aplicativo, para que possa ser feito em polyfills.ts . E se você quiser carregar outro conjunto de traduções, precisará recarregar a página. Se você quiser entender um pouco mais o porquê, escrevi https://blog.ninja-squad.com/2019/12/10/angular-localize/ para explicá-lo.

Atualmente, loadTranslations precisa ser chamado antes do início do aplicativo, para que possa ser feito em polyfills.ts .

É ainda pior que isso, ele precisa ser chamado antes de qualquer arquivo de módulo ser importado, por isso funciona se você colocá-lo em polyfills.ts (que é executado antes do arquivo principal do aplicativo), mas se você quiser usá-lo em seu "main" então você precisa usar um import(...) dinâmico para o módulo

@vekunz é um bom motivo para não usar minha lib por enquanto 😊 dito isso Locl não é apenas sobre extração, pretendo adicionar muitas outras ferramentas para simplificar o i18n

Existe alguma intenção de implementar o runtime i18n em Angular alguma vez? Estamos esperando o recurso há quase três anos e agora Ivy está aqui e ainda está apenas pela metade.

Existe alguma intenção de implementar o runtime i18n em Angular alguma vez? Estamos esperando o recurso há quase três anos e agora Ivy está aqui e ainda está apenas pela metade.

Meu entendimento é que Ivy, de muitas maneiras, é um facilitador para as coisas que estão por vir. Não é de surpreender que a agulha i18n tenha se movido incrivelmente com o lançamento de Ivy, mas deve liberar o potencial para grandes mudanças no futuro. Essa tem sido a minha leitura dele, e minha esperança, de qualquer maneira.

@Karasuni - Acho que precisamos esclarecer o que a tradução de tempo de execução realmente significa para a estrutura principal do Angular, porque há um pouco de confusão sobre isso.

As alterações que fizemos para a v9 envolvem a tradução baseada $localize . O objetivo principal disso era desacoplar a tradução do compilador Angular, para permitir várias melhorias interessantes:

A primeira delas, que está imediatamente disponível para todos os usuários da v9, é acelerar a geração de aplicativos traduzidos. Anteriormente, todo o pipeline de compilação precisava ser executado para cada idioma para o qual você desejava traduzir seu aplicativo. Agora, a compilação principal do seu aplicativo só precisa ser executada uma vez e o processo de tradução final, que é significativamente mais curto, é executado para cada idioma na saída da compilação. Para suportar isso, há o novo pacote @angular/localize , mudanças dentro do compilador Angular e uma carga de trabalho dentro da CLI Angular para tornar isso o mais transparente e transparente possível

Em segundo lugar, como as tags $localize podem ser deixadas no código distribuído, agora também é possível fazer a tradução no navegador (em tempo de execução, em vez de em tempo de compilação). Isso é o que queremos dizer na estrutura principal do Angular como tradução de tempo de execução. Mas, por favor, não que o resultado final disso seja efetivamente o mesmo que a tradução em tempo de compilação. A tradução acontece apenas uma vez; se você deseja alterar o idioma em tempo de execução, deve reiniciar todo o aplicativo (por exemplo, por meio de um recarregamento). Isso tem a vantagem de permitir que o projeto implante um único distribuível com vários arquivos de tradução, o que é útil em um pequeno número de casos de uso em que você não deseja gerar todas as traduções diferentes antecipadamente. Existem alguns problemas complicados ao carregar as traduções com antecedência suficiente, conforme apontado por @ocombe e outros aqui. Você pode considerar https://www.locl.app/ para obter mais ajuda com isso.

Observe que essa tradução de "tempo de execução" também pode ser usada em rotas carregadas lentamente, portanto, pode ser viável ter rotas diferentes em idiomas diferentes, dependendo de como você configura as coisas.

Como não há uma única abordagem para esse carregamento de traduções que funcione para todos os cenários, ainda não incluímos isso na CLI ou fornecemos APIs públicas estáveis ​​para oferecer suporte a isso. Assim que entendermos melhor os casos de uso, poderemos adicionar mais suporte para isso. Enquanto isso, coisas como Locl podem ajudar se você não quiser se aventurar a descobrir por si mesmo.

Por fim, observe que a alteração dinâmica de strings traduzidas em tempo de execução não é especificamente suportada (por design) pela estrutura principal do Angular. Conectar as strings traduzidas ao sistema de detecção de alterações do Angular colocaria muita pressão na maioria dos aplicativos e arruinaria o desempenho. Das minhas interações com a comunidade, quase não vi nenhum cenário do mundo real em que isso seja realmente necessário além de reiniciar o aplicativo na mudança de idioma. Se este for um requisito para o seu aplicativo, você poderá alcançá-lo usando um pipe personalizado em suas strings em modelos que extraem traduções e talvez até chame $localize em tempo real para traduzir, mas não parece isso seria muito performático. Caso contrário, você pode considerar uma abordagem mais dinâmica como https://netbasal.gitbook.io/transloco/.

As principais mudanças que virão na próxima versão menor do Angular serão a extração de tradução aprimorada, que será capaz de identificar e extrair strings localizadas do código TS - atualmente a extração CLI lida apenas com strings localizadas em templates.

As alterações para melhorar a tradução do tempo de execução, conforme descrito acima, não apareceriam até depois do 9.1, no mínimo.

Por fim, observe que a alteração dinâmica de strings traduzidas em tempo de execução não é especificamente suportada (por design) pela estrutura principal do Angular. Conectar as strings traduzidas ao sistema de detecção de alterações do Angular colocaria muita pressão na maioria dos aplicativos e arruinaria o desempenho. Das minhas interações com a comunidade, quase não vi nenhum cenário do mundo real em que isso seja realmente necessário além de reiniciar o aplicativo na mudança de idioma.

Posso estar enganado, mas apenas neste tópico muitas pessoas demonstraram expressamente interesse na capacidade de alterar o idioma ao vivo, em tempo de execução, sem precisar reconstruir ou recarregar o aplicativo. Ou todos aqui têm uma definição diferente de runtime translation ?

Eu não quero recarregar um aplicativo apenas para mudar um idioma. Por exemplo, quando um usuário está em uma página com um formulário, um recarregamento de página inteira para uma mudança na tradução será chocante para o usuário.

Só para ficar claro. O que eu quis dizer é que muitas pessoas vieram até mim para dizer que precisam absolutamente de uma mudança de linguagem ao vivo em seu aplicativo. Mas quando você investiga as razões, verifica-se que não. Não estou dizendo que não há cenários que exijam isso, mas na minha experiência no ano passado, encontrei muito poucos.

Pergunta: por que um usuário precisaria trocar de idioma ao acessar um formulário específico em seu aplicativo?

Eu não acho que a comutação ao vivo também seja necessária. Com que frequência você altera o idioma de um site? Geralmente uma vez, no máximo. E desta vez, um recarregamento de página não é tão crítico. Como @petebacondarwin disse, quase todos os cenários para comutação ao vivo não são cenários relevantes do mundo real, mas apenas "bom de se ter".

Ou todos aqui têm uma definição diferente de tradução em tempo de execução?

Eu absolutamente preciso de traduções em tempo de execução. Nossos clientes precisam ser capazes de editar e atualizar traduções em campo, não apenas no servidor de compilação. Então, tempo de execução, em oposição ao tempo de compilação.

A troca real de idiomas após o carregamento da página é agradável.

Só para ficar claro. O que eu quis dizer é que muitas pessoas vieram até mim para dizer que precisam absolutamente de uma mudança de linguagem ao vivo em seu aplicativo. Mas quando você investiga as razões, verifica-se que não. Não estou dizendo que não há cenários que exijam isso, mas na minha experiência no ano passado, encontrei muito poucos.

Pergunta: por que um usuário precisaria trocar de idioma ao acessar um formulário específico em seu aplicativo?

Você pode estar certo de que não é um requisito sólido. Eu posso tentar implantar traduções no carregamento, mas isso transformará completamente a experiência do usuário dos aplicativos que atualmente podem alternar o idioma dinamicamente - sem recarregar ou alterar a posição na página - com uma biblioteca externa. Traduções tem sido um tema acalorado por muito tempo.

Eu tenho uma pergunta importante: os arquivos de tradução podem ser carregados de forma assíncrona? Todas as minhas traduções são armazenadas em um banco de dados, pois é importante poder atualizá-las sem uma reconstrução.

sim, eles podem ser carregados de forma assíncrona, mas você precisa atrasar o início do seu aplicativo até que eles sejam carregados

Só para ficar claro. O que eu quis dizer é que muitas pessoas vieram até mim para dizer que precisam absolutamente de uma mudança de linguagem ao vivo em seu aplicativo. Mas quando você investiga as razões, verifica-se que não. Não estou dizendo que não há cenários que exijam isso, mas na minha experiência no ano passado, encontrei muito poucos.
Pergunta: por que um usuário precisaria trocar de idioma ao acessar um formulário específico em seu aplicativo?

Você pode estar certo de que não é um requisito sólido. Eu posso tentar implantar traduções no carregamento, mas isso transformará completamente a experiência do usuário dos aplicativos que atualmente podem alternar o idioma dinamicamente - sem recarregar ou alterar a posição na página - com uma biblioteca externa. Traduções tem sido um tema acalorado por muito tempo.

Tecnicamente, você pode recarregar o aplicativo inteiro e ainda manter o usuário onde ele estava.
Você "só" precisa ter um aplicativo controlado por estado (com ngxs, ngrx ou qualquer outra biblioteca de gerenciamento de estado) que seja armazenado em algum lugar e recuperado na inicialização.

O único truque seria manter a posição de rolagem, mas isso também é viável.

@petebacondarwin Devo dizer que concordo com você. Não conheço usuários finais reais (exceto testadores na fase de desenvolvimento) que estão alternando um aplicativo permanentemente entre idiomas ao usá-lo. Claro, eles provavelmente fazem isso no começo se abrirem em outro de alguma forma, mas depois, é um caso raro.

Ou todos aqui têm uma definição diferente de tradução em tempo de execução?

Eu absolutamente preciso de traduções em tempo de execução. Nossos clientes precisam ser capazes de editar e atualizar traduções em campo, não apenas no servidor de compilação. Então, tempo de execução, em oposição ao tempo de compilação.

A troca real de idiomas após o carregamento da página é agradável.

Não tenho certeza do que seus clientes estão fazendo, mas "edição de traduções ao vivo no site de produção" não parece um cenário comum.

Não vejo a mudança de idioma ao vivo (_sem recarregamento de página_) para ser um disjuntor tão grande.
A alteração de um idioma para um usuário ocorre apenas uma vez;

Pense nisso, quantas vezes você mudou o idioma do seu telefone? provavelmente uma vez ou você acabou de rolar com o idioma padrão.

Observar as alterações de idioma para fazer alterações ao vivo sem recarregar a página traz muitas penalidades de desempenho para algo que mal é usado durante a vida útil de um usuário.

Em última análise, se resume a 3 coisas para mim;

1. Extraia traduções de modelos e arquivos TS.
   
   
   
   • Atualize o recurso de idioma de origem.
   
   
   • Atualize a tradução também (_se eu tiver vários idiomas, fr, en, de... quero que todos sejam atualizados com as novas chaves de tradução e as removidas._)
   
   
2. Uma compilação para todas as traduções (_Ter 1 compilação para cada tradução também é bom, desde que não multiplique o tempo de compilação._)
3. Obtendo idiomas disponíveis e altere o idioma com recarga.

@Karasuni
Você pode buscar traduções assíncronas e só então carregar o aplicativo angular.
Veja meu comentário acima sobre como carregar o app.module assíncrono usando import(...) .

pessoalmente, uso a Wikipédia para descobrir para que título de um filme que sei foi "traduzido" em outro idioma.

nos dias de hoje, ser bilíngue ou trilíngue é mais do que comum (além de dentro dos EUA, nenhum dano significa).

o usuário pode querer mudar de idioma ao vivo, é completamente plausível. o exemplo da Wikipedia é um resultado positivo de ter permitido isso, não vejo por que devemos sufocar outros usos potenciais antes que eles vivam para ver a luz do dia sob o pretexto de desempenho.

mesmo o ngx-translate do ocombe, que deve ser o exemplo equivalente para vocês de "traduções de baixo desempenho", funcionou perfeitamente rápido o suficiente para o usuário comum.

Eu pessoalmente sou trilíngue e não consigo me contentar em usar um idioma: todos os idiomas são bonitos para mim

com tudo o que disse, não posso concordar com isso:

Pense nisso, quantas vezes você mudou o idioma do seu telefone? provavelmente uma vez ou você acabou de rolar com o idioma padrão.

A Wikipedia é o pior exemplo disso porque os diferentes idiomas de um artigo são, na verdade, artigos independentes. Normalmente você não precisa de idiomas diferentes para o mesmo site. Mesmo que você trabalhe quadrilíngue.
E se você realmente precisar de comutação ao vivo, poderá usar a solução alternativa com o canal de tradução personalizado, mencionado por @petebacondarwin ou a nova ferramenta de @ocombe.

OK, então eu não acho que este seja realmente o melhor lugar para ter essa discussão. Estou preocupado que (embora todos tenham sido muito razoáveis ​​até agora) possamos cair em uma discussão negativa. Receio que, no futuro próximo, a estrutura Angular não forneça uma solução de troca de idioma ao vivo pronta para uso.

Sinto que o valor desta questão se esgotou. Movi os problemas abertos e os PRs vinculados na descrição deste problema para https://github.com/angular/angular/milestone/101 e vou fechar e bloquear este PR.

Se você tiver novos problemas de solicitações de recursos, abra um novo problema e me marque nele.