Community Translations of the Standard for Public Code

Contents

  1. Krav
  2. Hvorfor er dette vigtigt
  3. Hvad dette ikke gør
  4. Hvordan tester man
  5. Politiske beslutningstagere: hvad skal du gøre
  6. Ledelse: hvad skal du gøre
  7. Udviklere og designere: hvad skal du gøre
  8. Yderligere læsning

Contribute on GitHub

Brug almindeligt engelsk

Krav

  • Al kode og dokumentation SKAL være på engelsk.
  • Enhver oversættelse SKAL være opdateret med den engelsk version og vice versa.
  • Der BØR ikke være akronymer, forkortelser, jokes eller juridiske/domæne specifikke begreber i kodebasen uden en forklaring før eller et link til en forklaring.
  • Navnet på kodebase BØR være beskrivende og uden akronymer, forkortelser, jokes eller branding.
  • Dokumentation BØR stile efter en læsesværhedsgrad som før-gymnasium niveau, som anbefalet af Web Content Accessibility Guidelines 2.
  • Enhver kode, dokumentation og test MÅ have en oversættelse.

Hvorfor er dette vigtigt

  • Gør kodebasen og hvad den gør forståelig for en bred gruppe af interessenter in flere kontekster.
  • Hjælper andre med at opdage din kodebase.
  • Kan hjælpe dig med at imødekomme European Union accessibility directive, som kræver at det meste offentlige information er tilgængeligt.

Hvad dette ikke gør

  • Gør forklaringer af din kodebases funktionalitet forståelig.
  • Gør din organisations jargon forståelig uden en forklaring.

Hvordan tester man

  • Tjek at oversættelsen og den engelske version har samme indhold.
  • Valider at ingen akronymer, forkortelser, jokes, juridisk/domæne specifikke begreber står i dokumentationen uden forklaring.
  • Test dokumentationen for grammatiske fejl ved at bruge Grammarly.
  • Test dokumentationens læsbarhed med Hemingway text editor.
  • Spørg nogen uden for din kontekst, om de forstår dit indhold (f.eks. en udvikler, der arbejder på et andet projekt).

Politiske beslutningstagere: hvad skal du gøre

  • Test ofte med andet ledelse, designere og udviklere i processen, om de forstår, hvad du leverer og hvordan du dokumenterer det.

Ledelse: hvad skal du gøre

  • Forsøg at begrænse brugen af akronymer, forkortelser, jokes eller juridisk/domæne specifikke begreber i intern kommunikation og imellem teams og interessenter.
  • Vær kritisk overfor dokumentation og beskrivelser i forslag og ændringer – hvis der er noget, du ikke forstår, så vil andre nok også have problemer med det.

Udviklere og designere: hvad skal du gøre

  • Test ofte med politiske beslutningstagere og ledelse, hvorvidt de forstår, hvad du leverer og hvordan du dokumenterer det.

Yderligere læsning