From a065e04d529da1d847b5062a12c46d916408bf32 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 21:46:22 -0500 Subject: update based on https://github.com/mdn/yari/issues/2028 --- .../writing_localizable_code/index.html | 47 ---------------------- 1 file changed, 47 deletions(-) delete mode 100644 files/pt-br/mozilla/localization/writing_localizable_code/index.html (limited to 'files/pt-br/mozilla/localization/writing_localizable_code') diff --git a/files/pt-br/mozilla/localization/writing_localizable_code/index.html b/files/pt-br/mozilla/localization/writing_localizable_code/index.html deleted file mode 100644 index f403bdbb1c..0000000000 --- a/files/pt-br/mozilla/localization/writing_localizable_code/index.html +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: Escrevendo código localizável -slug: Mozilla/Localization/Writing_localizable_code -tags: - - Internacionalização - - Localização -translation_of: Mozilla/Localization/Writing_localizable_code ---- -
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:

- - - -

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 é

- - -- cgit v1.2.3-54-g00ecf