[devel] Локализация и использование функции catgets
Sergey Vlasov
=?iso-8859-1?q?vsu_=CE=C1_mivlgu=2Emurom=2Eru?=
Ср Фев 20 18:10:36 MSK 2002
On Wed, Feb 20, 2002 at 09:12:25 +0300, Volkov Serge wrote:
> On Tue, 19 Feb 2002 17:08:29 +0300
> Sergey Vlasov <vsu на mivlgu.murom.ru> wrote:
>
> > On Tue, Feb 19, 2002 at 15:01:31 +0300, Volkov Serge wrote:
> > > Да хочется ввести полную локализацию и в библиотеки и в сообщения
> > > выдаваемые утилитами и так далее
> > > Координатор проекта настаивает на catgets а мне кажется что это не
> > > перспективно :((( хотя что я видел :()
> >
> > catgets имеется в большем количестве коммерческих Unix-систем, чем
> > gettext - возможно, дело в этом, и они просто не хотят вводить лишнюю
> > зависимость от GNU gettext.
>
> вот именно и поэтому Координатор проекта цитирую :
>
> While I'm not aware of any locale specific problems with catgets(3),
> my knowledge in this area is VERY limited, hence I will refrain
> from comment here.
>
> But I believe my statement that catgets(3) is more widely
> available than gettext(3) is true.
Понятно.
> так что лучше ??? или правильнее использовать с точки зрания
> кросплатформенности?
Кстати, у них тут
(http://www.openldap.org/lists/openldap-devel/200201/msg00120.html) еще
одно требование: сервер должен сам отдавать сообщения на запрошенном языке
в UTF-8. Похоже, gettext при всех своих преимуществах тут пролетает по
следущей причине: он использует язык, установленный в LC_MESSAGES.
Динамически переключать его неудобно, к тому же сервер, насколько я понял,
на pthreads - тут вообще труба, т.к. setlocale действует глобально для
всего процесса.
Т.е. gettext хорошо подходит для тех ситуаций, где не нужно переключать
язык динамически, но при их подходе к локализации сервера он не годится.
В любом случае всплывает неприятный вопрос перекодировки. Одно из
возможных решений - отдавать из -lldap _все_, в том числе и сообщения об
ошибках, в UTF-8 - все равно правильный клиент должен уметь работать с
UTF-8 в данных, так почему бы ему не разобраться тем же способом и с
ошибками? Это, правда, будет работать только в том случае, если они не
вставляют в сообщения строки с именами файлов, strerror(errno) и т.п.
С другой стороны, функции преобразования у них вроде бы есть -
ldap_x_utf8s_to_mbs и т.п., только реализованы они коряво (предполагается,
что wchar_t == Unicode, что в общем случае неверно; кроме того, у
wcstombs/mbstowcs есть проблемы с кодировками, зависящими от состояния -
т.е. сам интерфейс тоже кривоват). С более новыми и правильными функциями
опять та же проблема - они не везде есть. GNU libiconv (этот точно под
LGPL) им опять, вероятно, не понравится?
> > > по поводу gettextize а где скрипты лежат так как я думаю что луше
> > > библиотеку записать где все библиотеки в проекте лежат
> > > /libraries
> >
> > rpm -ql gettext-devel и т.п. - или этого мало?
>
> не если говорить о gettext то вполне достаточно
> а если о catget то нет не могу понять как подготавливать исходники к
> работе :((
apt-get source blackbox, например - хотя там тоже слегка кривовато.
> Да кстати есть ли возможность совсемтить использование и той и другой
> функций ???
> т.е.можно ли установить взаимнооднозначное соответствие?
В старых версиях gettext был вариант работы через catgets, потом его
убрали - надоело поддерживать.
Подробная информация о списке рассылки Devel