Como organizar recursos de cadeia de localização?

Estamos desenvolvendo um aplicativo grande, composto por muitos pacotes pequenos. Cada pacote possui seu próprio conjunto de arquivos de recursos para localização.

Qual é a melhor abordagem para organizar e nomear as cadeias de localização?

Aqui estão os meus pensamentos até agora:

Manipulação de duplicatas

O mesmo texto (por exemplo, "CEP") pode ocorrer várias vezes em um determinado pacote. O instinto de programação (DRY) diz-me para criar um recurso de cadeia única compartilhado por todas as ocorrências .

Por outro lado, um tradutor pode querer escolher uma tradução longa ("Postleitzahl") em alguns lugares e outra mais curta ("PLZ") em lugares com menos espaço. Ou podemos decidir anexar dois pontos a algumas ocorrências ("CEP:"), mas não a outras. Ou podemos exigir uma capitalização diferente ("código postal") em alguns lugares. Todos esses argumentos apontam para a criação de um recurso por uso, mesmo que seu conteúdo seja idêntico .

Nomeação

Se pretendemos eliminar duplicatas, faz sentido nomear recursos por conteúdo , talvez sugerindo o tipo de uso via prefixo. Portanto, podemos ter labelOK= "OK" , messageFileTooLarge= "O arquivo excede o tamanho máximo do arquivo." e labelZipCode= "CEP" .

A nomeação por conteúdo tem a vantagem de manipular argumentos de formato naturalmente: O recurso messageFileHas_0_MBWhileMaximumIs_1_MBclaramente usa dois argumentos de formatação, o tamanho real do arquivo e o tamanho máximo do arquivo.

Se permitirmos duplicatas, no entanto, nomear somente pelo conteúdo não faz sentido. Para obter nomes de recursos exclusivos, devemos, de alguma forma, incluir o local de uso no nome do recurso. Isso funciona para controles gráficos, embora os identificadores tendam a demorar um pouco: fileSelectionConfirmationButtonText= "OK" , customerDetailsTableColumnZipCode= "CEP" . No entanto, para arquivos de código não visuais, fica mais difícil. Como você nomeia um uso específico de uma string se não sabe onde ela será exibida? Por arquivo de código e nome da função? Parece um pouco desajeitado e quebradiço para mim.

Em suma, estou inclinado a permitir duplicatas, mas estou lutando para encontrar um esquema de nomes consistente que suporte isso.

Editar: Esta pergunta tem dois aspectos: Como organizar recursos (DRY x duplicatas) e como nomeá- los. Até agora, as respostas se concentraram no primeiro aspecto. Eu gostaria de receber algum feedback sobre convenções de nomenclatura!

Eu aceitaria duplicação sempre que você não tiver certeza absoluta de que o significado é exatamente o mesmo em todos os casos em que uma determinada string é usada.

Mesmo que dois rótulos sempre contenham a mesma sequência em inglês (ou no idioma nativo), eles não serão necessariamente os mesmos em todos os idiomas. Aceitar a duplicação pode oferecer a você (ou melhor, aos tradutores) a flexibilidade necessária para lidar com essas situações.

Como exemplo: considere um rótulo "Condição", que, dependendo do contexto, pode ser traduzido para "Zustand" ou "Bedingung" em alemão (entre muitas outras traduções possíveis).

Aceite algumas duplicatas.

Você pode evitar algumas traduções múltiplas criando controles extras. Por exemplo, a CancelButtone a OKButtonque já contêm o texto e agora Cancelar / Abrir OK / OK precisam ser traduzidos apenas uma vez. Mas isso é quase um caso especial.

É assim que lidamos com isso na minha empresa:

Convenção de nomenclatura: Nomeamos rótulos prefixando-os com sua classe / seção / formulário / etc. Por exemplo loadFile_loadButton, loadFile_fileNameLabel, loadFile_cancelestão todas as etiquetas que pertencem a um diálogo Carregar arquivo. Embora essa convenção de nomenclatura com sublinhado não seja a mais comum, nós a favorecemos por mais convenções padrão porque melhora a legibilidade e a "capacidade de agrupar": observe como é fácil ver a qual elemento os rótulos pertencem e o que cada rótulo representa, em comparação aos rótulos chamado loadFileLoadButton, loadFileNameLabele loadFileCancel. Você pode pensar que a diferença não é tão grande, mas quando você tem milhares de rótulos, o efeito composto vale a pena.

Comentários do cabeçalho: Além de prefixar nomes de rótulos, também adicionamos comentários de "cabeçalho" aos arquivos de recursos para definir claramente os agrupamentos de rótulos. Dessa forma, alguém que deseja modificar ou adicionar rótulos específicos relacionados a uma classe / seção / formulário / etc específicos pode encontrar todos os rótulos relacionados a esse elemento específico em apenas um lugar, sob um cabeçalho, e pode facilmente continuar adicionando ou modificando rótulos facilmente sabendo que eles não quebrarão as traduções para outros elementos (IMHO, esse também é um ponto muito forte sobre o motivo pelo qual você precisa permitir a duplicação).

