Automatically replace words/names/phrases with custom ones when browsing

with or without an extension


https://addons.mozilla.org/en-GB/firefox/addon/zero-word-replacer/&sa=U&ved=2ahUKEwjR89X859TpAhXkShUIHVQdDWAQFjAAegQIBRAB&usg=AOvVaw265A8XVMJZH0G1CC1FfTov

Have to say it is great fun - good for subverting the deluge of political media references by changing the names of politicians you particularly dislike etc

I use chrome as my second browser and it has similar extension

Perhaps that FF extension can be converted, but far beyond my skills anyway.
And I distrust possible abuse, but you're right - if used just for fun it's hilarious!
So I couldn't help playing with alternative, more crude methods on my level, and can now offer a selfmade macro. It just runs a little (probably non-perfect) script, and has no pretty GUI. The words must be defined directly in the js-file, hope that's okay.
Almost finished, will post it soon...

New macro "replacefaketext" finished, see attachment.
Works in KM1.6 or in theory newer builds too, could anyone test and confirm?
Perhaps a bit buggy, doesn't work in iframes, and words in plural need own definitions etc, but oh well. It's just a little fun gimmick anyway.

Installation:
unzip the attached file and place the 2 files into a macros folder, then restart KM.
This script is DISABLED at every session start to avoid confusion.
Switch it ON in menu Tools > Replace Fake Text (On/Off)
For convenience, switching always offers to open the config file.

Read the description / help text in both files, in any text editor.

USERCONFIG: Edit your texts in FILE replacefaketext.js.
Do CHANGE it, by default it contains only nonsense replacements, just for testing :cool:
Toggle menu 2x to import changes with needing a restart.

EDIT:
That double menu-toggle to refresh rules is too bothersome Same prob as always, macros can at most show 3-choice buttons named YES-NO-CANCEL, no other names possible, sigh. But that multipurpose menuline must somehow get more userfriendly anyway. Upate in work...

UPDATE v2: (2020-05-30, new attachment below)
Improved the MENU handling. And moved menuline on TOP of Tools menu for easier testing.
Now also possible to exclude user-defined domains or URL-snippets from this macro.
For advanced options edit the kmm-file, search inside for **USERCONFIG**

ATTENTION: the file names are the same, do NOT simply overwrite the files or you'll lose your own settings from version-1!



Edited 3 time(s). Last edit at 05/30/2020 06:27PM by siria.

Works in newer builds too. Consider declaring 'nameX'.

Terrific! - siria strikes again.

Mugbook - I like it.

Works in latest Goanna

Double toggle is onerous, if no other way around could toggle be assigned to
hotkeys?



Edited 1 time(s). Last edit at 05/30/2020 03:25AM by Mello.

Thanks for confirmation in new KM - great! Var declared now too.

Yes the double-toggle is really awful, as mentioned above am already working on an update.
Basically everything is possible menu-wise, no prob in macros. Just would prefer a single menuline, because several entries grow the parent menus so endless long if a user installed lots of macros, and alternatively a popup menu can be bothering too.

Meanwhile am finally happy with my current update (in work), which will automatically show more choices with still just 1 menuline.
And alternatively will prepare separate menulines for different actions too, for users who prefer this way.
If they dare ;-) to edit the kmm-file they can choose exactly which lines they want and how etc.

Do you have any preferences what you'd like in the menu exactly, and how and where....? :cool:

UPDATE version-2, see above (replaced attachment)

Very good!
Thanks.

I'm fine with current system, but if you come up with something I'll
give suggestions - if needed.

It is still magic to me that text and symbols in files do anything at all.

Well...it has stopped working, both versions.

I deleted and started over from scratch, still not working?

Quote
Mello
Well...it has stopped working, both versions.
I deleted and started over from scratch, still not working?

If everything is the same as before, incl. userconfig rules and visited pages, something must still be different obviously. But only you can tell....
Especially userconfig rules are easily prone to syntax errors. Any message in the error console?
Perhaps any other extensions or whatever security tools interfer now?

Remember that it's set OFF by default at every session start. That's intentionally set in the kmm, since text changes can be highly intrusive but so easy to forget. Therefore versions 1+2 must first be switched ON in Tools menu. Of course, that's all open source and everything can be changed easily by users too.

@Mello
There was a line that disabled it on startup. Added # in front of last setpref near the end of kmm file when testing v1.

Thanks - I've set it to true.

Working now.
I tried V1 again and then edited some of siria's entries - Fine.

But when I copied and pasted in my previous more extensive list - not working.
So I trimmed that down to one entry - still not working.

Reverted to siria's original list - fine
added some entries manually - fine



Edited 1 time(s). Last edit at 06/02/2020 03:19AM by Mello.

Please use the newer version, there's really no advantage in using the old one.

In your user rules must be some syntax prob.
Make sure all lines look like that, and check the comma at the end.
"....." : "....." ,

Hmm, starting to wonder about possible JS-restrictions for characters on left side, will have to do more research :-/
Ah, the very first little test already a hit: javascript does not like BLANKS after the end of a word!
And it neither likes symbols as in "research :-/"
But accepts the same symbols if followed by a normal character: "research :-/ x"

Broken: "research "
Broken: "research :-/"
Broken: "research :-/ ö"
OK: "research :-/ x"

Found CULPRIT: \\b in replace line, needed to catch "word borders"
Makes sense, but riddling how this could possibly be fixed?
Which workaround to catch word borders but still allow non-AZ09 at begin+end??



Edited 4 time(s). Last edit at 06/02/2020 04:53AM by siria.

@Mello
Convert script to UTF-8 after pasting.

