Text replacement plugins

I have three questions.

1. How do text replacement plugins work?
2. Why do they affect text entry fields as well as regular html content?
3. Would either a wishlist item or bug report to circumvent text replacement action in text entry fields be appropriate?

If text replacement action were blocked in specific text entry fields then text replacement plugins would no longer affect edits.

Could always have a warning pop up after registering saying "If your running text changers,turn them off NOW!" since its the new users who usually have it on

edited 31st Mar '16 4:02:31 AM by Ultimatum

1. By replacing text on a web page with different text when it is rendered.
2. Because their programmers don't bother to think of these things; they are too busy feeling edgy and clever.
3. There is no way to block every possible text-replacement plugin because you can't predict what will be altered next.

edited 31st Mar '16 5:02:26 AM by Fighteer

(1) I was guessing that they replace text when it is added to the HTML section. (2) But it would take more work, not less to also replace text in additional areas. (3) Are you talking about heuristic detection from what they replace? I am talking about blocking the mechanism. Which would be done without first detecting the plugin.

I am assuming this is possible. If text replacement replaced everything, then it would break websites by breaking links and messing with js code.

There are some fancy scripting tricks you can use to control the rendering and display of a web page on the user's end, but they tend to be somewhat expensive in terms of performance. It's something to look at as a tech issue, but Wikipedia deals with the same exact problem.

Would something like a pop up work?

"Hi,are you running a text replacement feature?—-yes—-Then turn it off!

Bonus points if they hit no,automatic ban if they are running one anyway

Isn't anyone caught using one suspended anyway?

^^Not reliable enough I'd say.

Anyhow, at a minimum for a tech based (possibly unreliable) solution we need a string of text, not overly long, that contains all "sensitive" words. Then we'd need to put it as "hidden" (i.e invisible to human readers) text on edit pages that is editable. If the page saves with that text string modified (by a plugin or bot) the save is rejected.

Or we could wrap the whole editing interface in a big chunk of HTML 5 or Javascript that loads the edit window content via AJAX or something to bypass the filters, but that does create a fairly imposing barrier for those who don't like or can't use such scripting.

edited 31st Mar '16 2:20:19 PM by Fighteer

Yeah, that one is definitively on the "can't be done" pile. Especially given the performance problems that would create.

So if the content of the edit window were loaded into the edit window from a compressed file after page load, the text replacer would still get it? This would make sense if the point of alteration is when the text is placed in the field. And also if the plugins monitor changes to the field and perform live replacement.

I would like to do some more research on these plugins, but google does not like my search terms. Do any of you know what these things are normally called?

edited 31st Mar '16 4:48:13 PM by war877

I actually think this is a really good idea. More often than not, the text replacers used are Cloud-to-Butt or Trump-to-Drumpf, so you literally only need to check those two words.

It would perhaps be possible to check all modified text and see if they contain one of those words, and if they do, check if they used to say what they replace. Basically one step more than a regular chat censor filter.

Another one that used to be a big problem around here was auto-Bowdlerising nannybots, so throw in a "fuck shit ass" or something.

SJW -> skeleton is also popular, but that hopefully doesn't come up much.

Well, we could embed every page with "cloud" and "Trump" but that's just a band-aid fix—and we can't predict when some dummy is going to replace "Superman" with "salad" or "night" with "nachos" because of reasons.

edited 1st Apr '16 8:27:01 PM by Rotpar

We do already have such a tool, or did. Eddie put in a hidden text field that gets submitted whenever you press Send on a wiki edit. It is clearly not reliable, and I don't think the current devs have been maintaining it. I'll see if they are interested in the project.

edited 1st Apr '16 9:46:28 PM by Fighteer

You want us to come up with a general solution to the problem of "text replacers exist"? Sure, let's fill the invisible text field with a copy of the entire pre-edit wikitext and block the edit if it's changed in any way.

... Actually, even though I typed that sarcastically, I wonder if that's a genuinely viable solution? Probably not, but I don't know enough about... whatever the relevant computer stuff would be.

You can add some very simple code to duplicate the text to make the outgoing bandwidth cost minimal. However, unless some trick of the way text replacers work (which I still haven't found good documentation on) is exploited, both copies will have to be sent back as the test must be done on the servers. And the test has to be done on the servers.

And fudge. You can kill that problem by sending the new text back as a diff file. But the test would still have to be done on the servers.

edited 6th Apr '16 8:43:22 PM by war877

We want a solution that does not require burdening the end-user experience with a ton of scripting.

I think you are already using javascript for something. The difference between a small amount of javascript and a large amount of javascript is negligible. Especially for use cases that only registered users will ever see.

Using some light scripting to reduce server load and bandwidth is a real possibility as well.

The current amount of scripting is already generating a number of problems, so I am not overly keen at adding more.

Given that the problem of "wordfilter plugins mess with wikis" doesn't seem to have an easy solution, can we get a "hey don't use wordfilter plugins when editing" message added to that list that you can send people?

Well, the problem there is that assuming they have a plug-in active that could affect TV Tropes, by the time they see the message (which would be while editing), it's most likely a little too late. It would be really difficult for any troper to catch any and all changes made by a substitution plug-in without the page history to guide them.

The objective is to prevent the plug-ins from messing with TV Tropes at all, not have it so after the first time it will be taken care of.

Are we thinking of the same list of messages? I'm thinking of the "Is there an issue? Send a message" link you can find in the edit histories. Those are always sent after the edit they're responding to. That's... kind of what a response is?

The fact that we want to prevent those plugins from affecting edits in the first place doesn't mean we can't have a quick "hey don't do that" message for it added to the already-existing list of quick "hey don't do that" messages.

edited 30th Oct '16 1:23:24 PM by billybobfred

Yes, and that is a problem. We'd like for the problem edits not to happen at all, not merely the tropers being warned after the fact.