Yes. I think it should consist of two independent modules. The first would be the basic mechanism for creating the plugin, walking the node, and doing the text conversion, which would just be a function you could pass in. Then it would have a build step to make Chrome and FireFox extensions.
Or maybe you would want to pass in a series of regexp replacement pairs there, but even that is too limiting, I think. You might want to do something based on information about the whole node, not just the regex
Then the second module would be the good-enough natural language processor. You'd have an API for nouns, one for verbs, etc.
Yup. One of the other commenters suggested checking into Greasemonkey, but it's only for Firefox. Something could be created with a build step that creates the plugins for multiple browsers.
I've actually been giving that a lot of thought while writing this. It wouldn't be too difficult.
Although as I have learned, verbs are quite a bit more involved than nouns. I think I have something close to a generalized API for verbs at this point. I'll be polishing it up more this weekend.
Totally. It takes about 30-40 milliseconds on a typical news page, and that's after I added a pretty hacky series of brute-force regexps in a panic after I realized that I had been assuming that disrupt is always a transitive verb, but it's increasingly used intransitively these days, especially in the kinds of articles this plugin is meant for.
So the translation, ('We disrupted that industry' => 'We rained bullshit on that industry'), was rendering badly when the verb was used intransitively ('We can't disrupt on our own' => 'We can't rain bullshit on on our own').
The regexps I added have mostly taken care of the problem for the time being, as Chrome auto-updates its extensions in users' browsers. Now the latter sentence above renders 'We can't bullshit on our own.'
Once I reintegrate the new rules into the generalized verb creation function this weekend, it should be a little faster.
But I initially didn't spread the word about it as much as for the Chrome one because as previous commenters have noted, the Firefox one is under review for 10 days, and before that it's not a searchable page.
It should not do that. If it does, there's a bug. Can you tell me what page you're looking at?
EDIT: Oh, you mean the actual text inside the "a" tag? Yes, the plugin will change that in its current form. It would be pretty trivial to not have it do that. I will add that next. In the meantime, I don't think the link itself will be affected -- even now, you should be able to click on it and it will go to the right place.
The plugin actually contains a large number of rules for different forms of the word 'disrupt'. Try it and see. For instance, both the words 'disruption' and 'disruptive' become 'bullshit'.
I'd stick to Firefox and Chrome. They're both widely used and fully cross-platform (Windows, Mac and Linux). Desktop Safari is kind of the modern-day IE in that it's artificially tied to a single OS (Apple dumped the Windows version of Safari a couple years ago with no notice leaving users in a lurch).
Yes, it does. But both Disrupt to Bullshit and Cloud to Butt are available for Firefox as well, if you don't want to switch. Disrupt to Bullshit's Firefox link is not searchable yet, but it's https://addons.mozilla.org/en-US/firefox/addon/disrupt-to-bu...
Or maybe you would want to pass in a series of regexp replacement pairs there, but even that is too limiting, I think. You might want to do something based on information about the whole node, not just the regex
Then the second module would be the good-enough natural language processor. You'd have an API for nouns, one for verbs, etc.