ALT Linux Team development discussions
 help / color / mirror / Atom feed
From: Sergey Vlasov <vsu@mivlgu.murom.ru>
To: devel@altlinux.ru
Subject: Re: [devel] Локализация и использование функции catgets
Date: Wed, 20 Feb 2002 18:10:36 +0300
Message-ID: <20020220181036.D404@vcserver.mivlgu.ru> (raw)
In-Reply-To: <20020220091225.2dccfbfa.vserge@menatepspb.msk.ru>

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, потом его
убрали - надоело поддерживать.



  reply	other threads:[~2002-02-20 15:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-19 11:09 Volkov Serge
2002-02-19 11:35 ` Sergey Vlasov
2002-02-19 11:41   ` Volkov Serge
2002-02-19 11:47     ` [devel] Re: [devel] Локализация и использование функцииcatgets Anton Farygin
2002-02-19 11:51     ` [devel] Локализация и использование функции catgets Sergey Vlasov
2002-02-19 12:01       ` Volkov Serge
2002-02-19 14:08         ` Sergey Vlasov
2002-02-20  6:12           ` Volkov Serge
2002-02-20 15:10             ` Sergey Vlasov [this message]
2002-02-20 15:44               ` Alexander Bokovoy
2002-02-20 16:49                 ` Sergey Vlasov
2002-02-21  6:04                   ` Volkov Serge
2002-02-19 12:07     ` Dmitry V. Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020220181036.D404@vcserver.mivlgu.ru \
    --to=vsu@mivlgu.murom.ru \
    --cc=devel@altlinux.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

ALT Linux Team development discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
		devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
	public-inbox-index devel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git