Duplicatas "justificadas" são desejáveis: Como mencionado acima, essas práticas definitivamente levarão a etiquetas duplicadas, mas não vemos nenhum problema com isso (mais sobre como lidar com isso em Ferramentas do comércio).

Como outros já apontaram, um rótulo em um idioma pode ser traduzido de duas ou mais maneiras diferentes em outros idiomas, dependendo dos contextos apresentados. Se você "unificar" marcadores, o tradutor terá muita dificuldade em criar um único marcador que acomoda todos os contextos em que é encontrado. Portanto, a nosso ver, permitir duplicatas "justificadas" ajuda a melhorar a qualidade da localização, desde que não se refiram à mesma coisa no mesmo contexto (esse é o significado de "justificado").

Ferramentas comerciais: para ser o mais eficaz possível ao fazer suas traduções, você pode criar sua própria ferramenta que procura rótulos semelhantes existentes em seus pacotes configuráveis ​​e oferecer as traduções deles como valores padrão para novos rótulos, ou pode até use serviços existentes como este , que fornecem ferramentas como a que acabei de mencionar, facilitando a tradução de novos rótulos (ainda mais se eles forem repetidos várias vezes, pois a ferramenta oferecerá várias opções de tradução por padrão para os novos rótulos )

Resumindo: a duplicação justificada e o agrupamento de rótulos de maneira contextual realmente ajudam os tradutores a fazer seu trabalho. Grande momento. Pense bem: ter contexto ajuda bastante o tradutor a selecionar a tradução correta. E permitir duplicatas "justificadas" elimina o conflito de ter que selecionar uma tradução que se encaixe mal em alguns contextos (mas, de qualquer maneira, é o melhor ajuste geral).

Eu espero que isso ajude!

Quando eu fiz isso no passado, descemos a rota do arquivo de recursos contendo frases completas. Se a mesma frase exata fosse usada repetidamente, mas se fossem apenas palavras individuais de uma frase, essas palavras seriam duplicadas.

Estávamos vinculados a uma estrutura em que o arquivo de recursos continha apenas uma lista de frases em inglês, seguida pela tradução (com alguns dados de indexação no final para uma pesquisa rápida).

Para pequenos avisos ou botões de dados, como um nome de campo "CEP" ou um botão "OK", ele armazenava a sequência "CEP" seguida da tradução e a usava sempre que a sequência completa fosse necessária. Mas (a menos que tenhamos quebrado uma string manualmente) não a usaríamos para "CEP" que aparece em uma frase.

Usando seu exemplo de código postal, se você tentar traduzi-lo por si próprio e substituí-lo em todas as frases que o usarem, obterá uma tradução muito ruim.

Por exemplo, "CEP deve ser inserido" pode precisar traduzir o equivalente literal de "CEP inserido deve estar" em outro idioma. Se você cortar uma frase, não terá a reversão de palavras necessária em outro idioma.

É por isso que algumas traduções mal feitas para o inglês parecem tão ridículas, a pessoa que fez isso apenas traduziu as palavras individuais, não a frase inteira.

Sempre achamos melhor traduzir frases como um todo, sem quebrá-las. Tínhamos marcadores de posição para os dados que precisavam ser inseridos (por exemplo, "O número da peça @ 1 é redundante") e o tradutor poderia mover o marcador de posição para a posição desejada para uma boa tradução.

No entanto, descobrimos que permitir locais que usavam exatamente a mesma frase, o mesmo prompt de dados ou o mesmo rótulo de botão, etc, era bom para compartilhar traduções. Isso nunca foi um problema e economizou tempo / custo para o tradutor.

Seu pensamento sobre nomear é bom.

Objetivos

• Defina um rótulo comum (ou seja, nome da variável) para o texto localizado.
• O rótulo deve ter "tamanho da mente". Isso é ... o mais prático possível, sem ambiguidade.
• Os rótulos devem seguir um formato consistente para maximizar a previsibilidade e recuperação.

Implementação

• Reduza a carga cognitiva com o uso consistente de abreviações conhecidas (por exemplo, msg = mensagem, lbl = rótulo, btn = botão, ...)
• As ferramentas apresentam variáveis ​​/ rótulos em listas alfabéticas, portanto, a pesquisa humana é melhor quando os rótulos relacionados são agrupados. Torne os nomes hierárquicos do mais geral ao mais específico. (ou seja, msgFileMissing, msgFileSaved, msgFileDeleted).
• O inglês é uma língua ordenada pelo verbo-substantivo. Muitas (a maioria?) Outras línguas são substantivo-verbo. O verbo substantivo funciona melhor no agrupamento hierárquico.