Community Translations of the Standard for Public Code

Contents

  1. Requisitos
  2. Por qué es importante
  3. Qué no hace
  4. Cómo probar o hacer tests
  5. Responsables de políticas y legislaciones: qué necesitan hacer
  6. Profesionales de la dirección de equipos: qué necesitan hacer
  7. Profesionales del desarrollo de software y diseño: qué necesitan hacer
  8. Más información

Utilizar un inglés sencillo

Requisitos

  • Toda la documentación de la codebase DEBE estar en inglés sencillo.
  • Todo el código DEBE estar en inglés, excepto cuando se requiera su ejecución como política.
  • Cualquier traducción DEBE estar actualizada con la versión en inglés y viceversa.
  • No DEBERÍA haber acrónimos, abreviaturas, juegos de palabras o términos legales/no ingleses/específicos del dominio en la codebase sin una explicación previa o un enlace a una explicación.
  • El nombre de la codebase DEBERÍA ser descriptivo y estar libre de acrónimos, abreviaturas, juegos de palabras o marcas de la organización.
  • La documentación DEBERÍA apuntar a un nivel de lectura de educación secundaria inferior, como recomiendan las Pautas de Accesibilidad al Contenido en la Web 2.
  • Todo el código, la documentación y las pruebas PUEDEN tener una traducción.

Por qué es importante

  • Hace que la codebase y lo que hace sean comprensibles para una mayor variedad de partes interesadas en múltiples contextos.
  • Ayuda a descubrir la codebase.
  • Puede ayudarle a cumplir la directiva de accesibilidad de la Unión Europea, que exige que la mayor parte de la información del sector público sea accesible.

Qué no hace

  • Hacer comprensibles las explicaciones de la funcionalidad de la codebase.
  • Hacer que la jerga de tu organización sea comprensible sin una explicación.

Cómo probar o hacer tests

  • Verificar que las traducciones y la versión en inglés tienen el mismo contenido.
  • Validar que la documentación no contenga acrónimos, abreviaturas, juegos de palabras o términos legales/específicos del dominio sin explicar.
  • Comprobar la gramática de la documentación con Grammarly.
  • Comprobar la legibilidad de la documentación con Hemingway text editor.
  • Preguntr a alguien fuera de tu contexto si entiende su contenido (por ejemplo, un desarrollador que trabaje en una la codebase diferente).

Responsables de políticas y legislaciones: qué necesitan hacer

  • Probar con frecuencia con otras personas directivas, diseñadoras y desarrolladoras del proceso si entienden lo que esta siendo entregando y cómo está documentado.

Profesionales de la dirección de equipos: qué necesitan hacer

  • Intentar limitar el uso de acrónimos, abreviaturas, juegos de palabras o términos legales/específicos del dominio en las comunicaciones internas en y entre los equipos y las partes interesadas.
  • Ser una persona crítica con la documentación y las descripciones de las propuestas y los cambios: si no entiendes algo, es probable que los demás también tengan problemas con ello.

Profesionales del desarrollo de software y diseño: qué necesitan hacer

  • Realizar pruebas o tests frecuentemente con responsables de políticas y personas directoras de equipos. si comprenden lo que está siendo entregando y cómo está documentado.

Más información