*** Bug 22182 has been marked as a duplicate of this bug. ***

Надо будет попробовать...

setup-2.2.13-alt1 -> sisyphus:

* Thu May 27 2010 Dmitry V. Levin <ldv@altlinux> 2.2.13-alt1
- /etc/profile.d/lang.*sh: do not source i18n files if
  non-empty LANG is already set (closes: #11814).
- /etc/services: updated SANE entries (closes: #13071).
- /etc/inputrc: added bindings for xterm ctrl-arrows (closes: #15628).
- /etc/profile.d/tmpdir.*sh: do not create ~/tmp directory (closes: #19014).
- /etc/filesystems: replaced obsolete content with a comment hinting
  on the purpose of this file (closes: #21082).
- /etc/inputrc: added bindings for history search (closes: #22570).
- /etc/securetty: added xvc0 for xen virtual console (closes: #23532).

+if [ -n "${LANG-}" ]; then
+       sourced=1

Теперь имеем

vvk@home ~ % echo $LANG
ru_RU.UTF-8
vvk@home ~ % su -
Password:
root@home ~ # echo $LANG
ru_RU.UTF-8

В /root/.i18n
LANG=en_US.utf8

По-моему такой фикс совсем не OK.

(In reply to comment #4)
> +if [ -n "${LANG-}" ]; then
> +       sourced=1
> 
> Теперь имеем
> 
> vvk@home ~ % echo $LANG
> ru_RU.UTF-8
> vvk@home ~ % su -
> Password:
> root@home ~ # echo $LANG
> ru_RU.UTF-8
> 
> В /root/.i18n
> LANG=en_US.utf8
> 
> По-моему такой фикс совсем не OK.

1. Я не использую "su -".
2. Как вы предлагаете удовлетворить несоместимые желания одновременно?  Сделать поведение конфигурируемым?

(В ответ на комментарий №5)
> 2. Как вы предлагаете удовлетворить несоместимые желания одновременно?  Сделать
> поведение конфигурируемым?

Возможно, переключатель через control не помешает.

(В ответ на комментарий №5)
> 2. Как вы предлагаете удовлетворить несоместимые желания одновременно?  Сделать
> поведение конфигурируемым?

Возможно, переключатель через control не помешает. Но если делать системную ручку, всё равно надо решить, какое поведение должно быть по умолчанию.

Раз за несколько месяцев никто не поинтересовался этим изменением, значит всех устраивает текущий вариант. А кому нужно переопределение, могут и ~/.bashrc поправить.

Как-то за прошедшие 2 года я понял, что более предпочительным является обратное предложенному поведение:
- имена локалей могут быть несовместимы между машинами (но это уже вопрос к AcceptEnv в конфиге ssh)
- становиться рутом с нерутовой локалью как-то непривычно и может давать побочные эффекты

(In reply to comment #8)
> Как-то за прошедшие 2 года я понял, что более предпочительным является обратное
> предложенному поведение:

Поздно, все уже привыкли и активно пользуются.

Не успел еще ощутить все "прелести" такого поведения удаленно, только обновил dekstop, но вот то, что теперь переменную LC_MESSAGES=C в ~/.i18n все дружно игнориуют - удручает. Это что теперь, как раньше редактировать свои .bashrc/.zhrc?

P.S. У меня еще в .i18n прописан LANG, может в этом дело, надо проверить.

(In reply to comment #10)
> теперь переменную LC_MESSAGES=C в ~/.i18n все дружно игнориуют

Прежде чем делать свои выводы, прочитайте, пожалуйста, сперва всё, что здесь написано.

(В ответ на комментарий №11)
> (In reply to comment #10)
> > теперь переменную LC_MESSAGES=C в ~/.i18n все дружно игнориуют
> 
> Прежде чем делать свои выводы, прочитайте, пожалуйста, сперва всё, что здесь
> написано.
Я все прочитал, но проблема была. С помощью #altlinux, "зубила и такой-то матери" выяснилось, что в случае использования GDM эти настройки в ~/.1i8n игнорируются, не знаю, почему (раньше не игнорировались). Переключился на xdm и заработало. 

Оставляю комментарий для тех, кто тоже столкнется с этой проблемой.

А точнее, gdm сам выставил локаль, минуя {/etc/sysconfig/,.}i18n

*** Bug 24314 has been marked as a duplicate of this bug. ***

поиск есть, но найти не удалось, спасибо хорошему заголовку у этой ошибки.

Дим, надо что-то с этим делать. сейчас приходится на всех серверах править profile.d/lang.sh убирая оттуда игнорирование ~/.i18n

Сперва тема была "/etc/profile.d/0lang.*sh: изменить приоритет в пользу переменных среды".
Потом, через полгода после того, как изменение было реализовано внедрено,
тему поменяли на "/etc/profile.d/0lang.*sh: изменить приоритет в пользу конфигурационных файлов .i18n".

Когда одни хотят одного, а другие -- другого, то мне, как лично незатронутому этим вопросом, проще ничего не делать.
Так что просьба заинтересованным искать консенсус.

Дим, уже же нашли консенсунс.

в конфигурационном файле прописать переменную USE_I18N и если она есть, то использовать ~/.i18n, если нет - не использовать.

Странно что автор предложения по игнорированию локальных настроек отмалчивается.

(In reply to comment #17)
> в конфигурационном файле прописать переменную USE_I18N и если она есть, то
> использовать ~/.i18n, если нет - не использовать.

В каком конфигурационном файле?

Можно в том же /etc/sysconfig/i18n, но тогда придётся делать какую-то обвязку, сохраняющую старые значения переменных.

приехали, здрасти.
уже месяца 3 сижу на gdm и сегодня после d-u опаньки.
В самом gdm усе русское, но гном уже locale = C
При запуске через login && startx все в положеной utf-8.

Какая зараза где что оторвала?
~/.i18n не имел с принятия в комсомо^Wгода с 2006го.

Вы предлагаете делать ручки по управлению ручками контроля над ручками?
Я против чрезмерной косвенности.

(В ответ на комментарий №5)
> 1. Я не использую "su -".
> 2. Как вы предлагаете удовлетворить несоместимые желания одновременно?  Сделать
> поведение конфигурируемым?

А это нормально:

login as root
# locale | grep LANG
LANG=POSIX
# su - <username>
$ locale | grep LANG
LANG=POSIX

but if login as <username>
$ locale | grep LANG
LANG=ru_RU.utf8

?

*** Bug 26423 has been marked as a duplicate of this bug. ***

Дмитрий, ответьте, пожалуйста...

(In reply to comment #23)
> (В ответ на комментарий №5)
> > 1. Я не использую "su -".
> > 2. Как вы предлагаете удовлетворить несоместимые желания одновременно?  Сделать
> > поведение конфигурируемым?
> 
> А это нормально:
> 
> login as root
> # locale | grep LANG
> LANG=POSIX
> # su - <username>
> $ locale | grep LANG
> LANG=POSIX
> 
> but if login as <username>
> $ locale | grep LANG
> LANG=ru_RU.utf8
> 
> ?

Да, я полагаю что это вполне допустимое поведение (если закрыть глаза на то, что su - <username> не вполне безопасная операция).

(В ответ на комментарий №26)
> Да, я полагаю что это вполне допустимое поведение (если закрыть глаза на то,
> что su - <username> не вполне безопасная операция).

Согласно man su :
"giving the argument flag -, su is instructed to invoke the shell as a login shell". Т.е. по логике, результат su - должен быть аналогичен, как если бы вошли под username с консоли сервера. А сейчас мы имеем другое поведение.

(In reply to comment #27)
> (В ответ на комментарий №26)
> > Да, я полагаю что это вполне допустимое поведение (если закрыть глаза на то,
> > что su - <username> не вполне безопасная операция).
> 
> Согласно man su :
> "giving the argument flag -, su is instructed to invoke the shell as a login
> shell". Т.е. по логике, результат su - должен быть аналогичен, как если бы
> вошли под username с консоли сервера. А сейчас мы имеем другое поведение.

С другой стороны, результат "su -" аналогичен логину с консоли в той части, которая касается "login shell".  Остальное - это вопрос вариантов трактовки, которых по данному вопросу две.