This would happen only in two ways, either the user ID is unique enough that when converted without being caught as a “bad” word in the process it turns into the ABCD
visual tag, or after converted, the visual tag deemed to have bad words (or look exactly like a bad word), even after checking it more than one time, resulting in the tag falling back to the ABCD
format.
I just deep dived into the comments plugin’s user ID into visual ID converting algorithm behind the scenes, that’s why I’m making a post related on this topic. Also, have you ever seen actual occurrences of tags like this happening on comments of generators? Share if you have one!
I want to learn more about what you said as, “bad” word.
The bad words (explicit, offensive, etc.) and their variations are compiled in a
rudeWords
array variable contained somewhere in the comments plugin engine which then used to check the converted tag against the words that are in the variable. It checks it three times before it eventually falls toABCD
since it still deemed to have these bad words after some more thorough conversions.In that code, the first three letters of the converted, unchecked string are being checked if there’s a bad word contained in the
rudeWords
variable. If it does, the string is converted again in a different way. But if that still have bad words inside, then the ID is reversed so it wouldn’t appear to have a bad word inside. But even if the double-checked ID still found to have bad words, then the engine decided to choose the fallback tagABCD
for the purpose. But this is an extremely rare case, most user IDs will turn out a fresh, unchecked visual ID which will mostly pass the first few bad word detection in the process.Note that
rudeWords
is aSet
in JavaScript, which is just like an array, but it has unique values inside and is a bit different from an array. That’s why it uses.has()
instead of.includes()
in an ordinary array. And the lowercase tag is then being converted to uppercase when being displayed in the comments.Cool. :O 👍