[meta] Remove usage of "blacklist", "whitelist", use better terms instead

Thank you so much for opening the issue! 👏🏽I would kind of argue this is more of a task than a feature request.

1. +++ b/core/core.services.yml
   @@ -442,14 +442,14 @@ services:
   -  path.alias_whitelist:
   -    class: Drupal\Core\Path\AliasWhitelist
   

   We need to keep the old service around. You can use something like ``` deprecated: The "%service_id%" service is deprecated. You should use the 'router.no_access_checks' service instead.``` though to mark it as deprecated

2. +++ b/core/includes/file.inc
   @@ -712,7 +712,7 @@ function file_munge_filename($filename, $extensions, $alerts = TRUE) {
    
   -    $whitelist = array_unique(explode(' ', strtolower(trim($extensions))));
   +    $allowlist = array_unique(explode(' ', strtolower(trim($extensions))));
    
        // Split the filename up by periods. The first part becomes the basename
        // the last part the final extension.
   @@ -727,7 +727,7 @@ function file_munge_filename($filename, $extensions, $alerts = TRUE) {
   
   @@ -727,7 +727,7 @@ function file_munge_filename($filename, $extensions, $alerts = TRUE) {
        // of allowed extensions.
        foreach ($filename_parts as $filename_part) {
          $new_filename .= '.' . $filename_part;
   -      if (!in_array(strtolower($filename_part), $whitelist) && preg_match("/^[a-zA-Z]{2,5}\d?$/", $filename_part)) {
   +      if (!in_array(strtolower($filename_part), $allowlist) && preg_match("/^[a-zA-Z]{2,5}\d?$/", $filename_part)) {
            $new_filename .= '_';
   

   For sake of reviewing I could imagine that a core committer would suggest to to the variable/string renaming after renaming of classes, given the review scope / risk is different

3. +++ b/core/lib/Drupal/Core/Extension/Discovery/RecursiveExtensionFilterIterator.php
   @@ -38,7 +38,7 @@ class RecursiveExtensionFilterIterator extends \RecursiveFilterIterator {
   -  protected $whitelist = [
   +  protected $allowlist = [
        'profiles',
        'modules',
        'themes',
   @@ -53,7 +53,7 @@ class RecursiveExtensionFilterIterator extends \RecursiveFilterIterator {
   
   @@ -53,7 +53,7 @@ class RecursiveExtensionFilterIterator extends \RecursiveFilterIterator {
       *
       * @var array
       */
   -  protected $blacklist = [
   +  protected $denylist = [
   

   Note: Protected variables can be just renamed in a minor release, which seems to be the right focus for this anyway :)

4. +++ b/core/lib/Drupal/Core/Path/AliasManager.php
   @@ -277,15 +277,15 @@ public function cacheClear($source = NULL) {
   -  protected function pathAliasWhitelistRebuild($path = NULL) {
   -    // When paths are inserted, only rebuild the whitelist if the path has a top
   -    // level component which is not already in the whitelist.
   +  protected function pathAliasAllowlistRebuild($path = NULL) {
   

   I could imagine that we would like to have a BC layer for this renamed function as well

5. +++ b/core/lib/Drupal/Core/Path/AliasWhitelist.php
   @@ -2,119 +2,10 @@
   + *
   + * @deprecated
   ...
   +class AliasWhitelist extends AliasAllowlist {
    }
   
   +++ b/core/lib/Drupal/Core/Path/AliasWhitelistInterface.php
   @@ -2,14 +2,14 @@
   + * The allowlist contains the first element of the router paths of all
     * aliases. For example, if /node/12345 has an alias then "node" is added to
   - * the whitelist. This optimization allows skipping the lookup for every
   - * /user/{user} path if "user" is not in the whitelist.
   + * the allowlist. This optimization allows skipping the lookup for every
   + * /user/{user} path if "user" is not in the allowlist.
   + *
   + * @deprecated
     */
   -interface AliasWhitelistInterface extends CacheCollectorInterface {}
   +interface AliasWhitelistInterface extends AliasAllowlistInterface {}
   

   Let's trigger a deprecation notice + document the deprecation, see https://www.drupal.org/core/deprecation

6. +++ b/core/lib/Drupal/Core/Security/RequestSanitizer.php
   @@ -17,9 +17,9 @@ class RequestSanitizer {
   -   * The name of the setting that configures the whitelist.
   +   * The name of the setting that configures the allowlist.
       */
   -  const SANITIZE_WHITELIST = 'sanitize_input_whitelist';
   +  const SANITIZE_WHITELIST = 'sanitize_input_allowlist';
    
      /**
   

   We could introduce an additional constant as well, and somehow deprecate the old one

An issue summary would be nice so adding the tag.

I have one question though 'blacklist' and 'whitelist' can be used as verbs like 'blacklisted' and 'whitelisted' now the verb form for 'allowlist' would be allowedlist or 'allowlisted' and 'denylist' would be 'denylisted' or 'deniedlist'? All I'm trying to say is, 'black' and 'white' are nouns and 'allow' and 'deny' are verbs we should be replacing those words with nouns. FWIW, my browser is underlining 'allowlist' and 'denylist' because they are not real words. Is it time to update the dictionary?

@jibran Good to bring up writing guidelines! I stared at your comment for a few seconds, baffled, and then your own very simple explanation hit me: can we just use "allow" and "deny" for the verbs? The list itself is more of an implementation detail than a description of what's supposed to happen. So we'd get something like "Anyone/anything on the allowlist is granted/allowed access, and anyone on the denylist is denied access".

Considering the complexity of rewriting such anchored terms (you may remember our efforts to improve on "master" and "slave"), what can we do to communicate this to translators too? In Dutch, for example, the term "blacklist" is used, but "whitelist" is not. It may be less obvious to Dutch translators that they may want to find an alternative anyway, despite the difference in perception across languages and cultures. This is also why I added the Needs change record tag. We can use that to explain the rationale, and provide people with information and instructions to address this issue in their code and translations.

@Xano I think you missed my point. All I meant was, how do we rephrase something like IP address: %s has been blacklisted. Please contact admin to get it whitelisted.

At the risk of missing it again: "IP address: %s has been denied. Please contact admin for access."? Admittedly, I cheated by avoiding having to translate "whitelist" altogether.

While talking with @alexpott about this particular issue we concluded that instead of introducing "denylist" and "allowlist", which are not real worlds, we could instead find real words depending on the domain.

For example whitelist in the context of XSS could be allowedTags.

This updated all remaining entries.

Tagging for DrupalNorth 2019

Tagging for DrupalCamp Colorado Contrib day (Sunday August 4)

Tagging for badcamp2019, thanks! (October 2-5)

I think in order to do this we need to break this issue up into separate manageable tasks.

• Replace use of whitelist/blacklist in the path alias module
• Replace use of whitelist/blacklist in file_munge_filename()
• Replace use of whitelist/blacklist in \Drupal\Component\Utility\Xss and its test and core/lib/Drupal/Core/Render/theme.api.php
• Replace use of whitelist/blacklist in \Drupal\Core\Extension classes and their tests
• Replace use of whitelist/blacklist in \Drupal\Core\Security\RequestSanitizer and its test
• Replace use of whitelist/blacklist in \Drupal\Core\Template classes and their tests
• Replace use of whitelist/blacklist in \Drupal\Core\Utility\Error and its test
• Replace use of whitelist/blacklist in \Drupal\Core\Utility\ProjectInfo and its test
• Replace use of whitelist/blacklist in core/misc/autocomplete.es6.js and core/modules/link/src/Plugin/Field/FieldWidget/LinkWidget.php
• Replace use of whitelist/blacklist in Big Pipe module
• Replace use of whitelist/blacklist in CkEditor and Editor modules
• Replace use of whitelist/blacklist in Filter module
• [Coder issue] Rename GenderNeutralCommentSniff to InclusiveLanguageSniff and scan code and make wordlist configurable

This issue can then enable the updated PHPCS rule for core.

Sad I never found this issue earlier, and happy to see it getting new life now! Very timely. Huge +1000 to this.

Let's hope we've evolved enough as a community that there's no aggressive pushback on this like there was at #343414: Rename "master/slave" terminology to "client/server" or #2275877: Replace "master/slave" terminology with "primary/replica". 🤞🖤✊

I'll help as many child issues as I can.

Thanks!
-Derek

Sadly, we are starting to get some pushback. Amazing. So it's more easily shared across this whole effort, here's a copy of my reply:

- - -

So the burden of explaining the racist implications of "whitelist" equaling the good things you want to keep and the "blacklist" being the bad things you want to skip or prohibit doesn't have to fall to someone of color, I'll take a moment to provide some references for further reading:

“Blacklists” and “whitelists”: a salutary warning concerning the prevalence of racist language in discussions of predatory publishing:
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6148600

This commentary addresses the widespread use of racist language in discussions concerning predatory publishing. Examples include terminology such as blacklists, whitelists, and black sheep. The use of such terms does not merely reflect a racist culture, but also serves to legitimize and perpetuate it.

Terminology: it's not black and white:
https://www.ncsc.gov.uk/blog-post/terminology-its-not-black-and-white

It only makes sense if you equate white with 'good, permitted, safe' and black with 'bad, dangerous, forbidden'. There are some obvious problems with this. So in the name of helping to stamp out racism in cyber security, we will avoid this casually pejorative wording on our website in the future. No, it's not the biggest issue in the world - but to borrow a slogan from elsewhere: every little helps.
...
You may not see why this matters. If you're not adversely affected by racial stereotyping yourself, then please count yourself lucky. For some of your colleagues (and potential future colleagues), this really is a change worth making.

UK Cybersecurity Agency Drops 'Blacklist' and 'Whitelist' Terms Over Racial Stereotyping:
https://www.pcmag.com/news/uk-cybersecurity-agency-drops-blacklist-and-w...

The words “blacklist” and “whitelist” get tossed around a lot in cybersecurity. But now a UK government agency has decided to retire the terminology due to the racial stereotyping the language can promote.
...
Emma W. added: “Finally, a word from the NCSC's Technical Director Ian Levy (supported by the full NCSC Management Board): ‘If you’re thinking about getting in touch saying this is political correctness gone mad, don’t bother.’”

Everyday words and phrases that have racist connotations:
https://www.cnn.com/2020/07/06/us/racism-words-phrases-slavery-trnd/inde...

Many are so entrenched that Americans don't think twice about using them. But some of these terms are directly rooted in the nation's history with chattel slavery. Others now evoke racist notions about Black people.

No More Inflammatory Jargon: Change Blacklist To Blocklist:
https://www.adexchanger.com/data-driven-thinking/no-more-inflammatory-ja...

He explained that it didn’t matter that the etymology of the terms had nothing to do with racism. The term blacklist was first used in the early 1600s to describe a list of those who were under suspicion and thus not to be trusted, he explained. But regardless of the words’ origins, my colleague went on to impress upon me the discomfort he felt everyday living in a world where black was equated with bad and white with good.

Hope you take time to try to imagine the world through someone else's eyes and see if that might change your perspective.

Thanks,
-Derek

@dww, thanks for the links.

Adding the links to resources from the previous comment to the IS.

Pressing save so the issues in the issue summary are the right status.

Re-saving since #3151093: Replace use of whitelist/blacklist in \Drupal\Core\Security\RequestSanitizer and its test is no longer postponed.

We're getting close!

Yay,
-Derek

Tagging for upcoming contribution day at GovCon2020, dates Sept 23-25.
Thanks!

Current stats of the 9.2.x branch for anyone curious:

$ grep -ri 'whitelist' . | wc -l
163
$ grep -ri 'blacklist' . | wc -l
      53

After applying the patches in #3151086: Replace use of whitelist/blacklist in the path_alias module, #3151097: Replace use of whitelist/blacklist in core/misc/autocomplete.js and LinkWidget.php, #3151100: Replace use of whitelist/blacklist in CkEditor and Editor modules:

$ grep -ri 'whitelist' . | wc -l
      54
$ grep -ri 'blacklist' . | wc -l
      22

Remaining for "whitelist" are:

./core/core.api.php: *   arguments: ['@path_alias.repository', '@path_alias.whitelist', '@language_manager']
./core/tests/Drupal/Tests/Core/Security/RequestSanitizerTest.php:   * @param array $whitelist
./core/tests/Drupal/Tests/Core/Security/RequestSanitizerTest.php:   *   An array of keys to whitelist and not sanitize.
./core/tests/Drupal/Tests/Core/Security/RequestSanitizerTest.php:  public function testRequestSanitization(Request $request, array $expected = [], array $expected_errors = NULL, array $whitelist = []) {
./core/tests/Drupal/Tests/Core/Security/RequestSanitizerTest.php:    $request = RequestSanitizer::sanitize($request, $whitelist, is_null($expected_errors) ? FALSE : TRUE);
./core/tests/Drupal/Tests/Core/Security/RequestSanitizerTest.php:    $tests['recursive no sanitization whitelist'] = [$request, ['query' => ['q' => 'index.php', 'foo' => ['#bar' => 'foo']]], [], ['#bar']];
./core/tests/Drupal/Tests/Core/Security/RequestSanitizerTest.php:    $tests['no sanitization POST whitelist'] = [$request, ['request' => ['#field' => 'value']], [], ['#field']];
./core/tests/Drupal/Tests/Core/Security/RequestSanitizerTest.php:    $tests['destination whitelist'] = [$request, ['query' => ['destination' => 'whatever?q[%23test]=value']], [], ['#test']];
./core/tests/Drupal/Tests/Core/Template/TwigSandboxTest.php:   * Currently the following methods are whitelisted: id, label, bundle, and
./core/tests/Drupal/Tests/Core/Site/SettingsTest.php:        'sanitize_input_whitelist',
./core/tests/Drupal/Tests/Core/Site/SettingsTest.php:        'The "sanitize_input_whitelist" setting is deprecated in drupal:9.1.0 and will be removed in drupal:10.0.0. Use Drupal\Core\Security\RequestSanitizer::SANITIZE_INPUT_SAFE_KEYS instead. See https://www.drupal.org/node/3163148.',
./core/tests/Drupal/Tests/Core/Site/SettingsTest.php:        'twig_sandbox_whitelisted_classes',
./core/tests/Drupal/Tests/Core/Site/SettingsTest.php:        'The "twig_sandbox_whitelisted_classes" setting is deprecated in drupal:9.1.0 and is removed from drupal:10.0.0. Use "twig_sandbox_allowed_classes" instead. See https://www.drupal.org/node/3162897.',
./core/tests/Drupal/Tests/Core/Site/SettingsTest.php:        'twig_sandbox_whitelisted_methods',
./core/tests/Drupal/Tests/Core/Site/SettingsTest.php:        'The "twig_sandbox_whitelisted_methods" setting is deprecated in drupal:9.1.0 and is removed from drupal:10.0.0. Use "twig_sandbox_allowed_methods" instead. See https://www.drupal.org/node/3162897.',
./core/tests/Drupal/Tests/Core/Site/SettingsTest.php:        'twig_sandbox_whitelisted_prefixes',
./core/tests/Drupal/Tests/Core/Site/SettingsTest.php:        'The "twig_sandbox_whitelisted_prefixes" setting is deprecated in drupal:9.1.0 and is removed from drupal:10.0.0. Use "twig_sandbox_allowed_prefixes" instead. See https://www.drupal.org/node/3162897.',
./core/tests/Drupal/Tests/Component/Utility/XssTest.php:      // Only whitelisted scheme names allowed in attributes.
./core/tests/Drupal/KernelTests/Core/Theme/TwigWhiteListTest.php:class TwigWhiteListTest extends KernelTestBase {
./core/tests/Drupal/KernelTests/Core/Theme/TwigWhiteListTest.php:  public function testWhiteListChaining() {
./core/lib/Drupal/Core/Security/RequestSanitizer.php:  const SANITIZE_WHITELIST = 'sanitize_input_whitelist';
./core/lib/Drupal/Core/Site/Settings.php:    'sanitize_input_whitelist' => [
./core/lib/Drupal/Core/Site/Settings.php:      'message' => 'The "sanitize_input_whitelist" setting is deprecated in drupal:9.1.0 and will be removed in drupal:10.0.0. Use Drupal\Core\Security\RequestSanitizer::SANITIZE_INPUT_SAFE_KEYS instead. See https://www.drupal.org/node/3163148.',
./core/lib/Drupal/Core/Site/Settings.php:    'twig_sandbox_whitelisted_classes' => [
./core/lib/Drupal/Core/Site/Settings.php:      'message' => 'The "twig_sandbox_whitelisted_classes" setting is deprecated in drupal:9.1.0 and is removed from drupal:10.0.0. Use "twig_sandbox_allowed_classes" instead. See https://www.drupal.org/node/3162897.',
./core/lib/Drupal/Core/Site/Settings.php:    'twig_sandbox_whitelisted_methods' => [
./core/lib/Drupal/Core/Site/Settings.php:      'message' => 'The "twig_sandbox_whitelisted_methods" setting is deprecated in drupal:9.1.0 and is removed from drupal:10.0.0. Use "twig_sandbox_allowed_methods" instead. See https://www.drupal.org/node/3162897.',
./core/lib/Drupal/Core/Site/Settings.php:    'twig_sandbox_whitelisted_prefixes' => [
./core/lib/Drupal/Core/Site/Settings.php:      'message' => 'The "twig_sandbox_whitelisted_prefixes" setting is deprecated in drupal:9.1.0 and is removed from drupal:10.0.0. Use "twig_sandbox_allowed_prefixes" instead. See https://www.drupal.org/node/3162897.',
./core/phpunit.xml.dist:    <whitelist>
./core/phpunit.xml.dist:     </whitelist>
./core/modules/migrate_drupal/tests/fixtures/drupal7.php:  'name' => 'path_alias_whitelist',
./core/modules/locale/locale.compare.inc:    $additional_whitelist = [
./core/modules/locale/locale.compare.inc:    $project_info->processInfoList($projects, $module_data, 'module', TRUE, $additional_whitelist);
./core/modules/locale/locale.compare.inc:    $project_info->processInfoList($projects, $theme_data, 'theme', TRUE, $additional_whitelist);
./core/modules/path/tests/src/Functional/PathAliasTest.php:    // Check the path alias whitelist cache.
./core/modules/path/tests/src/Functional/PathAliasTest.php:    $whitelist = \Drupal::cache('bootstrap')->get('path_alias_whitelist');
./core/modules/path/tests/src/Functional/PathAliasTest.php:    $this->assertTrue($whitelist->data['node']);
./core/modules/path/tests/src/Functional/PathAliasTest.php:    $this->assertFalse($whitelist->data['admin']);
./core/modules/workspaces/src/FormOperations.php:    // for the whitelisted ones defined below.
./core/modules/workspaces/src/FormOperations.php:    // Whitelist a few forms that we know are safe to submit.
./core/modules/system/system.install:        $requirements['php_random_bytes']['description'] = t('Drupal is unable to generate highly randomized numbers, which means certain security features like password reset URLs are not as secure as they should be. Instead, only a slow, less-secure fallback generator is available. The most likely cause is that open_basedir restrictions are in effect and /dev/urandom is not on the whitelist. See the <a href=":drupal-php">system requirements</a> page for more information. %exception_message', $args);
./core/modules/path_alias/path_alias.services.yml:    arguments: ['@path_alias.repository', '@path_alias.whitelist', '@language_manager', '@cache.data']
./core/modules/path_alias/path_alias.services.yml:  path_alias.whitelist:
./core/modules/path_alias/src/AliasManager.php:   * @param \Drupal\path_alias\AliasWhitelistInterface $path_prefixes
./core/modules/path_alias/src/AliasManager.php:  public function __construct($alias_repository, AliasWhitelistInterface $path_prefixes, LanguageManagerInterface $language_manager, CacheBackendInterface $cache) {
./core/modules/path_alias/src/AliasWhitelist.php:class AliasWhitelist extends AliasPrefixList {}
./core/modules/path_alias/src/AliasWhitelistInterface.php:interface AliasWhitelistInterface extends AliasPrefixListInterface {}
./core/modules/editor/tests/src/Unit/EditorXssFilter/StandardTest.php.orig:    // whitelisted.
./core/assets/vendor/ckeditor/CHANGES.md:* #13316: predefined page vs story: what are they good for?(https://dev.ckeditor.com/ticket/13316): Made [`CKEDITOR.env.isCompatible`](https://ckeditor.com/docs/ckeditor4/latest/api/CKEDITOR_env.html#property-isCompatible) a blacklist rather than a whitelist. More about the change in the [Browser Compatibility](https://ckeditor.com/docs/ckeditor4/latest/guide/dev_browsers.html) guide.
./composer/Plugin/Scaffold/AllowedPackages.php:   * project must be explicitly whitelisted in the top-level composer.json
./composer/Plugin/Scaffold/AllowedPackages.php:   * project must be explicitly whitelisted in the top-level composer.json
Binary file ./.git/objects/pack/pack-0cdd2ad25c1f7ffc11cf8fed01f4f1b1c06e0a45.pack matches
Binary file ./.git/index matches

Remaining for "blacklist" are:

./core/misc/autocomplete.js:    if (term.length > 0 && options.firstCharacterBlacklist.indexOf(term[0]) !== -1) {
./core/misc/autocomplete.js:        var blacklist = $autocomplete.attr('data-autocomplete-first-character-blacklist');
./core/misc/autocomplete.js:          firstCharacterBlacklist: blacklist || ''
./core/misc/autocomplete.js:      firstCharacterBlacklist: '',
./core/tests/Drupal/KernelTests/KernelTestBase.php:  protected $backupStaticAttributesBlacklist = [
./core/tests/Drupal/KernelTests/KernelTestBase.php:    $blacklist = [];
./core/tests/Drupal/KernelTests/KernelTestBase.php:      $blacklist[$property->name] = $property->getDeclaringClass()->name;
./core/tests/Drupal/KernelTests/KernelTestBase.php:      if (!$property->isStatic() && !isset($blacklist[$property->name])) {
./core/modules/jsonapi/tests/src/Functional/CommentTest.php:    \Drupal::state()->set('jsonapi__entity_test_filter_access_blacklist', [$this->entity->getCommentedEntityId()]);
./core/modules/jsonapi/tests/src/Functional/CommentTest.php:    Cache::invalidateTags(['state:jsonapi__entity_test_filter_access_blacklist']);
./core/modules/jsonapi/tests/src/Functional/CommentTest.php:      $cacheability->addCacheTags(['state:jsonapi__entity_test_filter_access_blacklist']);
./core/modules/jsonapi/tests/src/Functional/EntityTestTest.php:      $cacheability->addCacheTags(['state:jsonapi__entity_test_filter_access_blacklist']);
./core/modules/jsonapi/src/Access/TemporaryQueryGuard.php:        $blacklist = \Drupal::state()->get('jsonapi__entity_test_filter_access_blacklist', []);
./core/modules/jsonapi/src/Access/TemporaryQueryGuard.php:        $cacheability->addCacheTags(['state:jsonapi__entity_test_filter_access_blacklist']);
./core/modules/jsonapi/src/Access/TemporaryQueryGuard.php:        foreach ($blacklist as $id) {
./core/modules/language/tests/src/Unit/process/LanguageDomainsTest.php:  protected $backupGlobalsBlacklist = ['base_url'];
./core/modules/workspaces/src/WorkspaceManager.php:  protected $blacklist = [
./core/modules/workspaces/src/WorkspaceManager.php:    if (isset($this->blacklist[$entity_type->id()])) {
./core/modules/workspaces/src/WorkspaceManager.php:    // This entity type can not belong to a workspace, add it to the blacklist.
./core/modules/workspaces/src/WorkspaceManager.php:    $this->blacklist[$entity_type->id()] = $entity_type->id();
./core/assets/vendor/ckeditor/CHANGES.md:* #13316: predefined page vs story: what are they good for?(https://dev.ckeditor.com/ticket/13316): Made [`CKEDITOR.env.isCompatible`](https://ckeditor.com/docs/ckeditor4/latest/api/CKEDITOR_env.html#property-isCompatible) a blacklist rather than a whitelist. More about the change in the [Browser Compatibility](https://ckeditor.com/docs/ckeditor4/latest/guide/dev_browsers.html) guide.
./core/assets/vendor/ckeditor/CHANGES.md:* #10276: Incorrect 'update_start' value in database.mysql(https://dev.ckeditor.com/ticket/10276): Introduced blacklisting in the [Allowed Content Filter](https://ckeditor.com/docs/ckeditor4/latest/guide/dev_advanced_content_filter.html).

Some of these are covered by and just missing from other issues, but it looks like we might need more sub-issues here:

- Core security tests
- Kernel tests
- JSON API
- Workspaces
- etc.

I notice a couple of upstream problems, for example PHPUnit. It looks like PHPUnit deprecated "whitelist" and "blacklist" in 9.3.0 https://github.com/sebastianbergmann/phpunit/blob/a0d6b21c6c8f6564212a1a... ... but I think I read elsewhere that we need to continue to support PHPUnit 8 until we don't support PHP 7.3 anymore...

Anyway, hope that helps. Thanks to everyone contributing to this initiative!

Great to see the progress on this. Thanks for making Drupal more inclusive.

It's actually been two years since any progress. I've split the child issues into 'to do' and 'done' to make it easier to focus on what is still remaining.

The last child issue has been committed! The related task, #3151102: Rename GenderNeutralCommentSniff to InclusiveLanguageSniff and scan code and make wordlist configurable, has a wider scope than this name change. Core is now using cspell to prevent future usages creeping back in. So, everything is done here.

Thank you to everyone who participated in having core use more inclusive language.

The Needs Review Queue Bot tested this issue.

While you are making the above changes, we recommend that you convert this patch to a merge request. Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)

Huzzah!

Very cool that #3470895: Add blacklist and whitelist to the list of flagwords has landed - imo that means this is fixed.

It is also "fixed" in Contrib too, see #3524087: Add blacklist and whitelist to flagWords for all Contrib CI