Inclusive language/fr

Nous voulons encourager une 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 avec 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 devant être mis à jour.

Some of these may be as simple as updating/improving comments and variable names.

Others may be more complex and need functions and hooks renaming, while following our.

Some usages may need to stay around for longer, but will generally stop being the canonical code, showing the intention for this to be removed in the near future.

Ressources

 * Manuels et documentation associées venant d'autres organisations (via cdanis et ietf qui en listent beaucoup d'autres)
 * 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)
 * 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"
 * 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

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)
 * "Abolish racist language", Intuit Content design blog (2021)
 * "Use This Rubric for More Inclusive Language, and Other Actions for Allies", Better Allies® blog (2020)