Messages in my terminal are displayed using Russian language by default, which is my native one.
For just a moment I want them to be in English (eg. to paste in forums), then switch back to the default language.
How can I do the switch and switch back using bash?
There are several environment variables available for changing language settings. You can view your current locale settings by executing the
locale
command. To change all locale settings to English, useLANG=C
. ThisC
locale is always available without installing additional language packs. (In order to temporarily change to non-English locales, see @mklement0's post.)Examples:
Executing a command with the default language settings and print the current locale settings:
Temporarily override the language for one program and show that it is really temporary:
Change the locale for all commands executed in the current shell and include proofs again:
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 ases
for Spanish.Background info
GNU gettext-based utilities give precedence to the nonstandard
LANGUAGE
environment variable[1] over POSIX-defined locale environment variablesLC_ALL
,LC_MESSAGES
, andLANG
(in that order).Given that
LANGUAGE
is set by default on Ubuntu systems[2], namely to a substring of theLANG
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 overrideLANGUAGE
in order for a different language's messages to take effect.[3]Option 1: Set
LANGUAGE
Example: Switch to Spanish (
es
) messages ad-hoc: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 setLC_ALL
This alternative solution undefines
LANGUAGE
first, and then uses POSIX locale environment variableLC_ALL
to implicitly setLC_MESSAGES
[4]: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) settingLC_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
) (unlikeLANGUAGE
, for which a simple language tag is sufficient (likees
)). The same applies to settingLC_MESSSAGES
andLANG
. 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.