apt shows incorrect language strings if used with specific locale settings - and aborts package installation if you confirm installation

Version: 0.6.46.4ubuntu7

apt uses

nl_langinfo(YESEXPR)

it seems like this is not honored LANGUAGE

Can you please attach the output of:
$ locale
and
$ cat /etc/default/locale

Thanks,
 Michael

[ch@monique~%] locale
LANG=en_US.UTF-8
LANGUAGE=de_AT:de
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

[ch@monique~%] cat /etc/default/locale
LANGUAGE="de_AT:de"
LANG="de_AT.UTF-8"

I'm admitting that LANG=en_US.UTF-8 gets set by a local user configuration file. (zshenv)
This is really intended behaviour (and it worked until upgrading to feisty; seems like edgy doesn't set $LANGUAGE). (gdm isn't the cause for that.)

I guess it's really a very uncommon configuration. Still, apt is showing something else than it's expecting.

Chris

Oh, another thing I forgot to mention in the bug report. If I setup my locale like this:

LANG=de_AT.UTF-8
LANGUAGE=de_AT:de

-> it works. apt shows "[J/n]", and entering "j" or "J" works.

Chris

[Expired for apt (Ubuntu) because there has been no activity for 60 days.]

Hi Christian
Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with the development version of Ubuntu, Hardy Heron?

Thanks in advance.

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New".

Thanks again!

I have the same problem.

I'm using Kubuntu 8.10. In system settings (Regional and Language option) my country is set to Brazil, and my language is set to English. All command-line programs are in English, but not apt. Thus I'm having the same problem, when I need to confirm something it shows (S/n), but to say yes I have to press 'Y', not 'S'. (It's the expected behaviour, since it should be in English, but it's not what it shows me on screen)

$ locale
LANG=en_US.UTF-8
LANGUAGE=pt_BR
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

$ cat /etc/default/locale
LANG="en_US.UTF-8"

This bug (duplicate of https://bugs.launchpad.net/ubuntu/+source/apt/+bug/307798) is set to low priority. However, this effects EVERY non-English speaking apt-get user.

Issue (in Danish):

Efter denne handling, vil 86,0kB yderligere diskplads være brugt.
Vil du fortsætte [J/n]? j
Afbryder.

Issue (in French):

Suite à cette action, serait 86,0 Ko d'espace disque supplémentaires seront utilisés.
Voulez-vous continuer [O / n]? o
Abandon.

Translation (in English):

Following this action, would 86.0 kB of additional disk space will be used.
Do you want to continue [Y / n]? y
Aborting.

In other words, the user selected "J" for "Ja" ("Yes" in English), but the expected affirmative input is "Y", so apt-get assumes NO, NEJ, NADDA, ABORT, CANCEL, Which is very wrong.

Confirmed bug since 2007 and still in Ubuntu 10.10. I motion to set this to HIGH priority.

Just 2 cents... If it will be changed, it should be done properly.

Justification: in Russian localized version acceptable answers are [Д/н], which corresponds to English [Y/n]. In this respect we had problem with aptitude, if I remember correctly, which accepted (or still accepts, can not check this right now) all variants: localized and non-localized. The catch is: in the layout of Russian keyboard Cyrillic "н", which corresponds to "no", is the same key as English "y" and if person is not paying attention to current keyboard layout the final result while selecting Russian "н" will be the opposite of intended.

I would rather make it untranslatable and not dependable on current locale:
* no problems if language is set, but switching of keyboard layout does not work by any reason (workaround is easy, but one have to know it)
* situations like described above are not possible

And I don't think that the bug https://bugs.launchpad.net/ubuntu/+source/apt/+bug/307798 where I described the situation from the comment above is the duplicate of this particular problem.

This bug is about having LANG/LC_ALL/LC_MESSAGES set to not matching locales. This should not be the case on a normal Ubuntu installation, but only if you have customized your shell environment. If you do not know what I'm talking about, then this bug is probably not what you're experiencing.

How is this low priority?

I'm not sure what is being talked about with shell environments. The way this manifests for me is that I got to System -> Administration -> Language Support (my apologies if that's not the exact wording...translating from Portuguese atm) and pick a different language and it stays with English. If it is a shell problem it seems to be because the shell is not being properly updated by the language support system.

Still happening here on Oneiric. The message is shown in spanish, but if I enter S (sí = yes), installation is aborted. If I enter Y, it continues.

0 actualizados, 9 se instalarán, 0 para eliminar y 0 no actualizados.
Se necesita descargar 40.2 kB/3,026 kB de archivos.
Se utilizarán 9,490 kB de espacio de disco adicional después de esta operación.
¿Desea continuar [S/n]? S
Abortado.

Please note that a list over all applications or parts of applications that don't honor the LANGUAGE environment variable would be long; the issue in this bug report uncovers one example. Therefore, in Natty and Oneiric both LANGUAGE and LC_MESSAGES are used to denote the language.

On 2011-10-11 16:41, Leo Arias wrote:
> Still happening here on Oneiric.

Only if your language/locale settings are inconsistent. If you use the UI in language-selector or User Accounts to set the language, apt ought to work as expected.

> Only if your language/locale settings are inconsistent

A problem is topical after an system install. If settings inconsistent, this is because inconsistent by system installer.

After installation
locale:
LANG=ru_RU.UTF-8
LANGUAGE=
LC_CTYPE="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES="ru_RU.UTF-8"
LC_PAPER="ru_RU.UTF-8"
LC_NAME="ru_RU.UTF-8"
LC_ADDRESS="ru_RU.UTF-8"
LC_TELEPHONE="ru_RU.UTF-8"
LC_MEASUREMENT="ru_RU.UTF-8"
LC_IDENTIFICATION="ru_RU.UTF-8"
LC_ALL=

/etc/default/locale
LANG="ru_RU.UTF-8"

And Russian language in "user account" setted

I do not know, how to correct this settings if it is inconsistent.

It seems to me, for so many years, you could simply change the translation to

"Do you want to continue [Yes=y/No=n]?"
"Продолжить [Да=y/Нет=n]?"

and the like in other languages