Feature Request: Profanity filter

[jazzsequence]

Something that's been buzzing around in my head lately is adding a parameter that acts as a profanity filter. I end up using Delorean Ipsum as my defacto placeholder text, and occasionally I'm demoing Delorean Ipsum content on client-facing sites or screenshares. I don't always remember to check for profanity before I demo.

Back to the Future doesn't drop f-bombs, but there are a few lesser swear words in there and it would be good to filter those out or exclude those blocks of dialog if a profanity filter was toggled.

Considerations There's basically two ways I see of handling this:

1. Create an alternate string of text that censors the word via replacement or **** (I'm not a huge fan of stars or dashes, though). If the profanity filter is on, and an alternate "clean" string exists, return that... or
2. Highlight the strings (via some identifier in the string) that have profanity and, if the filter is toggled, omit those strings.

The filter itself would just be another parameter to pass to the main js.

If I get some spare time on my hands, I'll work on a PR but I wanted to throw this out there as a sort of statement of intent.

[polevaultweb]

@jazzsequence good idea, this has been mentioned a few times. I think if we can do a search for the words we want to replace and then hold them in a profanity array, which we can then replace out if an argument is used for clean text.

[jazzsequence]

Part of my thinking with an alternate string was that many of the strings are lines of dialog consisting of multiple sentences, and my thought was that you wouldn't necessarily just want to strip (or even replace) the single word in a line, but you might want to still return part of the line in some form. But perhaps this opens up a somewhat broader discussion around how the strings are handled generally and whether it's worth breaking up some of the lines into multiple strings where several sentences are part of a single string.

That said, as an MVP, a profanity array and omitting the string if found is a first start that wouldn't conflict with refactoring the strings if that becomes a thing. It felt like doing something like that would be a bit restrictive since you'd be limiting a lot of content (e.g. the difference between turning "Damn, where is that kid?" into "Where is that kid?" as opposed to not returning that string at all).