[gnome-cyr] =?koi8-r?q?Re=3A_=5Bgnome-cyr=5D_GUADEC=3A_=D0=D2=C1=D7=C9=CC=D8=CE?==?koi8-r?q?=C1=D1_i18n?=

[Vlad Harchev <hvv hippo ru>]

On Tue, 3 Apr 2001, Dmitry G . Mastrukov wrote:

 Привет!

> Всем привет!
> 
> Ниже предлагаю заготовки для subj
> 
> 1. Необходимо помнить, что программа должна функционировать не только
> в non-latin окружении.

 Громкий истерический смех :)

> 2. Одна локаль может быть в нескольких различных кодировках. ru_RU -
> клинический случай. Поэтому желательно отделять кодировку данных (data
> charset) от кодировки представления (display charset) и осуществлять
> при необходимости двунаправленные преобразования с желательным
> контроем пользователя над ними. В случае использования в качестве
> внутреннего представления информации одного из вариантов UNICODE (что
> правильнее и предпочтительнее), преобразование становится
> двухступенчатым. Для преобразования надо использовать стандартные
> средства, типа iconv. Libiconv/libunicode являются переносимыми
> библиотеками.

 Положение дел таково:
 gtk-2.x/glib-2.x работают ТОЛЬКО со строками utf8 внутри (то есть нельзя
вывести строку на экран в кодировке, отличной от utf8). Посему все проблемы
i18n откладываются разработчиками gnome на gnome-2.0 (из-за gtk-2.0 якобы там
все будет для этого). Кстати это сделает все файлы, созданные текущими
версиями софта и содержащими не-utf8 строки, частично нечитабельными. Еще есть
большой вопрос, будет ли весь gtk-2.0 софт работать без доп. исправлений под
локалью с не-utf8 чарсетом если он использует функции, не имеющиеся в glib
(типа strftime(), strcoll() да и просто функции аналоги которых есть в libc -
типа isalpha вместо g_isalpha()). Короче, будующее c gnome-2.0 софтом будет не
таким легким и возможно поначалу даже тяжелее, чем сейчас..

 libunicode вроде как намного более идеологически корректная вещь так как
предоставляет намного большую функциональность вдобавок к iconv(). Вроде бы
все то что предоставляет libunicode будет в glib-2.0.

 Но то, что для некоторых локалей может использоватся разные кодировки, это
да, надо подчеркивать.. Лучше ввести в библиотеку функции для ассоциации
номеров кодовых страниц MS и названий чарсетов (для китайцев есть проблемы -
iconv() не знает их виндовый кодировки под именами cpXXXX), и функции типа
char* microsoft_encoding_name_for_current_locale() которая под LANG=ru вернет
"cp1251" - это сильно поможет программам, которые читают/пишут файлы в
стандартных форматах (типа .xls, .wmf).

> 3. При работе со шрифтами следует помнить, что шрифт может не иметь
> необходимых глифов для кодировки представления. Поэтому при выборе
> шрифтов необходимы различные процедуры отката. Также не следует

 Это IMO не совсем верно. Лучше считать, что фонт имеет все глифы, но что пре
перекодировке из других кодировок в текущую некоторые символы могут быть
непереводимы - и им надо делать интеллегентную замену..

> полагаться на семейство шрифта. Helvetica может быть не только от
> Adobe. (Нужно показать, как правильно указывать шрифт типа
> -*-helvetica-...).
 
  Это да, но у CJK нет helvetica (ну разве что алиас), так что лучше и
название шрифта делать переводимым. А лучше давать имена виджетам и их
документировать - тогда пользователь в gtkrc файле сможет настроить font или
что является единственным способом для CJK, fontset, для этого виджета (просто
через фонт-селектор гнома невозможно определить фонтсет - только фонт).

> 4. Особая сложность в представлении многоязычных документов. Пока нет
> Pango, приложение само должно заботится о грамотном выводе различных

 Я думаю все скажут - подождем до gnome-2.0 и все - каких-то 8 месяцев
осталось.. Короче, неубедительно.

> кодировок шрифтами с различными кодировками на экран. Тут наибольшую
> пользу может оказать использование в качестве внутреннего
> представления данных UNICODE.
> 
> Вот, это всё надо развернуть, конкретизировать, я только направления
> обозначил. Потом, я думаю, у Влада найдётся, что конкретно
> порекомендовать по части кодирования.

 Я думаю что все i18n-потуги и призывы - практически бесполезны и просто
нарушат праздничную атмосферу GUADEC и не оставят только негативное
впечатление у обоих сторон. Разработчикам откровенно наплевать на то, что их
софт не работает у каких-то китайцев (типа пускай сами китайцы и прикручивают
- мол мне не интересно). Короче, я  бы не рекомендовал портить себе нервы и
настроение и отношение со стороны других к вам выступлениям по этому поводу на
GUADEC.. :(

> Дмитрий

 Best regards,
  -Vlad