Como preparar um aplicativo para localização (HTML)

Artigo
01/29/2016

[ Este artigo destina-se aos desenvolvedores do Windows 8.x e do Windows Phone 8.x que escrevem aplicativos do Windows Runtime. Se você estiver desenvolvendo para o Windows 10, consulte documentação mais recente ]

Siga as etapas e a práticas recomendadas descritas aqui para preparar seu aplicativo para localização. Antes de você iniciar, leia a lista de verificação para globalização para assegurar que seu aplicativo está pronto para outros mercados, regiões e idiomas.

Instruções

Usar arquivos e qualificadores de recurso

Especifique os recursos da cadeia de caracteres nos arquivos de recurso. Para saber mais, veja Início rápido: traduzindo recursos da interface do usuário.

Especifique imagens ou outros recursos de arquivo com a marca do idioma adequado em seu arquivo ou pasta. Saiba que localizar imagens, áudio e vídeo consome uma grande quantidade de recursos do sistema, portanto é melhor usar ativos de mídia neutros sempre que possível. Para saber mais, veja Como nomear recursos usando qualificadores.

Adicionar comentários contextuais

Adicione comentários de localização aos arquivos de recurso do aplicativo. Os comentários ficam visíveis para o tradutor e devem fornecer informações contextuais que ajudem o tradutor a traduzir os recursos com precisão. Os comentários também devem fornecer informações de restrições suficientes sobre o recurso, para que a tradução não corrompa o software. Opcionalmente, os comentários podem ser registrados pela ferramenta Makepri.exe.

O ResJSON permite metadados em campos que comecem com um sublinhado, como comentários:

{
    "String"  : "Hello World",
    "_String1.comment" : "This is a comment to the localizer"
}

Localizar sentenças em vez de palavras

Considere a seguinte cadeia de caracteres: "o {0} não pode ser sincronizado."

Uma variedade de palavras poderia substituir {0}, como compromisso, trabalho ou documento. Apesar desse exemplo funcionar em português, essa estrutura gramatical pode não funcionar em uma sentença correspondente em alemão. Note que, nas seguintes sentenças em alemão, algumas das palavras da cadeia de caracteres de modelo ("Der", "Die", "Das") precisam corresponder à palavra parametrizada:

Português	Alemão
Não foi possível sincronizar o compromisso.	Der Termin konnte nicht synchronisiert werden.
Não foi possível sincronizar a tarefa.	Die Aufgabe konnte nicht synchronisiert werden.
Não foi possível sincronizar o documento.	Das Dokument konnte nicht synchronisiert werden.

Como outro exemplo, considere a sentença "Lembre-me em {0} minuto(s)." Embora o uso de "minuto(s)" funcione para o idioma português, outros idiomas podem usar termos diferentes. Por exemplo, o idioma polonês usa "minuta", "minuty" ou "minut" dependendo do contexto.

Para solucionar esse problema, localize a sentença inteira, em vez de uma única palavra. Fazer isso pode parecer um trabalho redobrado e uma solução inadequada, mas essa é a melhor solução porque:

Uma mensagem sem erros será exibida para todos os idiomas.
Seu tradutor não precisará perguntar pelo o que as cadeias de caracteres serão substituídas.
Não será necessário implementar uma correção de código dispendiosa quando um problema como esse surgir depois que seu aplicativo for concluído.

Assegurar da ordem correta do parâmetro

Não suponha que todos os idiomas usem os parâmetros na mesma ordem. Por exemplo, considere a cadeia de caracteres "Em %s %s", onde o primeiro %s é substituído pela data de um mês e o segundo %s é substituído pelo nome de um mês. Esse exemplo funciona no idioma português, mas não funcionará quando o aplicativo for localizado no idioma inglês, onde a data e o mês são exibidos na ordem inversa.

Para solucionar esse problema, mude a cadeia de caracteres para "Em %1 %2", dessa forma a ordem será intercambiável dependendo do idioma.

Não localizar excessivamente

Traduza cadeias de caracteres específicas, não marcas. Veja os seguintes exemplos:

Cadeia de caracteres traduzida excessivamente	Cadeia de caracteres traduzida corretamente
<link>termos de uso</link>	termos de uso
<link>política de privacidade</link>	política de privacidade

A inclusão da marca acima <link> nos recursos significa que ela também será traduzida. Isso invalida a marca. Só as cadeias de caracteres devem ser traduzidas. De um modo geral, você deve considerar as marcas como um código, que devem ser mantidas separadas do conteúdo localizável. Entretanto, algumas cadeias de caracteres longas devem incluir marcação para manter o contexto e a assegurar a ordem.

Não usar as mesmas cadeias de caracteres em contextos diferentes

