-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inclusive renaming for --whitelist and whitelist.txt #44
Comments
I would definitely be up for this and its been at the back of my mind to introduce anyway. I cant give a timeline for when I would have the chance to work on this though. Would you like to give a go? It shouldnt be too difficult to figure it out :) |
Hi, do you need support on this one? I recently found this package and I'd be interested in changing the term "whitelist" :) I saw some effort done here #55 (comment), but it looks like those were not merged? If you have some suggestions how to go about this change, I'm happy to contribute. |
Hello @mt-krainski, reality is I just dropped the ball on those PRs and should follow up on them. I'm happy for you to take help push this forward if you have the motivation to do so :) I think we could even not worry about backwards compatibility by just marking the next version as a major version change along with a warning in the changelog. |
I opened #92; I changed the default Please let me know if you have any comments, I'm happy to adjust the PR as needed. |
As the spellcheck "whitelist.txt" file is generally a dictionary of allowed terminology within the codebase, could allowdict.txt, allowterm.txt or allowlist.txt be used instead of whitelist naming?
For non-breaking changes, whitelist.txt could remain as a backwards-compatible default and be used in the code but not in the documentation. A double-default would be required to fall back to the older version. Terminology used within the project documentation could be the renamed file.
If this is something the projects authors are interested in I could take a crack at making this change.
In either case, as an improvement to the documentation, the readme could note the way to change the default whitelist.txt file using --whitelist parameters.
The text was updated successfully, but these errors were encountered: