Essa página lhe fala sobre as melhores práticas e diretrizes ao lidar com código de UI relacionado a localização. Ela é destinada a desenvolvedores do Mozilla e de extensões.

Para mais detalhes técnicos, por favor veja também UL_Tutorial:Localization.

Sobre localizadores

Algumas notas sobre localizadores para desenvolvedores que raramente lidam ocm eles:

  • localizadores gostam de ferramentas, e eles não gostam de editores,
  • ferramentas de localização geralmente são baseadas em pares de chave-valor,
  • pelo menos alguns localizadores possuem talentos com foco em habilidades linguísticas e não conhecedores de programação, ou alté mesmo compilação de aplicativos.

Diretrizes

Portanto, há algunas diretrizes que você deve seguir para facilitar a localização de seu código:

Escolha bons nomes de chaves
Os nomes escolhidos para suas chaves (independentemente de ser um DTD ou um arquivo de propriedade) devem ser descritivos. Pensem neles como sendo nomes longos de variáveis. Se você alterar as semânticas de uma string localizada, altere a chave. Isso provavelmente será um bom nome de chave, e ajudará as ferramentas a compreender que a alteração que você fez é diferente de uma mera correção de ortografia.
Tente não presumir a gramática em strings compostas
A separação de frases em várias chaves muitas vezes, inadvertidamente, pressupõe uma gramática, uma estrutura de oração e essas strings compostas são muitas vezes muito difíceis de traduzir. Quando uma string composta é necessária, tente dar aos tradutores "espaço para se mover". Um exemplo de uma string composta bem utilizada é a configuração do Firefox para páginas visitadas: o tradutor pode (implicitamente) posicionar o campo de texto como ele bem entender.
Não use macros de pré-processador
O uso de #if #else #endif ou #expand é fortemente desencorajado. Há algumas exceções a esta regra, mas, em geral, o arquivo localizado deve estar em conformidade com padrões e não devem exigir ferramentas de compilação para serem transformadas. Se você deseja adicionar processamento de compilação a arquivos localizados, certifique-se de solicitar feedback do l10n@. Na maioria dos casos, você também pode colocar o processamento em código de conteúdo e referência diferentes pares de valor-chave em l10n.
Use uma boa estrutura de diretórios de fontes
Certifique-se de colocar os arquivos localizáveis no lugar correto. A adição de diretórios de topo de nível é um meio termo entre a propriendade do módulo no repositório no cvsroot e a facilidade de localização.
Use uma boa estrutura de diretório de chrome
Para um módulo mod em particular, um caminho alvo jar:ab-CD.jar!/locale/ab-CD/mod/foo.dtd foi amplamente testado e é um bom lugar para seus arquivos referenciados como chrome://mod/locale/foo.dtd. Usar uma estrutura de diretórios como essa facilita o processo de localização sem o código fonte e é especialmente recomendada para autores de extensão. Manifestos de JAR podem facilitar isso.

Impacto de l10n

Em árvores congeladas, há a regra de não verificar alterações de l10n-impact. Então, o que isso significa? l10n-impact é

  • qualquer alteração a mozilla/@mod@/locales; Localizadores descobrem se eles têm que se atualizar sobre alterações ao fazer consultas de bonsai, assim como todo mundo faz. Nenhuma alteração significa que esse resultado de consulta é vazio.
  • qualquer uso alterado ou novo de strings localizadas existentes; Qualquer coisa que dispara um ciclo de QA em 40+ localizações é l10n-impact.

Etiquetas do documento e colaboradores

 Colaboradores desta página: rafaelff
 Última atualização por: rafaelff,