I'm quite surprised about the reported wording of the Wiki regarding speaking many languages. Sounds like bad editing of the page. I'll have a look at that, later, and see if I think I'm up to modifying the statement for clarity.
As for using plain English, attempts have been made to allow computers to respond to understand 'natural language', but that's really only at the User Interface level ("Please open the document that I wrote yesterday"), not for writing programs. Even the Hollywood-style depictions of computer interface where "Search the database for all even-numbered ID codes and check the owners against the list of all blue cars" is not programming, so much as natural language being parsed for sense. A parsing which might or might fall down on such input as "A canner can can anything that he can. Can a canner can a can, can he?", depending on sophistication.
The closest language I've encountered (and, truly, I found it a depressing language for various reasons) to one that takes plain English is Cobol. See
http://en.wikipedia.org/wiki/COBOL#Syntactic_features for the kind of thing. It was (not checking even Wiki for this, just repeating what I remember the teacher told me, 20-odd years ago) designed for "ordinary businessmen" to be able to program it.
I suspect that it wasn't so much the writing that was supposed to be 'natural' (there were so many restraints regarding line indentation, and of course the vocabulary, while very "English", was constrained almost exactly as much as any other language, if not more so), but the ability to read it without needing a "geek's eyes" for symbols and their meanings.
Compare with the likes of LISP (see
http://en.wikipedia.org/wiki/Lisp_(programming_language)#Examples) or Forth or Fortran (
http://en.wikipedia.org/wiki/Fortran#Simple_Fortran_II_program). Though my current favourite for prototyping general problems (not requiring specific language features) is Perl.
Indeed, Perl is a lot easier to write than COBOL (in my opinion) because of the multiplicity of possible methods[1], e.g. the following five (more or less) identically-functional lines:
if (@list) { print "We have a list" }
print "We have a list" if (@list);
(@list)?print "We have a list":;
print "We have a list" unless (!@list);
@list && print "We have a list";
(Doing that off the top of my head, so I've probably typoed or brainoed something. And I've not even delved into using "$#list" or "int(@list)" variants.)
It's not really English (unless you're happy with the "if" and "unless" keywords and flexible grammar making it English, and ignore the various parenthises and other strange punctuation). An easy language to write (when you know what you want to do, you can usually think of a way it can be done even if you don't know all the possible tricks and shortcuts that others might use) but can be hard to read (because even if
you wrote it, it can be horribly obfuscated and/or untidy when you come to read it after the fact).
Truly, if you want to actually make a computer do exactly what you want, understand its internals and work at the lowest level of code that you are able to, without having to reinvent the wheel for every trick. That could be batch file (or shell script) where you don't have to worry about much except piping file contents through a FIND/grep command and then through your favourite paging utility, or perhaps you need to peek and poke at your serial port to make your fax-modem do rather unorthodox things that were never allowed for by the deamons or drivers.
Slightly Ninjaed by Armok, here, but learn assembly-language and you can make your machine (and all compatible ones) spin on a dime. Nevertheless, if you just want to regularly display the number of lines in a file containing the word "Mother", you might as well put FIND /C "Mother" FILENAME.EXT in a batch file, rather than waste time with DiskIO and the like at a low level. This is what I understand about "Computers speak many languages". And English (or virtually any other human language) is going to be second-best to a suitable computer language.
As for taking an instruction such as "make an emulator, now make it dual processor compatible", look at
http://en.wikipedia.org/wiki/DWIM. And I see that also links to
http://www.catb.org/~esr/jargon/html/D/DWIM.html, which I was also going to suggest, to highlight the problem of a typo-correcting DWIM function.
[1] COBOL might be more flexible than I remember. It was a couple of decades ago when I last touched it, and I've slept since.