[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=-