I await your proposal for how to automate this with great interest. I will be particularly interested to see how you automagically deal with modules which provide a correctly spelt method and an incorrectly spelt alias for that method, and modules which provide neither, instead using clr just to stop idiots from whining. | [reply] |
Not sure if you are being tongue in cheek but.. For example with htdig and other search engines there is a plugin which allows words to be slightly "misspelled". A one character misspelling would match both color and colour. I don't remember but it seems there was also a list of commonly misspelled words, if not one could be made.
Anyway as you suggest it is impossible to solve every case. However please note these are things being created by programmers to do common things. It is not brain surgery. Also it is an old problem. For example BSD's spell command apparently has a -d option to specify a hash of alternate spellings (the hlist file).
Also guess what, dictionaries are published by people who study this sort of thing for a living and they usually note alternative spellings. Even WordNet which has a Perl module has both color and colour. So between currently available resources and software to be developed it does not in fact seem to be as daunting a task as all that. Not that I'm going to do it though! :)
| [reply] |
You miss the point. Yes, those dictionary-ish things will tell you what to look for, but they won't tell you how to look. You can't just blindly search and replace, you need to parse the files. And to figure out what bits of code to change you need to understand the documentation - see for example GD::Graph, where at most you would want to change some headings but you most definitely DON'T want to change the word colour (or color) anywhere else.
This CAN NOT be reliably automated. What might be worthwhile would be grepping over your CPAN mirror, finding all mentions of /colou?r/ and friends, manually checking that there really is a problem, and then notifying authors and perhaps submitting patches. And repeating this occasionally to catch any new modules, while being careful not to repetitively annoy authors who don't consider this to be important. Considering how much work is involved here, you might want to talk about it on the perl-qa list before doing anything.
| [reply]
[d/l] |
