1

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?

Gilles 'SO- stop being evil'
  • 829,060
wesalius
  • 113
  • 1
    This is a big prank specially if the erros does not have numbers. What program are you running? – Luciano Andress Martini Jan 20 '17 at 17:13
  • I am not trying to prank anyone, I just want to solve stuff and it would be better to use original error msges instead of self translating it. I am trying to build a package out of arch AUR and makepkg is complaining again. – wesalius Jan 20 '17 at 17:19
  • I didnt say that. What program are you running, it reads the locale environment variables? – Luciano Andress Martini Jan 20 '17 at 17:30
  • You can't do it after the fact. So if the error can not be reproduced by rerunning the command in an English locale, you should by default use an English locale to run all your commands. – Julie Pelletier Jan 20 '17 at 18:00
  • It may be reproducible, I am just asking for a way WITHOUT switching locales? Please note the besides switching locale in my original question. – wesalius Jan 20 '17 at 19:15

4 Answers4

2

To run a utility (program) with a modified locale:

$ env LC_ALL=C somecommand

The env utility modifies the environment of the utility that it executes, and setting the environment variable LC_ALL to C (or 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.

Read the locale(1) manual on your system (man 1 locale).

Kusalananda
  • 333,661
  • Setting LC_ALL sets all the locale settings to English/ASCII, which may affect the behavior of the program in other ways, especially with the set of printable characters. – Gilles 'SO- stop being evil' Jan 20 '17 at 22:52
  • @Gilles Yes, I mentioned that setting LC_ALL will have effects on sorting and other things. But as Stéphane mentioned in another comment, setting LC_ALL is the only way to override LC_MESSAGES if LC_ALL is already set. Of course, unsetting LC_ALL and then setting LC_MESSAGES would be the other option. – Kusalananda Jan 20 '17 at 23:41
1

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.).

LC_MESSAGES=C myprogram

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

export LC_MESSAGES=C

This won't affect programs started from other terminals.

Community
  • 1
Gilles 'SO- stop being evil'
  • 829,060
0

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.

Luciano Andress Martini
  • 6,628
  • Are you sure? Can i remove it? Or this is just a standard? I see a program that are programmed to read LANG environment and nothing more. – Luciano Andress Martini Jan 20 '17 at 17:39
  • 1
    Just to note, most systems have LANGUAGE unset, perhaps you should deal with LC_ALL (and subsets). – heemayl Jan 20 '17 at 17:41
  • 1
    @heemayl. LANGUAGE only applies to messages (LC_MESSAGES, not day/month names, currency, miss/mrs...), is not recognised on every OS/software. It would also not take precedence over LC_ALL=C or LC_ALL=POSIX. – Stéphane Chazelas Jan 20 '17 at 17:52
  • @StéphaneChazelas Thanks. Didn't know that. – heemayl Jan 20 '17 at 17:55
  • Isnt this switching my locales? Please note the besides switching locale in my question. – wesalius Jan 20 '17 at 19:14
  • Temporarily. Not in the whole system, but just in the current shell session. So another programs will run fine, only the programs executed in the current console will run in english. For example if you open a tab it will run with your language. – Luciano Andress Martini Jan 20 '17 at 19:15
0

"besides switching locale" – Short answer: No.

Long answer:

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 newlocale() and *_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?"

egmont
  • 5,866
  • Thanks for exhaustive answer, TIL something new. Unfortunately you are right, I just wanted to plain and simply run a program in English locale. – wesalius Jan 20 '17 at 23:12