Reutilizar uma cadeia de caracteres pode parecer a melhor solução, mas isso poderá causar problemas de localização se a mesma palavra ou frase tiver diferentes significados ou contextos.

Você poderá reutilizar cadeias de caracteres se os dois contextos forem iguais. Por exemplo, você pode reutilizar a cadeia de caracteres "Volume" para volume de efeito de som e volume de música, porque ambos se referem à intensidade de som. Não reutilize essa mesma cadeia de caracteres quando se referir a um volume de disco rígido, porque o contexto e o significado são diferentes, e a palavra pode ser traduzida de forma diferente.

Outro exemplo é o uso das cadeias de caracteres "ativar" e "desativar". No idioma português, "ativar" e "desativar" podem ser utilizados para uma alternância para modo de voo, Bluetooth e dispositivos. Mas em italiano, a tradução dependerá do contexto do que está sendo ativado e desativado. Seria necessário criar um par de cadeias de caracteres para cada contexto.

Além disso, uma cadeia de caracteres como "text" ou "fax" poderia ser usada como verbo e substantivo em inglês, o que pode confundir o processo de tradução. Em vez disso, crie uma cadeia de caracteres separada para o formato de verbo e substantivo. Quando você não tiver certeza se os contextos são os mesmos, por precaução, use uma cadeia de caracteres distinta.

Identificar recursos com atributos exclusivos

Os identificadores de recurso não diferenciam maiúsculas e minúsculas e devem ser exclusivos por arquivo de recurso. Ao acessar um recurso, use o identificador de recurso, não o valor real do recurso. Os identificadores de recurso não mudam, mas os valores reais dos recursos mudam dependendo do idioma.

Use identificadores de recurso significativos para fornecer contexto adicional para a tradução.

Não mude os identificadores de recurso depois que os recursos da cadeia de caracteres forem enviados para a tradução. As equipes de localização usam o identificador de recurso para rastrear as adições, exclusões e atualizações dos recursos. Mudanças nos identificadores de recurso, —também conhecidas como "alternâncias de identificadores de recursos"—, exigem que as cadeias de caracteres sejam novamente traduzidas, porque elas aparecerão mesmo que tenham sido excluídas e outras tenham sido adicionadas.

Escolher uma abordagem de tradução adequada

Depois que as cadeias de caracteres forem separadas nos arquivos de recurso, elas poderão ser traduzidas. O momento ideal para traduzir as cadeias de caracteres é depois que elas forem finalizadas, o que geralmente acontece no final de um projeto. Você pode abordar o processo de tradução de várias maneiras. Isso vai depender do volume de cadeias de caracteres a ser traduzido, da quantidade de idiomas a ser traduzida e do modo como a tradução será feita (por exemplo, internamente ou por contratação de fornecedor externo).

Considere as seguintes opções:

Os arquivos do recurso podem ser traduzidos abrindo-os diretamente no projeto. Essa abordagem funciona bem para um projeto que tenha um pequeno volume de cadeias de caracteres e que precise a ser traduzido para dois ou três idiomas. Ela pode ser adequada para um cenário em que um desenvolvedor fale mais de um idioma e esteja disposto a se envolver no processo de tradução. Essa abordagem é vantajosa por ser rápida, não exigir ferramentas e minimizar o risco de traduções incorretas, mas ela não é escalável. Em particular, os recursos em idiomas diferentes podem facilmente ficar fora de sincronia, causando experiências ruins para o usuário e dores de cabeça para executar a manutenção.
Os arquivos de recurso de cadeia de caracteres estão no formato de texto XML ou ResJSON, portanto, podem ser enviados para tradução usando qualquer editor de texto. Os arquivos traduzidos então serão copiados novamente no projeto. Essa abordagem implica o risco de os tradutores editarem acidentalmente as marcas de XML, mas permite que o trabalho de tradução seja feito fora do projeto do Microsoft Visual Studio. Essa abordagem pode funcionar bem para projetos que precisam ser traduzidos em poucos idiomas. O formato XLIFF é um formato XML projetado especificamente para uso em localização e deve ser bem aceito por alguns fornecedores ou ferramentas de localização. O Kit de Ferramentas de Aplicativo Multilíngue pode ser usado para gerar arquivos XLIFF a partir de outros arquivos de recurso (.resw ou .resjson).

Pode ser necessário que outros arquivos, como arquivos de imagem ou de áudio, sejam enviados para os tradutores. Normalmente, não recomendamos a criação de arquivos culturalmente dependentes, pois isso dificulta a tradução desses arquivos.

Além disso, considere as seguintes sugestões:

