Geralmente, em muitas plataformas, estou gravando meus recursos de string em um arquivo .resx ou .xml e, em seguida, obtendo-os usando alguma abordagem dependente da plataforma.
Ou seja, no iOS, eu as estou conseguindo via NSBundle.MainBundlee usando Context.Resourcesno Android.
Quais são as vantagens dessa abordagem e por que não tê-la diretamente acessível no código, por exemplo:
Em um projeto de plataforma cruzada, qualquer plataforma pode acessá-lo diretamente, sem integração.
Durante a construção, não há preocupações sobre se os recursos foram construídos ou não.
- O codificador pode usar funcionalidades como manipulação multilíngue
Longa história: qual é a razão pela qual os recursos de string são estruturados dessa maneira?
[Editar]
Digamos que meu arquivo faça parte de um projeto "básico" compartilhado entre outros projetos. (Pense em uma estrutura de arquivo de projeto de plataforma cruzada PCL.)
E suponha que meu arquivo seja totalmente semelhante a um arquivo .resx / .xml, parecido com este (eu não sou profissional em xml, desculpe!): Parameters Paramètres
Portanto, este é basicamente um xml personalizado, no qual você aponta para a chave / idioma para obter a string correta.
O arquivo faria parte do aplicativo, assim como você adiciona qualquer arquivo acessível dentro de um aplicativo e o sistema para acessar os recursos da string, codificados usando PCL. Isso adicionaria uma sobrecarga aos aplicativos?
fonte
Respostas:
Localização e internacionalização,
Manter as strings externas permite que elas mudem (leia-se: traduzidas) sem a necessidade de recompilar (apenas um relink no máximo e apenas inserir uma nova pasta na melhor das hipóteses).
fonte
Se você tiver um arquivo que contenha apenas os recursos de sequência, poderá entregá-lo a uma agência de tradução ou algo parecido e obter uma tradução. Eu acho que você pode imaginar o quão difícil isso poderia ficar se você tivesse que fornecer muitos arquivos de código a um leigo para fazer alguma tradução (além de talvez não querer fornecer seu código a quem quer que seja).
fonte
Além da internacionalização / localização, a separação de cadeias de texto como essa também permite que um revisor envie correções de ortografia / gramática / pontuação isoladas
messages.${LOCALE}, sem precisar tocar em um arquivo de código-fonte verdadeiro. Você pode ter um blecaute nas alterações de código, mas aceita essas correções de texto. Se você estiver aceitando alterações simultâneas no código e nas mensagens, mantê-las separadas facilita a mesclagem dos patches, desde que as alterações no código não redefinam nenhuma mensagem existente quando o revisor fez check-outmessages.en_US.Além disso, dependendo de como é implementado, pode nem ser necessário vincular novamente o aplicativo. O código pode simplesmente pegar a linha 138 de
messages.${LOCALE}uma mensagem específica, com o número da linha sendo determinado no tempo de execução.fonte
É exatamente assim que seu idioma / plataforma decidiu implementar a localização de strings. Todas as abordagens de localização precisam de algum tipo de arquivo de recurso externo para obter as traduções. O principal ponto problemático é como você mantém esses recursos.
Parece que você precisa manter esses arquivos de recursos manualmente , o que pode ser um fardo. Também complica o compartilhamento de seqüências repetidas. E ter que fazer isso quando você está enviando apenas um idioma no momento é um fardo ainda mais difícil.
Uma alternativa comum é a abordagem GNU Gettext de apenas marcar as seqüências traduzíveis no código-fonte e extrair automaticamente essas sequências para arquivos PO padrão, que funcionam muito bem em várias plataformas e idiomas. Do ponto de vista do desenvolvedor, ele supera a manutenção manual de arquivos de recursos XML a qualquer dia.
fonte