Por que os recursos de cadeia geralmente são mantidos externos ao código e não dentro do código?

18

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?

cross-platform resources internationalization

— Léon Pelletier
fonte

possível duplicação da internacionalização: o que pensar?

— mosquito

6

Não, minhas preocupações não são sobre internacionalização, e sim sobre arquitetura e multiplataforma, desculpe.

— Léon Pelletier

1

Essa questão pode ser generalizada para qualquer tipo de recurso, realmente, mesmo com a facilidade de localização / internacionalização de lado. Quais são as vantagens de manter qualquer tipo de recurso separado do código? Por que as imagens ou arquivos de áudio geralmente não são codificados na fonte como cadeias binárias? (Os URIs de dados existem, é claro, mas geralmente são impraticáveis para arquivos grandes). Outros já forneceram respostas muito boas, mas eu só queria salientar que as seqüências legíveis pelo usuário não são o único tipo de recurso que obtém um benefício ao ser externalizado.

— JAB

38

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

— catraca arrepiante
fonte

Esse relink vs recompilar é um bom motivo, obrigado.

— Léon Pelletier

2

Ainda a única pessoa que entendeu a pergunta.

— Léon Pelletier

3

@ratchetfreak é uma má forma de aceitar muito cedo (dentro de algumas horas definitivamente conta). Não dá tempo para outras respostas aparecerem. Isso é simples, direto ao ponto e preciso ... mas alguém pode oferecer uma resposta melhor, mais completa e mais detalhada amanhã (ou no próximo mês).

— WernerCD

3

Extra: Pode ser ok para um tradutor para editar um arquivo XML, mas não nunca deixá-los mexer código real perto ...

— Darkhogg

Agora a pergunta é: "Essa resposta ainda se aplica a idiomas interpretados?". Eu pergunto porque não haveria religação ou recompilação.

— Thomas Eding 14/03

10

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

— Flo
fonte

2

Bem, não há diferença entre um arquivo que está incluído no projeto e um arquivo de recurso. O problema não está aí.

— Léon Pelletier

Estou falando de incluir os recursos diretamente no código e, em seguida, lidar com tudo dentro do programa, para que ele seja mais compatível com PCL / entre plataformas.

— Léon Pelletier

2

se você tem um arquivo de "código" com todos os seus recursos de cadeia de caracteres (definição de dicionário ou algo assim) e nada mais .. bem, basicamente, é um arquivo de recurso (mas um para uma única plataforma, como por exemplo: android não pegue qualquer código objetivo-c). Se houver outro código nele ou se estiver dividido em vários arquivos, é mais difícil obter tradução externa. Em uma exibição de plataforma cruzada, um formato de texto como xml tem a vantagem de poder ler e usar em qualquer idioma / plataforma (mas você pode precisar trabalhar um pouco)

— Flo

7

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-out messages.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.

— Monty Harder
fonte

0

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

— Rene Saarsoo
fonte