Allowlist and disallowlist are not English.

Yes I know this is what Drupal did but it doesn't change the facts.

The opposite of allow is deny

List is not a suffix it is a new word.

On a personal note this is not the same as master/slave which has historically racist meaning. Blacklist refers to a black colour book.

@bembelimen PHPCS errors reported by Drone: https://ci.joomla.org/joomla/joomla-cms/33260/1/9

Allowlist and disallowlist are not English.

Yes I know this is what Drupal did but it doesn't change the facts.

The opposite of allow is deny

List is not a suffix it is a new word.

Thanks for your correction, as non-native speaker it's sometimes not easy to hit the difference. My thoughts were: I allow tags/attributes or I disallow them. What would you suggest as proper wording?

On a personal note this is not the same as master/slave which has historically racist meaning. Blacklist refers to a black colour book.

I can't judge for others if someone is offended or not as I'm not affected, I was asked to create a PR, so I'm open for the best solution for everyone.

"allow list" and "deny list"

blacklist & whitelist are long standing industry terms and not the least bit racially related.

@N6REJ and the industry is increasingly moving away from these terms:

PHP is discussing removing the terminology: https://externals.io/message/110515#110515

PHPUnit has removed the terminology: sebastianbergmann/phpunit@fe9223c#diff-7c9432f8518d7bc639d398ad1f994711

Whether you agree with the racial link or not the industry is moving away from the term so it's not really a reason either.

• I suggest for our tags using the term blocked list - two advantages - one is that it's actually describing what's happening. But secondly we can still use the abbreviation BL in our code without making any b/c breaks :)
• For workflows I'd use "Excluded Extensions"

I have tested this item ? unsuccessfully on 383b805

Logging a number of identified issues and examples in further comments.

Also based on the above discussion, @bembelimen is there additional changes to be made to some of the default wording values?

There's some other grammar items I've spotted looking at the files list.

I doubt any instances have been missed in applying the blacklists, but without significantly testing actual values, it's hard to check all of that.

The few language suggestions that I'm making clarify the purposes of the fields or what the allow/disallow lists are doing.

I agree with @wilsonge on the better terminology pairings: "Allow List" and "Blocked List" as blocking vs disallowing are slightly different terms, and blocking is what the lists are doing.

Will leave someone to make a final decision on this for the desired combination.

Currently the reviewed code has "Allow List" and "Disallow List" now throughout - matching the language tags. Also follows familiar terminology used in Robots.txt.

@wilsonge should it be "Blocked List" in which case I'm happy to go through and review my review.

@bembelimen once review has been accepted I'll then test again.

I think, if this happens, it should be made from scratch again to cover the new suggestion from Brian.

Probably @particthistle you want to give it a try?

Someone can feel free to open an RFC discussion to put forward an agreed upon linguistic standard to use, and then we can build this again.

I just spent some time looking at this and it will never be a simple search and replace. After thinking about it for a while I think in most cases it will be enough to just changed to allowed and forbidden but there will be some occasions where for linguistic reasons it will need to be allowed list and forbidden list

The second issue is should this be everywhere or just in the visible strings. Everywhere means changing comments and variable names and to me the time to do that has now passed. But some might argue that if you still have a variable called $blacklist then you're not really desensitizing the language.

If @wilsonge and @bembelimen can make a decision on that I can easily do the work

Changing the variable names it self is not the problem but the b/c break that can happen if they are public, also formfields are hard to change and have to be migrated (or both fields are considered till 5.0).