Inclusive language/fr

Nous voulons encourager la culture de l'inclusivité, et une façon faire cela est de s'assurer que nous utilisons les termes appropriés là où nous le pouvons.

Alors que certaines personnes peuvent prétendre que ces mots ne sont pas offensants pour eux, ou qu'ils n'ont jamais été ajoutés dans une intention offensante, ils doivent être conscients que ces mots sont potentiellement offensants pour d'autres groupes de personnes, et nous devons nous efforcer d'en supprimer l'usage.

Cet effort contribue également à remplir notre engagement envers le :

"Dans l'intérêt de favoriser une communauté ouverte et accueillante, nous nous engageons à faire de la participation aux projets techniques Wikimedia une expérience respectueuse et sans harcèlement pour chacun [...]"



Termes à éviter et leurs alternatives
La liste suivante est incomplète. Voir la section des Resources ci-dessous pour les autres recommendations. Nous utilisons différents mots alternatifs en fonction du contexte, pour que la correspondance grammaticale ou technique soit meilleure.

Il est à noter qu'il existe des cas où nous ne pourrons peut-être pas modifier/supprimer certaines de nos utilisations de ces mots, par exemple jusqu'à ce que les développeurs en amont les aient corrigés et que cela se répercute sur notre logiciel déployé. Cela convient car nous ne le maîtrisons pas. Il serait mieux de vérifier en amont s'ils envisagent de résoudre les problèmes similaires dans leurs propres bases de code. Néanmoins nous pouvons et devons utiliser ces mots dans nos bases de code quand nous le pouvons.



Comment aider
Si vous cherchez à aider en fournissant cet effort, est un bon point de départ pour discuter du problème, et aussi pour trouver les tâches spécifiques concernant les endroits du code qui doivent être mis à jour.

Certaines peuvent être aussi simples que la mise à jour ou l'amélioration des commentaires et des noms de variables.

D'autres peuvent être plus complexes et nécessiter un renommage des fonctions et des accroches, tout en suivant notre.

Certains usages peuvent avoir besoin de rester plus longtemps, mais cesseront généralement d'être le code canonique, montrant l'intention d'être supprimés dans un proche avenir.

Ressources

 * Manuels et documentation associées venant d'autres organisations (via cdanis et ietf qui en listent beaucoup d'autres)
 * American Chemical Society Inclusivity Style Guide
 * Android Open Source Project's "Coding with Respect"
 * Apple's Style Guide - (section on inclusive language, entry on master/slave, entry on blacklist/whitelist)
 * Bluetooth SIG's "Appropriate Language Mapping Tables"
 * Chromium's "Inclusive Code" document
 * Google's "Writing Inclusive Documentation"
 * Google's "Developer documentation style guide word list"
 * Internet Engineering Task Force:
 * Terminology, Power, and Inclusive Language in Internet-Drafts and RFCs (draft v.4)
 * Inclusive terminology in IETF Documents (work in progress)
 * Microsoft's "Bias-free communication" document
 * Twitter Engineering
 * W3C Manual of Style
 * Inclusive Naming Initiative
 * https://www.writethedocs.org/guide/writing/reducing-bias/
 * Woke, a non-inclusive language detection tool
 * Digital Journalism Style Guide of Inclusive Language - Language Please



Lectures complémentaires

 * "UK NCSC to stop using 'whitelist' and 'blacklist' due to racial stereotyping", ZDNet (2020)
 * "‘Master/Slave’ Terminology Was Removed from Python Programming Language", Vice (2018)
 * "“Blacklists” and “whitelists”: a salutary warning concerning the prevalence of racist language in discussions of predatory publishing", Journal of the Medical Library Association (2018)
 * "Racism in the English Language", Robert B. Moore (1976)
 * "Is the English Language Anybody's Enemy?", ETC: A Review of General Semantics (1975)
 * "The Racist Use of the English Language", Journal of Black Studies and Research (1973)
 * "That Word Black", Langston Hughes (1958)
 * "Use This Rubric for More Inclusive Language, and Other Actions for Allies", Better Allies® blog (2020)