Lekensteyn's helpful answer works great if you want to switch to US English on demand, as the OP requested, but if you want to switch to a different language on demand, more work is needed.
Before starting, you must install message tables with sudo apt-get install language-pack-<lang-tag>, where <lang-tag> is a simple RTF 5646 language subtag, such as es for Spanish.
Background info
GNU gettext-based utilities give precedence to the nonstandard LANGUAGE environment variable[1]
over POSIX-defined locale environment variables LC_ALL, LC_MESSAGES, and LANG (in that order).
Given that LANGUAGE is set by default on Ubuntu systems[2], namely to a substring of the LANG value that reflects either a simple language tag (e.g., es for Spanish) or a language-region tag (e.g., de_DE for the Germany variant of German), you must unset or override LANGUAGE in order for a different language's messages to take effect.[3]
Option 1: Set LANGUAGE
Example: Switch to Spanish (es) messages ad-hoc:
$ LANGUAGE=es ls NoSuchFile
ls: no se puede acceder a NoSuchFile: No existe el archivo o el directorio
Note: A simple language tag such as es is sufficient, but you may add a region identifier (e.g., es_AR for Argentina), and even a charset suffix (e.g., es_AR.UTF-8).
However, localized messages may only exist at the language level, and the fallback is to use messages that match the language part (es, in this case).
Option 2: Unset LANGUAGE and set LC_ALL
This alternative solution undefines LANGUAGE first, and then uses POSIX locale environment variable LC_ALL to implicitly set LC_MESSAGES[4]:
$ LANGUAGE= LC_ALL=es_ES.UTF-8 ls NoSuchFile
ls: no se puede acceder a NoSuchFile: No existe el archivo o el directorio
This solution has the advantage of setting all localization aspects to the specified locale (such as LC_TIME for date/time formats) and by (implicitly) setting LC_MESSAGES also informs non-GNU programs of the desired language.
Note how LC_ALL requires the exact, full locale name, including charset suffix, to be effective (es_ES.UTF-8) (unlike LANGUAGE, for which a simple language tag is sufficient (like es)). The same applies to setting LC_MESSSAGES and LANG. Specifying an invalid / non-installed locale name causes fallback to the POSIX locale and therefore US English.
Footnotes
[1] The reasons that Lekensteyn's answer works even _without_ unsetting / overriding `LANGUAGE` is an _exception_: if the (effective) `LC_MESSAGES` value (typically set indirectly via `LANG` or `LC_ALL`) is either `C` or (its synonym) `POSIX`, that value is respected, irrespective of the value of `LANGUAGE`, if any. Conversely, if the (effective) `LC_MESSAGES` value is any other, _specific_ locale, `LANGUAGE` takes precedence.
[2] This applies to [Ubuntu proper](https://www.ubuntu.com/), but not necessarily to [other flavors](https://www.ubuntu.com/about/about-ubuntu/flavours); Lekensteyn states that [Kubuntu](https://kubuntu.org/) does _not_ set `LANGUAGE`.
Arguably, `LANGUAGE` should _not_ be set by default, given that in its absence the `LC_MESSAGES` value implied by the `LANG` value (which determines the current locale), is respected.
[3] You can also use this approach to switch to [US] English by assigning either `LANGUAGE=C` or `LANGUAGE=POSIX` (as an alternative to, `LANG=C` / `LANG=POSIX`), though I'm unclear whether that is actively recognized or simply a _fallback_ mechanism, given that these values don't start with a _language_ tag; perhaps the better choice would be `en_US`.
[4] There's an _edge_ case where this approach doesn't work: Trying to invoke an executable with a _path_ - whether relative or absolute - does NOT switch to the specified language, whereas a _mere filename_ does:
`LANGUAGE= LC_ALL=es_ES.UTF-8 /path/to/no_such_utility` does _not_ work (outputs a message in the current locale), whereas
`LANGUAGE= LC_ALL=es_ES.UTF-8 no_such_utility` does (outputs a Spanish error message).
If anyone knows why and whether there's a good reason for this, do let us know.