[devel] Локализация и использование функции catgets

Sergey Vlasov =?iso-8859-1?q?vsu_=CE=C1_mivlgu=2Emurom=2Eru?=
Ср Фев 20 19:49:15 MSK 2002


On Wed, Feb 20, 2002 at 17:44:24 +0200, Alexander Bokovoy wrote:
> On Wed, Feb 20, 2002 at 06:10:36PM +0300, Sergey Vlasov wrote:
> > > так что лучше ??? или правильнее использовать с точки зрания
> > > кросплатформенности?
> > 
> > Кстати, у них тут
> > (http://www.openldap.org/lists/openldap-devel/200201/msg00120.html) еще
> > одно требование: сервер должен сам отдавать сообщения на запрошенном языке
> > в UTF-8.  Похоже, gettext при всех своих преимуществах тут пролетает по
> > следущей причине: он использует язык, установленный в LC_MESSAGES.
> > Динамически переключать его неудобно, к тому же сервер, насколько я понял,
> > на pthreads - тут вообще труба, т.к. setlocale действует глобально для
> > всего процесса.
> > 
> > Т.е. gettext хорошо подходит для тех ситуаций, где не нужно переключать
> > язык динамически, но при их подходе к локализации сервера он не годится.
> Неверно. Дело в том, что gettext прекрасно справляется и с этой задачей
> посредством использования функции bind_textdomain_codeset(const char *
> DOMAINNAME, const char* CODESET).

Речь шла не о смене кодировки, а о смене языка. Т.е. клиент посылает (в
расширенном эапросе - они собирались ввести какое-то расширение) код
языка, на котором выдавать ответ; сервер выдает сообщения на этом языке.
Для кодировки, действительно, есть bind_textdomain_codeset; для языка -
надо все равно менять locale.  А кодировка как раз в данном случае
одинаковая - UTF-8 для любого языка.

> > что wchar_t == Unicode, что в общем случае неверно; кроме того, у
> > wcstombs/mbstowcs есть проблемы с кодировками, зависящими от состояния -
> > т.е. сам интерфейс тоже кривоват).  С более новыми и правильными функциями
> > опять та же проблема - они не везде есть.  GNU libiconv (этот точно под
> > LGPL) им опять, вероятно, не понравится?
> Если не понравится, то сами себе они злобные буратины. Других настолько же
> общих и портабельных решений нет.

Понятно.  Просто обидно, что опять можем получить половинчатое решение
проблемы, при том, что уже есть готовые средства для нормального решения.




Подробная информация о списке рассылки Devel