When I run into errors I sometimes get errors in my language set by locale. Is there a way besides switching locale to force English error messages for the sake of googling the solution?
Locale settings are how most programs decide what language to use. While a few programs have a different setting, the most common way to select the language of messages is through locales. There's no other way that works across more than one application (or family of related applications).
You don't need to set any system settings, however. Just run the program this one time with a different setting. The locale setting for messages is
LC_MESSAGES (see What should I set my locale to and what are the implications of doing so?), so you can set it by setting the environment variable
LC_MESSAGES. The special value
C is supported on all systems and means the default, untranslated messages (normally in English).
From a shell, the following command runs
myprogram with the environment variable
LC_MESSAGES set to
C, i.e. runs
myprogram with messages in English and other locale settings unchanged (so the program still uses your favorite character set, sort order, date format, etc.).
After the program runs, other programs executed from the same shell will use your usual locale settings, the change doesn't stick. If you want the change to stick within a terminal, run
This won't affect programs started from other terminals.
To run a utility (program) with a modified locale:
$ env LC_ALL=C somecommand
env utility modifies the environment of the utility that it executes, and setting the environment variable
POSIX) will ensure that you get localized error messages in the POSIX locale. It may also affect sorting, date & time formats, and numerical formats.
The environment outside of the utility (the shell or the system as a whole) will not be affected by this temporary switch of locale.
locale(1) manual on your system (
man 1 locale).
Do this before running the program:
export LANGUAGE=en_US.UTF-8 export LANG=en_US.UTF-8
If the program is running by a script like in /etc/init.d you need to put this inside the script.
"besides switching locale" – Short answer: No.
If an app's developers decide to print all error messages in English, regardless of the locale, sure they can damn easily do so. All they need to do is not to send these strings via gettext's translating functions.
If the app's developers decide to introduce another environment variable (or other means) of specifying a different locale for error messages, they could also relatively easily implement this. The
*_l() functions will probably come handy. I have never seen such an app, though, and I see no reason for developers bothering with this.
An app normally just initializes the locale according to the environment variables and then, whenever it wants, translates a string according to the locale being used.
Assuming a regular, internationalized app that translates its error messages (I believe this is what you care about), there is no way to trick it into using one locale for strings that will go to the standard output, and another locale for the strings that will appear on standard error. This cannot be "hacked" by tricks like an LD_PRELOAD library or so. The reason is very simple: at the time of constructing a translated string, it is not yet known where that string will appear (stdout, stderr, a log file, graphical interface, sent through wire etc..., maybe even more of these at the same time). Yet, for being able to process, the string already has to be created in its translated form.
For the sake of googling the solution, if you'd prefer to use the app in a non-English locale, here's my recommendation:
Try to locate a large substring of the error message that is likely to come from a fixed string, that is, doesn't have substituted numbers or words. Do a grep for this string under /usr/share/locale/(yourlocale)/LC_MESSAGES to locate which file it comes from. If there's no match, repeat with a substring that contains 7-bit ASCII (English) characters only, since *.mo / *.gmo files might be in any encoding (although for modern software they're typically in UTF-8). Once you have found the file where the error message comes from, run
msgunfmt on that file to find the original English string.
Update: I just realized you mentioned in a comment that you're seeing troubles with AUR and makepkg.
As others have answered, it's easy to run a specific program with English locale. For building packages this is highly recommended.
So I probably misunderstood your question. My answer above answers the question: "Is it possible to have an app running in my preferred non-English locale, yet [that very same process] print the error messages in English?"