Enhancement: Update language used for blacklist/whitelist

[williamdenton]

In raising this issue, I confirm the following:

• I have read and understood the contributors guide.
• The issue I am reporting can be replicated.
• The issue I am reporting isn't a duplicate (see FAQs, closed issues, and open issues).

How familiar are you with the the source code relevant to this issue?: 1

---

Expected behaviour:

Concise yet descriptive terms used for lists of ip addresses/hostnames rather than colors blackList denyList and whiteList allowList

Actual behaviour:

Words that have become socially unacceptable, regardless of their roots, being used to describe a list of domains/ip addresses that are permitted or denied access

---

I've opened this issue on this repo (being the UI for Pi-Hole), but these terms are used through out the code base. I suggest starting in the UI as it has the most visible impact immediately.

However this language must be updated through-out the code base, this shouldn't be just a skin deep change. Changing APIs and configuration will take time and a major version bump, but it may be able to be done in such a way that it remains functional, but deprecated, until the following major version.

[yubiuser]

You might want to support:
https://discourse.pi-hole.net/t/change-blacklist-and-whitelist-terminology/31657

[andrewlow]

I can see by looking at the code the terms are fairly deeply embedded, both in the UI code - as well as the APIs.

However - would there be any interest in a simple "ui only" fix to this issue?

It seems trivial to modify the display name from Whitelist to Allowlist here: https://github.com/pi-hole/AdminLTE/blob/989e1ba0ca9f31570ea92a3139211d83cdcbd344/scripts/pi-hole/php/header.php#L454

This would NOT change the link groups-domains.php?type=white which would take you to the configuration page.

However, we can further address that landing page by adding a little work-around logic to the use of the type to define the words used in the UI. https://github.com/pi-hole/AdminLTE/blob/989e1ba0ca9f31570ea92a3139211d83cdcbd344/groups-domains.php#L13

I'd imagine it wouldn't be hard to set the variables $pagetitle and $adjective to the more acceptable "Allowlist" and "allowlisted"

These two changes would at least show some progress towards using improved language.

If there is agreement that this is an acceptable path - I'd be happy to create a PR.

[andrewlow]

Ah - there seem to be a number of other 'cosmetic' uses of the term Whitelist which should probably also be included in the same PR.
https://github.com/pi-hole/AdminLTE/blob/989e1ba0ca9f31570ea92a3139211d83cdcbd344/scripts/pi-hole/js/queries.js#L112
https://github.com/pi-hole/AdminLTE/blob/7e602e0df4c28e093afeedee27a205209f1f5104/scripts/pi-hole/js/db_queries.js#L203
https://github.com/pi-hole/AdminLTE/blob/989e1ba0ca9f31570ea92a3139211d83cdcbd344/scripts/pi-hole/js/auditlog.js#L72
etc..

This is a little bit of a search/replace exercise - and of course testing. However, the main point of my comments here is to determine if simply making cosmetic changes (for now at least) is acceptable.

[DL6ER]

Pi-hole v6.0 is currently under development. The terms white/black has been replaced a long time ago in these branches (even before this started to be a political debate) because we were redesigning the API from scratch and these terms simply felt better because they describe what is actually going on without depending on metaphors. Check out AdminLTE#new/FTL_is_my_new_home.

We're only recently seen in other projects that metaphors are a bad thing, e.g. the popular K9 mail that had to replace the "floppy disk" icon from the attachment download because young users have no clue what a floppy disk even is. That's how things evolve, I guess. Hence, it's better to live without any kind of assumptions on what users may or not conclude from pictures.

Hence, I'd say its not worth doing the replacements now, even more because doing it cosmetically on the surface but not in the API really feels half-hearted, quoting the original poster above:

this shouldn't be just a skin deep change

At the same time, we cannot do it in the API right now because this would break a lot of user-provided scripts. Hence, the right time for doing this is a major version change, signaling that backwards compatibility may be broken. This is exactly what Pi-hole v6.0 will do with its brand-new all-JSON API. Your offer to open a PR is appreciated, however, I don't think it's worth investing the time right now. Because it has already long been done in v6.0 which is not that far in the future.

[andrewlow]

Thank you for taking the time to read and respond to this.

I hadn't come across the v6.0 work in progress - I agree that is the best way to address the issue.

I see that the terms 'allow' and 'deny' are being used. Has 'deny' been used consistently? I know that the current top level UI shows 'blocklist' which is also a sensible naming.

[DL6ER]

It is still somewhat in the state of flux. The two dedicated list pages are gone and there is a new common domain management page from where domains can also easily be switched from allowed to denies forth and back. This is how this page currently looks like:

And this is how the menu currently looks like:

But, as I said, nothing is set into stone right now.

[andrewlow]

That looks good - my comment about the consistency of 'deny' vs. 'block' is based on the current WebUI landing page

There is also plenty of documentation about pi-hole that talks about it being an 'ad blocker'.

I agree that allowlist / denylist are sensible choices.

However if we opted to use allowlist / blocklist that might reduce the vocabulary being used.
You would allow a domain name or block a domain name.

Of course - you're doing the work - I'm just armchair coding here.

[DL6ER]

However if we opted to use allowlist / blocklist that might reduce the vocabulary being used.

In the Pi-hole universe, blocklist a third item - they are the lists downloaded by gravity from some upstream source. They are the primary source for blocked domains. Allowed domains overwrite them and denied domains add you own domains on top.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.