Usar uma ferramenta de localização. Uma série de ferramentas de localização são disponíveis para analisar os arquivos de recursos e permitir somente as cadeias de caracteres traduzíveis a serem editadas pelos tradutores. Essa abordagem reduz o risco de um tradutor editar acidentalmente as marcas de XML. A desvantagem é que é preciso introduzir uma nova ferramenta e um novo processo à localização. Uma ferramenta de localização é uma boa solução para projetos com um grande volume de cadeias de caracteres, mas incluindo poucos idiomas. Para saber mais, veja Kit de Ferramentas de Aplicativo Multilíngue.
Usar um fornecedor de localização. Considere usar um fornecedor de localização, se seu projeto contiver um grande volume de cadeias de caracteres e precisar ser traduzido para muitos idiomas. Um fornecedor de localização pode recomendar ferramentas e processos, bem como traduzir seus arquivos de recurso. Essa é a solução ideal, mas também é a opção mais dispendiosa, e pode aumentar o tempo de retorno do conteúdo traduzido.
Manter os tradutores informados. Informe os tradutores de cadeias de caracteres que podem ser considerados um substantivo ou um verbo. Explique as palavras fabricadas para seus tradutores usando as ferramentas de terminologia. Mantenha as cadeias de caracteres gramaticalmente corretas, sem ambiguidade e o menos técnicas possível para evitar confusão.

Teclas de acesso e rótulos

É realmente um desafio fazer a "sincronização" das teclas de acesso usadas na acessibilidade com a exibição das teclas de acesso localizadas, porque os dois recursos de cadeias de caracteres são categorizados em duas seções separadas. É importante que você siga a implementação mostrada abaixo e que comente adequadamente a cadeia de caracteres do rótulo para vinculá-la à definição da tecla de acesso.

<label id="theLabel" data-win-res="{accessKey: 'theLabelAccessKey'}" for="xPrinterRedirection" accessKey="L">The <u>L</u>abel</label>
<input type="checkbox" value="OFF" id="xPrinterRedirection" name="xPrinterRedirection" />

Forneça os seguintes tipos de comentários: Make sure that <u>L</u> is synchronized with the access key "theLabelAccessKey"

Suportar Furigana para cadeias de caracteres japonesas que podem ser classificadas

Os caracteres Kanji japoneses apresentam a propriedade exclusiva de ter mais de uma pronúncia, dependendo da palavra e/ou do contexto em que são usados. Isso é um problema quanto tentamos classificar os objetos nomeados em japonês, como nomes de aplicativos, arquivos, músicas etc. No passado, o Kanji japonês era classificado em uma ordem chamada XJIS, que podia ser compreendida pelo computador. Infelizmente, como essa ordem de classificação não é fonética, ela não é muito útil para o ser humano.

O Furigana resolve esse problema permitindo que o usuário ou criador especifique a fonética dos caracteres em uso. Se você usar o seguinte procedimento para adicionar Furigana ao nome do aplicativo, poderá garantir que ele seja classificado no local adequado da lista de aplicativos. Se o nome do aplicativo contiver os caracteres Kanji e o Furigana não for fornecido quando o idioma da interface do usuário ou a ordem de classificação for definida em japonês, o Windows se esforçará ao máximo para gerar a pronúncia adequada. Entretanto, existe a possibilidade de os nomes de aplicativos, que contêm leituras raras ou exclusivas, serem classificados em uma leitura mais comum. Portanto, a prática recomendada para aplicativos em japonês (especialmente aqueles que contêm caracteres Kanji em seus nomes) é fornecer uma versão Furigana do nome do aplicativo como parte do processo de localização em japonês.

Adicione "ms-resource:Appname" como o Nome de Exibição do Pacote e o Nome de Exibição do Aplicativo.

Crie uma pasta ja-JP nas cadeias de caracteres e adicione dois arquivos de recursos como a seguir:

strings\
    en-us\
    ja-jp\
        Resources.altform-msft-phonetic.resw
        Resources.resw

Em Resources.resw para ja-JP geral: adicione um recurso de cadeia de caracteres para Appname "希蒼"
Em Resources.altform-msft-phonetic.resw para recursos furigana em japonês: adicione um valor Furigana para AppName "のあ"

O usuário pode pesquisar o nome do aplicativo "希蒼" usando o valor Furigana "のあ" (noa),　e o valor fonético (usando a função GetPhonetic do IME) "まれあお" (mare-ao).

A classificação segue o formato Painel de Controle Regional:

Em local de usuário japonês,
- Se Furigana for habilitado, o "希蒼" será classificado em "の".
- Se Furigana estiver ausente, o "希蒼" será classificado em "ま".
Em um local de usuário que não é japonês,
- Se Furigana for habilitado, o "希蒼" será classificado em "の".
- Se Furigana estiver ausente, o "希蒼" será classificado em "漢字".

Compartilhar via