@Mello
Have found a workaround for the punctuation prob, if e.g. a searched text ends with a blank or dot or ! or ? etc.
Can you test with your own config? Replace only the JS-file, attached HERE below (not the one above)

Thanksfor your efforts siria, but no change with either new version or saving with utf-8

Syntax looks O'K but any file with pasted list doesn't work.

It's not that I changed something, the list I had working, just suddenly stopped
working.

I've finished manually building up my list mentioned above again so that is O'K

@siria
Not sure why there should be a problem with 'word borders'. Start position of found string is known. Length of search string is known. If positions before and behind a found string match 'a-zA-Z' nothing should be replaced.

@siria
Forgot to include \u00A0-\u10FFFF for 'ü'.

Quote
anonymous
Forgot to include \u00A0-\u10FFFF for 'ü'.

Good hint about unicode-ranges (am using them now), but you led me on slippery ice there!
Turned out unicode signs with more than 4 digits "\u1234" are a buggy minefield in older browsers, when written as \u123456 in regex. Especially tricky, there are no errors in the console, no hint anywhere. And 'real', pasted signs do seem to work (except range results), so took me a week to even realize something is fishy. Finally got suspicious and tests showed that regex in older engines just chops off all \u123456 after 4 digits. Instead of [\u123456] the engine wrongly understands [\u1234 or 5 or 6]. Killer trick especially for ranges, always starting from "F" or earlier.
Then learned that modern engines can understand a syntax of \u{123456}, but THIS in turn destroys the whole script in older engines again, when used in ranges, even so thoroughly that not even try-catch works anymore! Sigh, what a mess...
And read that in even younger engines, there's now a very handy unicode-equivalent for \w (word) and \b (wordBorder), which goes like this:
\p{L} is any unicode letter, and \P{L} (uppercase P) the opposite. Plus a bunch more such shortcuts.

Now am riddling since which KM-version the syntax \u{123456} may work.
Will need to test on another machine. If anyone wants to test too, my little test scripts:

if (/[\p{L}]/.test('M')) alert('\\p{L} WORKS'); else alert('\\p{L} NOT working');
if (/[\u{12345}]/.test('{')) alert('\\u{12345} NOT working'); else alert('\\u{12345} WORKS');

@siria
Set a limit as needed. Used this to block replacement of 'inform' and 'ticos' in informáticos.

var utf8Example = 'á';
if (utf8Example.match(/[-\u00A0-\u10FFFF]/)) {
 alert('Found: ' + utf8Example);
} else {
 alert('Not found: ' + utf8Example);
}

In the (hopefully soon finished) version 4 I've rewritten the whole thing completely, and sadly the size exploded from a lovely 1-page mini-scriptlet (working for English ONLY) to currently 13pages, grmpf. Although with lots of test notes yet, will see how much remains after deleting those. Frustrating again, but anyway, I wanted to get that thing working correctly in ALL languages, including exotic ones, and of course cyrillic and chinese. Cannot test the latter myself, but cyrillic works now, so am optimistic others will too.

(just about coding details, non-coders can skip)
Main goal was to not risk wrongly replacing stuff in mid-word, in undefined cases rather replace nothing (no harm) as the other way around. So have decided to define "all" characters as "word" by default, and the "border" characters as the exceptions to be defined. So far so great, but as usual with JS, that more complicated method created new regex struggles again, sigh. Since those borders have a "width" now, and two words in a row with a shared blank between killed the second word. Finally figured that out too, got both border chars excluded from the match, and yes, partly using the "position" you hinted at, and partly using lookahead.
To figure out which ranges to define as non-word, BabelMap helped greatly, always amazed at this fantastic userfriendly tool :-)
But it revealed that in unicode there are TONS of ranges for non-word characters, and all mixed up here and there. Started trying to collect those ranges, but the heap grew fast, and checking over 1500 characters before+after every searched word seems complete nonsense when in 99.99% cases the borders are just comma, blank, dots. So who cares about those 0,01% missed rare replacements, will just exclude the main punctuation ranges and a few special ones like emoticons.
But still, the next prob turned out SPEED, at least in my old KM1.6 and system. Even with only a limited set of border-chars, it slowed down extremely - several seconds on every page! Killer, no go. Of course I also checked how long your almost-everything range needs, perhaps 1 single giant range would be much faster, who knows? But it took even longer. Then tried it in KG74: only 1 second. Okay... Continued testing border-ranges, now trying to optimize for speed, but results were strange. Until finally understanding why, that \u1234-chopper bug described above. An ultimate test with excluding not the whole range up to \u10FFFF (bug=\u10FF), but up to \uFFFF took a whopping 90secs! (in KM1.6)
So excluding characters as u-numbers beyond 4 digits is impossible in old KM.
Luckily even the chinese main punctuation class is still in the lower planes and thus should work.
And luckily excluding SINGLE characters from those higher planes always works if pasted as 'real' character, even in old KM. Have now just added a few selected emoticons, not the whole range.

Then was trying to include additional ranges in modern syntax as "\u{123456}" for younger engines, but that kills the whole script in older engines (console complains about "invalid range"), so gave that up too for now. Will need to do some practical testing in younger KM too, but not urgent. And if needed, users can always add their own border definitions, no prob.
For now am planning to post this version-4 soon, when finished that bothersome cleanup and end polish ;-)



Edited 1 time(s). Last edit at 06/16/2020 09:52AM by siria.

@siria
Forgot that you added a menu which explains your need for translation. Nobody will use it without a whitelist, but if page load time increases, add a link or some words with borders for comparison. Shouldn't be worse than a spelltest kplugin.

@siria
Added \u4E00-\u9FAF for a Japanese site.