Rename GenderNeutralCommentSniff to InclusiveLanguageSniff and scan code and make wordlist configurable

Created on 12 June 2020, about 5 years ago
Updated 19 May 2025, about 1 month ago

Problem/Motivation

Lets scan for the usage of "blacklist" and "whitelist" in code.

They are:

  • An historic bad labeling of people
  • Provide no context: "what is listed in them"?

While we're at it, let's make sure we only have the single reference to "slave" in core/assets/scaffold/files/default.settings.php (where it refers to the DB docs that unfortunately still use that language).

Proposed resolution

Rename GenderNeutralCommentSniff to InclusiveLanguageSniff and scan code and make wordlist configurable

Configure to also warn on:

  • blacklist
  • whitelist
  • slave

Remaining tasks

  1. Implement proposal.
  2. Reviews.
  3. RTBC.
  4. Commit.
  5. New release of coder.

User interface changes

None

API changes

@todo

Data model changes

@todo

Release notes snippet

@todo

πŸ“Œ Task
Status

Active

Version

3.0

Component

Review/Rules

Created by

πŸ‡¬πŸ‡§United Kingdom alexpott πŸ‡ͺπŸ‡ΊπŸŒ

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡³πŸ‡ΏNew Zealand quietone

    Changing to a related issue because closing the core issue isn't dependent on this one.

    Core will need an issue when this is fixed.

  • πŸ‡¦πŸ‡ΉAustria klausi πŸ‡¦πŸ‡Ή Vienna

    We use cspell now to check for spelling, so another approach would be to add more bad flagWords into core's .cspell.json file. But I think that has the downside that it would not propagate to Drupal contrib projects, they would have to add the same flagWords to their cspell config? Not sure how the cspell gitlab job works.

    So a sniff in Coder could be the more universal approach.

  • πŸ‡¬πŸ‡§United Kingdom jonathan1055

    Hi Klausi,
    Actually we have just implemented a solution for all Contrib for this, just like core (actually a bit better). We have added not only "blacklist" and "whitelist" but also "blacklists", "blacklisted", "whitelists" and "whitelisted" to the flagWords array in the default .cspell.json which every Contrib project will automatically (except the 117 projects that have their own custom .cspell.json). For these projects they will get an advisory message in the log saying that these words should be added to their custom file. We also used the cpell syntax to give suggested alternatives 'blocklist', 'denylist' and 'allowlist'.The issue is πŸ“Œ Add blacklist and whitelist to flagWords Active and here is the Change Record β†’ .

    We do actually have a mechanism already in place to automatcally add words (or make any changes) to a project's existing custom file before the job runs, but in this case we took the decision not to 'force-add' these words as it was thought we should respect the projects file and settings. But thinking about it again, we could always automatically add the flagwords by default but allow an opt-out for the rare occasions when to clean up a project is not feasable. Although we document how to ignore specific lines, in the issue Change Record.

    So I would be in favor of adding a follow-up issue in Gitlab Templates to make this change even effect the 117 projects with a custom config.

  • πŸ‡ΊπŸ‡ΈUnited States dww

    Should this now be β€œClosed (outdated)”?

  • πŸ‡¦πŸ‡ΉAustria klausi πŸ‡¦πŸ‡Ή Vienna

    Agreed - please put any bad words in the cspell config of Drupal core and the cspell config of the gitlab template.

  • πŸ‡¬πŸ‡§United Kingdom jonathan1055

    Following my thoughts in #8 I have opened πŸ“Œ Add core flagWords even when project has a custom .cspell.json Active so that even those contrib projects that have their own .cspell.json will be alerted for use of these flagged words.

Production build 0.71.5 2024