A inclusão é essencial para a cultura do Android, e nossos valores incluem tratar uns aos outros com dignidade. Por isso, é importante que todos possam contribuir sem enfrentar os efeitos prejudiciais da parcialidade e da discriminação. No entanto, os termos do nosso codebase, as interfaces do usuário e a documentação podem perpetuar essa discriminação. Esta política oferece orientação para lidar com a terminologia desrespeitosa em código, interfaces e documentação.
Política
Termos que sejam depreciativos, ofensivos ou que perpetuem discriminação, seja ela direta ou indireta, precisam ser evitados. Essa é a orientação do Google sobre como redigir uma documentação inclusiva.
O que está no escopo desta política?
Tudo o que um colaborador leria ao trabalhar no Android, incluindo, entre outros:
- Nomes de variáveis, tipos, funções, arquivos, regras de compilação, binários, variáveis exportadas
- Dados de teste
- Saída e exibições do sistema
- Comentários e documentação (dentro e fora dos arquivos de fonte)
- Mensagens de confirmação
Princípios
- Demonstre respeito: uma linguagem depreciativa não é necessária para descrever como as coisas funcionam.
- Use uma linguagem culturalmente adequada: algumas palavras podem ter significados históricos ou políticos importantes. Considere isso e use alternativas.
Como posso saber se uma terminologia específica está correta?
Aplique os princípios acima. Se tiver alguma dúvida, entre em contato com android-community@googlegroups.com.
Que exemplos de terminologia devem ser evitados?
Esta NÃO é uma lista completa. Ela contém alguns exemplos que as pessoas encontram com frequência.
É sempre importante considerar se um comentário agrega algum valor.
Às vezes, a melhor solução é removê-lo completamente. Por exemplo, um
comentário que diz apenas "Verifique a integridade do cabeçalho" imediatamente antes de uma
função chamada verify_header não agrega nenhum valor, mesmo que você esteja escrevendo o
comentário de documento para uma API pública. Forneça informações mais específicas sobre o que precisa ser verificado. Por
exemplo: "Verifique se não há valores fora do intervalo no cabeçalho".
| Termo | Alternativas sugeridas |
|---|---|
| mestre/escravo | principal/réplica, principal/secundário, líder/seguidor, controlador/agente, gerente/trabalhador, misturador/folha, agregador/coletor, editor/assinante, iniciador/resposta automática |
| linha vermelha | linha de prioridade, controle de alterações, especificações de design, anotações de IU, exceção, anomalia, caso especial, lista de substituição |
| lista branca | lista de permissões, permitido, lista de inclusão, lista segura |
| lista negra | lista de negações, bloqueado, lista de exclusão, lista de bloqueio |
| lista cinza (escuro|claro) | Para APIs:
|
| louco, insano, inválido | Consulte as diretrizes em Evitar linguagem capacitista. |
| verificação de sanidade | A palavra "verificação" sozinha transmite o mesmo significado. Caso contrário, considere usar validação, confirmação, verificação rápida, verificação inicial, verificação de confiança, verificação de solidez, verificação de calibragem, verificação de prontidão. |
| dummy | não utilizado, marcador, ambiente autônomo, base, falso/simulado/stub. |
| grandfathering | isenção, já existente, retenção, transferência, valor de referência, legado |
| pronomes que determinam gênero (por exemplo, ele ou ela) | eles, eles, seus |
| atravessador | invasor |
| chapéu (preto|branco|cinza) | ético/antiético |
| cidadão de primeira classe | recurso principal, integrado, nível superior |
E se eu estiver interagindo com algo que viole esta política?
Essa situação já ocorreu algumas vezes, especialmente na especificação para a implementação de código. Nessas circunstâncias, uma linguagem na especificação pode interferir na capacidade de entendimento da implementação. Para essas circunstâncias, sugerimos uma das seguintes opções, em ordem decrescente de preferência:
- Se o uso da terminologia alternativa não interferir no entendimento, use a terminologia alternativa.
- Não propague a terminologia além da camada de código que está realizando a interface. Quando necessário, use uma terminologia alternativa nos limites da API.
- Se você não conseguir corrigir a linguagem, registre um bug com a respectiva equipe.