La inclusión es fundamental para la cultura de Android, y nuestros valores contemplan el trato digno entre individuos. Por lo tanto, es importante que todos puedan contribuir sin enfrentar los efectos negativos del sesgo y la discriminación. Sin embargo, la presencia de ciertos términos en nuestra base de código, interfaces de usuario y documentación podría perpetuar esa discriminación. Esta política sirve como orientación para resolver los problemas relacionados con terminología irrespetuosa presente en códigos, interfaces y documentación.
Política
Se debe evitar la terminología que sea despectiva, discriminatoria o agresiva, ya sea de manera directa o indirecta. Esta norma coincide con la guía de Google para la redacción de documentación inclusiva.
¿Cuál es el alcance de esta política?
Todo el contenido que un colaborador podría leer cuando trabaja en Android, lo que incluye, entre otros aspecto, lo siguiente:
- Nombres de variables, tipos, funciones, archivos, reglas de compilación, objetos binarios, variables exportadas
- Datos de pruebas
- Pantallas y salidas del sistema
- Comentarios y documentación (dentro y fuera de los archivos de fuentes)
- Mensajes de confirmación
Principios
- Respeta a los demás: no es necesario describir el funcionamiento de algo usando lenguaje despectivo.
- Usa términos culturalmente apropiados; es posible que algunas palabras tengan connotaciones históricas o políticas. Ten en cuenta esta realidad y usa alternativas.
¿Cómo puedo saber si un término específico es correcto?
Sigue los principios descritos más arriba. Si tienes alguna pregunta, escríbenos a android-community@googlegroups.com.
¿Qué ejemplos de términos son los que deben evitarse?
Esta lista NO es completa. Contiene algunos ejemplos que los usuarios encuentran con frecuencia.
Ten en cuenta que es importante evaluar si el comentario agrega valor.
A veces la mejor solución es quitar el comentario por completo. Por ejemplo, un comentario que solo dice "Realiza una prueba de sanidad en el encabezado" justo antes de una función llamada verify_header no agrega valor aunque se esté comentando el código de una API pública. Se más específico sobre lo que se está verificando, por ejemplo: "Comprueba que el encabezado no tenga valores fuera de rango".
| Término | Alternativas sugeridas |
|---|---|
| superior/esclavo | principal/réplica, primario/secundario, líder/seguidor, controlador/despachador, administrador/trabajador, mezclador/hoja, agregador/recopilador, editor/suscriptor, iniciador/respuesta |
| Redline | línea de prioridad, seguimiento de cambios, especificaciones de diseño, anotaciones de IU, excepción, anomalía, caso especial, lista de reemplazo |
| lista blanca | lista de anunciantes permitidos, permitidos, lista de inclusión, lista de elementos seguros |
| lista negra | lista de elementos rechazados, bloqueado, lista de exclusiones, lista de anunciantes bloqueados |
| lista gris (oscuro/claro) | Para las API:
|
| loco, demente, lisiado | En el artículo Cómo evitar los términos capacitistas, puedes consultar los lineamientos. |
| prueba de sanidad | El término "verificación" puede expresar el mismo significado. También puedes considerar: validar, comprobar, verificación rápida, verificación inicial, verificación de solidez, verificación de racionabilidad, verificación de calibrado, verificación de preparación. |
| dummy ("tonto" en inglés) | en desuso, marcador de posición, no-op, básico, falso/ficticio/stub. |
| grandfathering ("abuelos" en inglés) | exención, existente, retención, remanente, modelo de referencia, heredado |
| pronombre de género (por ejemplo, él o ella) | los usuarios, las personas, ellos |
| man-in-the-middle (MITM) ("hombre del medio" en inglés, que significa "intermediario") | atacante en la ruta |
| sombrero (negro, blanco o gris) | ético/no ético |
| ciudadano de primera clase | función principal, integrada, de nivel superior |
¿Qué sucede si muestro contenido que infringe esta política?
Este caso se da en algunas ocasiones, especialmente cuando se especifica la implementación de código. En estas circunstancias, usar términos distintos podría interferir con la capacidad de comprender la implementación. En esos casos, sugerimos una de las siguientes alternativas (en orden de preferencia descendiente):
- Si el uso de la terminología alternativa no interfiere con la comprensión, implementarla.
- No propagar la terminología más allá de la capa de código que realiza la acción en la interfaz. Cuando sea necesario, usa terminología alternativa en los límites de la API.
- Si no puedes corregir los términos por tu cuenta, informa el error al equipo correspondiente.