Provide inclusivity linting in automated testing for Drupal projects

Created on 12 April 2022, over 3 years ago
Updated 18 April 2023, about 2 years ago

This idea is not a Drupal *core* idea, strictly speaking, but it's a global testing policy idea that could likely use attention from the same sorts of folks who review these core ideas.

Background

There's been a movement recently in Drupal and in other software projects to move towards more inclusive language, for example, changing 'Master' branches to 'Main', and changing 'whitelist/blacklist' to 'allowlist/blocklist' and things of that nature.

Problem

The change to inclusive language is a good one, and for most projects it is relatively low effort, but many folks aren't necessarily aware of these issues in order to change them.

Proposed resolution

There are now automated 'inclusivity linting' tools that are available to catch this kind of language. If we can provide these as part of Drupal's automated testing defaults(even if their output produces 'warnings' rather than 'failures') this would be a good step in helping the community make these easy fixes.

@michaelemeyers β†’ and @fabianfranz β†’ from Tag1 have suggested we research libraries like woke and inclusivelint, which are both capable of producing output similar to the following:

% github-scanner lint .
config/sync/core.entity_view_display.node.custom_page.default.yml:61:7: undesirable term `blacklisted` found (terminology; phrase "black listed")
      blacklisted_blocks: {  }
      ^^^^^^^^^^^
config/sync/core.entity_view_display.node.custom_page.default.yml:62:7: undesirable term `whitelisted` found (terminology; phrase "white listed")
      whitelisted_blocks: {  }
      ^^^^^^^^^^^
l10n/drupal-9.3.5.es.po:26730:60: undesirable term `whitelist` found (terminology; phrase "white list")
"restrictions are in effect and /dev/urandom is not on the whitelist. "
                                                           ^^^^^^^^^
l10n/drupal-9.3.5.fr.po:26920:60: undesirable term `whitelist` found (terminology; phrase "white list")
"restrictions are in effect and /dev/urandom is not on the whitelist. "
                                                           ^^^^^^^^^
l10n/paragraphs-8.x-1.12.es.po:165:8: undesirable term `Master` found (terminology; string "master")
msgid "Master"
       ^^^^^^
l10n/paragraphs-8.x-1.12.fr.po:167:8: undesirable term `Master` found (terminology; string "master")
msgid "Master"
       ^^^^^^
2022/04/04 13:32:00 main.go:908: 6 errors found scanning .

Process and where to find it

Not yet defined.

Proposal roadmap

Not yet defined.

Not in scope

Automated patches/MRs.

Team and resources

Not yet defined.

Signoffs

TBD

Signoffs needed

TBD

Signoffs given

TBD

🌱 Plan
Status

Active

Component

Proposed Plan

Created by

πŸ‡ΊπŸ‡ΈUnited States hestenet Portland, OR πŸ‡ΊπŸ‡Έ

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.

  • πŸ‡ΊπŸ‡ΈUnited States hestenet Portland, OR πŸ‡ΊπŸ‡Έ

    It sounds like we can move this forward incrementally by starting with a core issue and an MR to update the Cspell forbidden words list with an initial pass.

    However, there is a tradeoff - Cspell can check everything, but can't do a custom error message to suggest an alternative, phpcs can check only code, but can do custom error messages.

    I guess the ideal case would be to somehow hook into the cspell error and offer help text if it exists, maybe in another piece of yaml?

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

    Moving this to the core queue.

    We already added whitelist/blacklist to flagWords after changing those to allow/denylist and similar equivalents in both comments and code - all of which turned out to be good technical changes in their own right.

    The only other technical concept that I think we could specifically avoid in core (off the top of my head) is master/slave where we already changed the terminology in the database API over a decade ago. I think we still have help text somewhere that references master/slave which might not be necessary now a lot of projects use replica and similar, but that can also be handle by cspell:ignore for specific cases.

Production build 0.71.5 2024