Como devo arquitetar suporte a vários idiomas para um grupo de aplicativos?

5

Eu tenho cerca de 8 aplicativos da web (todos eles baseados em ASP.NET), e quero implementar suporte a vários idiomas para todos eles e ter uma arquitetura que eu possa usar em novos aplicativos da web no futuro. Também gostaria de tentar centralizar a parte administrativa (onde todas as traduções de texto e outros recursos específicos de idioma residem), você conhece alguma ferramenta ou padrão de arquitetura que possa ser útil nesse caso?

A única solução robusta em que consigo pensar é ter um aplicativo da Web que gerencia os recursos de suporte a idiomas e todos os outros aplicativos da web se conectam a esse aplicativo / serviço centralizado, mas receio que essa solução tenha um impacto no desempenho em todos os aplicativos, se não for implementado da maneira correta.

Eu apreciaria muito qualquer sugestão.

    
por tivo 02.05.2012 / 15:27
fonte

1 resposta

1

Você pode começar definindo muitas coisas.

Defina como identificar a cultura na sua API (ISO-639, LS-2012, ...)

Essa opção mudará a maneira de armazenar recursos e acessá-los. Além disso, decida como recorrer a regiões e culturas neutras. Algumas linguagens têm uma maneira muito específica de alternar entre diferentes culturas, alguns livros oferecem uma ótima visão.

Como você está indo ASP.NET para a escolha é simples.

Defina como armazenar cada tipo de dados (strings, imagens, moedas ...)

Você terá que considerar diferentes formas de acesso. Você quer ficar móvel e usar arquivos simples? Ou você pode manter um banco de dados em um único lugar para lidar com tudo?

A centralização pode se tornar um problema se os clientes e consultores tiverem que lidar com a tradução. Usar uma solução baseada em arquivo de texto entra facilmente na revisão do controle de origem, fornecendo a boa ferramenta portátil e as bibliotecas é ótimo, mas não é fácil para quem não é especialista em tecnologia.

Defina os formatos de acesso para todos os tipos de aplicativos

  • precisa exportar para uma tecnologia específica (.resx, .po, .lang, xliff ...)?
  • precisa de acesso aleatório de um aplicativo de servidor por meio de um serviço (web)?
  • precisa de um acesso unitário para fazer a tradução?

Em todos os casos, a capacidade de exportar traduções em um formato bem conhecido possibilitará o uso de serviços de tradução. Você precisará então mesclar novas traduções com as existentes.

Defina como lidar com moedas

Isso é mais uma preocupação de código com a qual sua API não terá que lidar totalmente. Mas as regras de configuração para todos os desenvolvedores são boas.

Finalmente , certifique-se de que a API que você criará possa ser portada para quantos idiomas / tecnologias forem necessários. Usar formatos padrão será uma escolha essencial por causa das bibliotecas existentes (gettext, xliff) e ferramentas.

Não se esqueça de lidar com formulários no plural (sem itens, um item, itens x) e comentários de tradução (informações contextuais para cada recurso) que resolverão muitos problemas.

Escreva tudo o que você decidiu em um documento compartilhado para garantir que todos entendam o porquê e como. Se você está escrevendo uma API, a documentação é ... importante.

    
por 04.05.2012 / 22:26
fonte