Dois pontos na interface do usuário internacionalizada

Ao usar gettext ou uma estrutura semelhante, as seqüências de conversão devem incluir ':'(como "Label:") para gerar rótulos para a interface do usuário ou devo adicionar o ':'próprio código da interface do usuário?

Os dois pontos podem ser considerados como um símbolo de pontuação. É uma convenção que faz parte do texto, assim como um período ou ponto de interrogação.

Não deixaríamos de fora o ponto de interrogação de "Tem certeza de que deseja sair?" e escreva o código para adicionar os atributos da pergunta de maneira dependente do idioma à sequência traduzida. Fazer isso significa que o código da interface do usuário está assumindo desnecessariamente as responsabilidades de saber como pontuar frases em vários idiomas: uma responsabilidade que pode ser tratada na substituição de mensagens.

Existe uma possibilidade intermediária. É provável que, assim como todos os rótulos tenham o recurso de dois pontos em inglês, em outros idiomas os rótulos também tenham algum elemento lexical em comum. Esse elemento, se presente, é provavelmente algum tipo de prefixo ou sufixo, ou ambos.

Você pode representar os rótulos sem o adorno e, em seguida, ter uma sequência traduzível adicional que fornece um esquema para adicionar o adorno do rótulo. Como exemplo, suponha que a sprintfformatação do estilo C esteja disponível no aplicativo de interface do usuário. A versão em inglês da string de formato de geração de rótulo seria "%s:"e também poderia ser o padrão, pois funciona em outros idiomas. Os tradutores da interface do usuário podem substituí-lo "%s:"pelo que entenderem. Uma das possibilidades é que eles possam substituí-lo por apenas "%s"(não fazer nada) e depois especificar a representação completa e adornada de cada rótulo na tabela de cadeias traduzidas. Portanto, essa abordagem lida com algumas possibilidades estranhas, nas quais o marcador lexical que indica um rótulo deve ser inserido no meio.

Essa abordagem não parece valer a pena, se tudo o que ela consegue é uma leve compressão na representação das strings de etiquetas: a remoção de um caractere de dois pontos. Se você precisar escrever 100 caracteres de código extra para isso, precisará remover dois pontos de 100 rótulos apenas para empatar: e isso nem leva em consideração justificando o tempo gasto.

Deve haver alguma recompensa por isso: o aplicativo usa as strings para outros fins além de gerar rótulos, como gerar frases que se referem aos campos da interface do usuário por nome. Digamos que uma caixa de diálogo tenha um rótulo "User ID:" para inserir texto. Se você tiver uma lógica genérica que produz a mensagem "Você inseriu um ID de usuário inválido". combinando um texto clichê de sentença com o nome de um elemento da interface do usuário, é necessário ter a sequência sem adornos "ID do usuário" e passá-la por uma função de criação de etiqueta para gerar "ID do usuário:".

Para muitos idiomas, não há tradução individual das palavras e frases em inglês, mas várias traduções que são sensíveis ao contexto.

Para facilitar a vida dos tradutores, você deve fornecer o máximo de contexto possível para as strings. Isso inclui dois pontos nos rótulos e informações contextuais em que esses rótulos estão sendo usados.

Como regras básicas, em uma interface internacional, você deve

• não modifique seqüências traduzidas, exceto para preencher parâmetros com seus valores reais. Portanto, não adicione dois pontos depois do fato.
• não cortar cordas em partes em torno dos parâmetros. Especialmente se houver vários parâmetros a serem preenchidos, você pode ter certeza de que haverá pelo menos um idioma em que seria mais natural ter os parâmetros ao contrário.
• tenha muito cuidado com as formas singular / plural. Não existe um padrão comum de como criar plurais a partir de singulares, ou mesmo quantas formas plurais existem.

Eu finalmente decidi usar strings inteiras (neste caso, strings com dois pontos) nos meus arquivos i18n.

A razão para isso é que, em francês, deve haver um espaço antes dos dois pontos. Portanto, a melhor maneira de codificar francês é colocar dois pontos (com espaços antes) nas cadeias de tradução.

Não, não traduzimos para o francês. Mas este é um exemplo para uma regra geral de comportamento: coloque dois pontos nas seqüências de conversão, não no código da interface do usuário.

A abordagem ideal é incorporar os caracteres na sequência de caracteres para cada localidade, pois isso normalmente garante que o contexto esteja correto, supondo que você tenha feito sua pesquisa sobre o que seu público-alvo espera.

Cada país geralmente fornece um guia de estilo, que determina todos os locais 'corretos' para pontuação. Então, quando comecei a descobrir como lidaria com aspas para diferentes idiomas para algumas ferramentas de design da web, observei primeiro esses guias de estilo.

No entanto, embora as publicações escritas tendam a seguir os guias de estilo, o mundo on-line é bem diferente! Normalmente, um grande número de sites europeus e sul-americanos não ingleses usa aspas no estilo dos EUA, em oposição às guillemets («») de seus guias de estilo. Apenas mostra o quanto o domínio dos EUA da web primitiva permeia o uso de idiomas on-line em todo o mundo.

