On Sat, Jun 26, 2004 at 09:51:27PM +0400, Sergey Vlasov wrote:
> On Sat, Jun 26, 2004 at 09:01:33PM +0400, Dmitry V. Levin wrote:
> > > > If the LANGUAGE environment variable is set to a  nonempty  value,  and
> > > > the  locale  is not the "C" locale, the value of LANGUAGE is assumed to
> > > > contain a colon separated list of  locale  names.  The  functions  will
> > > > attempt  to  look  up  a translation of msgid in each of the locales in
> > > > turn.  This is a GNU extension.
> > > 
> > > gettext как раз ведёт себя в соответствии с этим описанием.  А rpm для
> > > выбора языка описания пакета использует собственные функции, поведение
> > > которых не соответствует поведению gettext.
> > 
> > Ok, поведение очередной сборки librpm в этом вопросе будет идентично
> > поведению gettext.
> 
> Вот, кстати, ещё одно потенциальное несоответствие:
> 
> $ env - LC_CTYPE=en_US.UTF-8 LC_MESSAGES=ru_RU.CP1251 rpm -q --qf='%{SUMMARY}\n' vim-common | iconv -f cp1251
> Общие для всех вариантов VIM файлы
> 
> $ env - LC_CTYPE=en_US.UTF-8 LC_MESSAGES=ru_RU.CP1251 rpm -q --qf='%{GROUP}\n' vim-common | iconv -f utf-8
> Редакторы
> 
> Т.е., gettext (используемый для вывода поля GROUP) при перекодировке
> использует ту кодировку, которая установлена через LC_CTYPE, не
> обращая внимания на кодировку в LC_MESSAGES.  rpm же в подобной
> ситуации сейчас берёт кодировку из LC_MESSAGES.  Это тоже необходимо
> исправлять, иначе в выводе rpm -qi возможна мешанина из кодировок.

Это тоже исправлено, т.е. вывод headerFindI18NString (таких как
%{SUMMARY}) теперь будет происходить по тем же правилам, что и у
gettext(3) (таких как %{GROUP}).


-- 
ldv