[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ru_* locale major update.



>Нет, будет так:
>LANG=ru
>LC_ALL=ru_RU.KOI8-R
>
>У них в документации пакета initscripts четко написано, что LANG должен
>быть двухбуквенный.


 Это решение (о двухбуквенном LANG) нельзя признать удачным.
И вот почему.

 Во-первых, это очень сильно отличается от других UNIX-ов.
Практически во всех современных системах применяется
LANG=language_TERRITORY.Codeset
как записано в POSIX.

 Во-вторых, строго двухбуквенный LANG лишает нас возможности
задавать LANG=  типа
ru_RU
ru_UA
ru_BY
ru_KZ
ru_ E.T.C.

 Я понимаю, что у буржуев такая ситуация практически невозможна,
кроме пожалуй Канады, где есть en_CA и fr_CA на уровне
государственных языков. (А денежная категория LC_MONETARY
зависит все-таки от TERRITORY, а не от language :-)

 Кроме того, переменная LANG влияет на ОГРОМНОЕ число
других приложений. Например NLSPATH (поиск message catalog-ов)
содержат подстановки типа :

%N The value of the name parameter passed to catopen().
%L The value of the LC_MESSAGES category.
%l The language element from the LC_MESSAGES category.
%t The territory element from the LC_MESSAGES category.
%c The codeset element from the LC_MESSAGES category.
%% A single % character.

 Да, для NLSPATH все наследуется от LC_MESSAGES, но
множество приложений читает и разбирает непосредственно
LANG например man и MANPATH  (насчет Linux не уверен,
в HPUX - да), семейство MOTIF*PATH, CDE*PATH и т.д.

 Мне кажется, что "стандартный" длинный LANG лучше. И если
есть возможность повлиять на RedHat то надо эту возможность
использовать.

 Теперь насчет LC_ALL . Как известно, такой категории нет,
это "виртуальная" категория обозначающая "все категории
одновременно". В огромном количестве руководств, которое
мне довелось прочитать настоятельно НЕ РЕКОМЕНДУЮТ
делать export LC_ALL мотивируя это тем, что она "слишком
сильная".

 Действительно, LC_ALL "сильнее" чем LANG. То есть приоритеты
расставлены так :

1) LC_CATEGORY   -  конкретная категория (если есть)
2) LC_ALL
3) LANG

 Но к сожалению, многие реализации libc путали п.п 1 и 2
из за стандартной формы вызова : setlocale(LC_ALL,"").

 И уж СОВЕРШЕННО неправильно устанавливать РАЗНЫЕ
значения для LANG и LC_ALL !


 То есть, если бы попросили меня сделать экспертное
заключение ;-) я бы посоветовал :
1) Задавать точное ДЛИННОЕ POSIX значение LANG
2) ни в коем случае не делать export LC_ALL
3) делать локализацию программ, опираясь на LANG

 Насколько я понял, именно по этому пути идет GNU.


 А если кому-то для своих целей уж очень нужно двухбуквенное
значение language, то могли бы и сделать разбор LANG и
подстановку %l как в NLSPATH. Код открыт.

P.S. Кстати, еще существуют переменные LANGUAGE и
LINGUAS. Чьи они и для чего используюся, я не в курсе.
(Вроде LANGUAGE - это от gettext ?)
Вот пусть RedHat c ними и извращается. :-)

--
-=AV=-