Os jornais e jornais em língua estrangeira do MIT : Home têm links para centenas de sites online. Analisá-las me ajudou a encontrar a melhor abordagem para meu dilema, que era fornecer ao proprietário do site a possibilidade de selecionar um dos 19 conjuntos mais populares de combinações de citações incorporadas entre aspas, apropriadas para o público-alvo.

O Chrome tenta usar automaticamente o guia de estilo de um país, mas felizmente pode ser substituído, especificando um código de idioma no atributo lang da tag q . Isso destaca o problema com abordagens automáticas que não levam em conta o mundo real, mas dependem da teoria para suas implementações.

Para o OP, pesquise esses sites de jornais on-line para ver o que é realmente usado em vários países, para que você possa ver qual abordagem fornecerá resultados mais consistentes.

Embora alguns idiomas usem tradicionalmente um caractere diferente para os dois pontos em inglês, o uso on-line pode atingir o público usado para esses dois pontos. Além disso, localidades diferentes podem ter uso diferente, exigindo a especificação de sequências de idiomas para cada localidade completa, em vez de apenas pelo idioma.

Quando eu estava fazendo minha própria internacionalização há alguns anos, funcionou algo como isto:

• As mensagens no código fonte foram escritas em inglês

• As mensagens foram traduzidas em tempo de execução aplicando uma tradução (que apareceu na fonte como translate ("string") ou, mais geralmente / "string"). Era esperado que houvesse um dicionário pré-construído de mensagens e traduções.

• Ao traduzir uma mensagem, o espaço em branco em cada extremidade foi cortado e a pontuação à direita foi removida, assim como qualquer capitalização. Depois de traduzir o que restou, eles foram devolvidos.

• Para fornecer mais contexto, às vezes adicionei um comentário à string, que fazia parte do processo de tradução para ajudar a encontrar a melhor correspondência, mas o comentário foi descartado.

Portanto, com uma mensagem como "Disco:", a cadeia "disco" foi traduzida para, por exemplo, "disquette" e, em seguida, recomposta como "Disquette:". Isso reduziu o número de mensagens muito semelhantes.

Eu fiz isso apenas para um pequeno número de línguas da Europa Ocidental; provavelmente haveria problemas com outros mais exóticos. No entanto, eu estava usando uma linguagem do tipo script para isso, para que algum processamento de string pudesse ser usado para quaisquer problemas que surgissem: quando eu precisava traduzir "G" (abreviação de Green), ele aparecia na fonte à esquerda (/ "Green" ), traduzido para algo como "vert" e reduzido para "V".

No entanto, não estou familiarizado com as estruturas atuais e como elas podem funcionar; eles não fornecem diretrizes para lidar com esses tipos de problemas?

Pode depender do sistema de localização que você usa, mas, tendo outras coisas iguais, eu pessoalmente evitaria adicionar qualquer pontuação (a menos que em uma frase, é claro, onde seu uso seja determinado pela gramática), porque sinto que eles fazem parte de a apresentação , como tamanho da fonte etc., e não o conteúdo . Então, estamos misturando coisas diferentes com essa abordagem.

Afinal, as mesmas palavras e frases podem ser necessárias tanto com pontuação quanto sem. Por exemplo. você pode ter "Enter subject:"legenda ao lado de uma caixa de texto, mas também "Enter subject"como um título da janela.

Faz sentido que os dois sejam traduzidos separadamente?

Quando você decide que os dois pontos realmente parecem ruins e redundantes na interface do usuário, será necessário retraduzir todas as versões de idioma. O que é um pouco bobo.

PS. As "regras básicas" fornecidas pelo @bartc são válidas de qualquer maneira - independentemente de você incluir ou não sinais de pontuação nas strings traduzidas.

PPS. @paulkayuk também levanta um bom argumento (em seu comentário) - que as especificidades da cultura devem ser levadas em consideração também. Se você tem coisas como pontos de interrogação espelhados em espanhol, inclua-os na sua tradução, é claro. Minha resposta assume uma pontuação uniforme e independente da linguagem, porque esse parece ser o ponto discutível.

Um arquivo de idioma do aplicativo não é apenas uma tradução fictícia de palavras. É um processo no qual você traduz as palavras e sua "apresentação" pontual no contexto correto e significativo .

Hello?em espanhol é ¿Hola?em árabe é مرحبا؟. Como você pode ver, você não pode simplesmente armazenar um Helloou Holaou مرحباe, na interface do usuário, basta executar um the_hello_text + "?". Não produzirá a saída correta. É óbvio que a pontuação precisa ser cuidada no arquivo de idioma. Isso significa que não é da preocupação da GUI "adicionar" um ponto de interrogação ou dois pontos no final de uma sequência.

A pontuação e tudo devem estar dentro do arquivo de internacionalização, prontos para serem enviados para a interface do usuário.

A única coisa com a qual a interface do usuário deve se preocupar é a apresentação correta desse texto pronto para ser computado , como alinhar à direita se for uma linguagem RTL. Mas isso é outra história e não tem nada a ver com arquivos de linguagem de internacionalização em texto simples por si só.