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.