7

The "LANGUAGE" variable is supposed to set the default language and can be used to specify a set of languages, where the next language will be used if a message is not available in the first (previous) one.

For example (as from gettext example) with 'sv:de' variable's value programs will show messages in Swedish and if such text is not found then in German.

I want to use English language as my primary language and some other (let's say Russian language) as secondary:

export LANGUAGE=en:ru; blabla
blabla: команда не найдена
        ^^^^^^^^^^^^^^^^^^
**Russian error message used**

Ok. Let's try another order:

export LANGUAGE=ru:en; blabla
blabla: команда не найдена
        ^^^^^^^^^^^^^^^^^^
**Russian error message used again**

In the other words, it doesn't matter on which position English language was specified, it always has the lowest priority and a message will be shown at any other specified language if the message is defined for that language.

The question: how can I specify English language as primary and any other language as secondary? And what's going on with the LANGUAGE variable?

P.S. 'LC_MESSAGES' is set up to the English locale of course.

Pierre.Vriens
  • 1,088
Sap
  • 239
  • 1
    It boils down to distribution not bothering including messages for English because English is the default language (so no need for additional language files, messages are in the code already). See also http://unix.stackexchange.com/q/171671. I'd say it's a bug indeed, or a misfeature. – Stéphane Chazelas Jan 29 '15 at 19:28
  • Yes it's exactly mu case. So I have to add the 'C' locale to the list of languages after english. Thanks a lot – Sap Jan 29 '15 at 20:03
  • @StéphaneChazelas The link is broken. If the question linked was deleted and you have access to it could you please add it here as an answer? – Piotr Dobrogost Feb 16 '17 at 08:35
  • @Piotr, the question was closed and deleted (wrongly IMO, I've requested undelete). to quote the relevant parts of the discussion by me: Try LANGUAGE=C:ru. The problem is that the langpack is not installed for English, it's just that the default language is English which in this case you get with C. I'd say it's a shortcoming of how localisation is designed (or non-designed in this case) on Unix/GNU. Well, given that English is the default language, LANGUAGE=C:ru is pointless given that ru will never be reached. – Stéphane Chazelas Feb 16 '17 at 09:02
  • @StéphaneChazelas Thanks for taking action. The simple fact is LANGUAGE can't work as designed because of missing en* langpacks (translations) installed in system which in turn is possible by taking advantage of the fact that fallback locale (C locale) is a de facto English translation almost always. This would be simple to fix by distributions providing en* langpacks. Do you know why that's not the case? – Piotr Dobrogost Feb 16 '17 at 09:17
  • @Piotr, given that the default language is (in 99.999% of the cases) English, a language pack for English would just duplicate the data (the english text is already there in the code). If the language packs for English were provided, with LANGUAGE=en:ru, you'd always get English. So you might as well use LANGUAGE=en or use LC_MESSAGES only. Or as Sap answers, use en:C:ru for other things than gettext that may use LANGUAGE to specify a language preference. – Stéphane Chazelas Feb 16 '17 at 09:34

2 Answers2

7

As it was discussed in this question most programs don't have 'English' locale but use default ('C') locale with English messages instead. So if I want to use some languages with preferred English then I have to add 'C' locale right after the English locale in the list. In my case the 'LANGUAGES' must be:

LANGUAGES=en:C:ru


Which means "Use English then Default and then Russian". So every program which doesn't have English locale (because of using English locale as its default locale) will fall back to its default locale.
Someone may think that there is no effect in specifying Russian locale after 'default' because the default locale is always present and the Russian locale will never be chosen. It's true. But some programs (like browsers and text-editors) use the 'LANGUAGES' variable to get a list of user-spoken languages (like languages to request HTML-pages on, or languages for spell-checking) and in such cases Russian language won't be superfluous in the language list.

Community
  • 1
Sap
  • 239
0

There is no reason to blame the LANGUAGE variable only. Firstly you have to look through output of locale programm and note that there are many variables which are responsible for different things. So if you'd like to receive English messages change the variable LC_MESSAGES:

LC_MESSAGES=C type test
test is a shell builtin

type test
test встроена в оболочку
Costas
  • 14,916
  • export LC_MESSAGES=en_US.UTF-8; export LANGUAGE=en:ru;

    type test test встроена в оболочку

    As you can see I've selected English language but it still uses Russian instead. And in your example you selected default (English) locale (C) and got a message in Russian. That's what I am talking about.

     – Sap Jan 29 '15 at 19:52
  • @user3544995 I got message test is a shell builtin – Costas Jan 29 '15 at 20:10
  • And I still get Russian message. And of course I got 'LC_MESSAGES' set up to 'en_US'. I'll add this to the question text. – Sap Jan 29 '15 at 20:21
  • @user3544995 Try export LC_MESSAGES=C may be en_US is not compiled on your machine? What is locale-gen shows? – Costas Jan 29 '15 at 21:09