Вход:  Пароль:  
FreeSource: Локализация/ЛокализацияПрограмм ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |

Локализация программ

Оглавление документа

Общие замечания по локализации


Для решения ряда проблем предназначена Библиотека NATSPEC. Она доступна на любом уровне (т.к. находится в /lib) и не имеет зависимостей ни на что, кроме glibc. В частности, перекодирование строк в текущую кодировку может быть осуществлено функцией natspec_convert(строка,NULL,"исх.кодировка")

Использование gettext

Примеры, идущие с пакетом gettext, слишком сложны и «наворочены».

Использование ngettext

Для множественных чисел

Замечания по локализации GTK2-программ

Введение


Как показывает практика, в большинстве программ, написанных на gtk2, вывод в консоль осуществляется с помощью функций printf или g_printf, которая есть ни что иное, как обёртка для printf. Поскольку внутри программ на gtk2 используется кодировка UTF8 (обратных примеров не знаю), на консоль выводится нечитаемая UTF8, без всякого перекодирования.
Но в glib имеется функция g_print, которая осуществляетперекодирование в кодировку консоли. Её и надо использовать


Подлежат проверке сообщения, выводимые на консоль:

Перекодировка строк


Чтобы преобразовать строку в текущую локаль, используйте:

и из локали в utf8:

получаемые с помощью этих функций строки обязательно нужно освобождать после использования с помощью g_free(указатель)

Локализация сообщений


Для локализации сообщений в программе обычно указывается в main():

Обязательно должна быть указана кодировка сообщение в программе через bind_textdomain_codeset! Симптомом нарушения этого правила являются проблемы с сообщениями в программе в неюникодных локалях.

Локализация кавычек


Видимо из-за громоздкости конструкции обычно в переводе не указываются кавычки, а подставляются функцией quote из gnulib, которую проекты (с лицензией GPL) таскают с собой.
Подробности в статье ситуация с кавычками.

Общие рекомендации


Работа с файлами и файловыми диалогами


Кодировка файловой системы может не совпадать с локалью, поэтому в glib введены отдельные функции для перекодирования:

получаемые с помощью этих функций строки обязательно нужно освобождать после использования с помощью g_free(указатель)


Во внутренних структурах программы рекомендуется хранить название файла в filesystem encoding (которая получается
с помощью g_filename_from_utf8), но выдавать на редактирование и сохранять в конфигурационные файлы – в utf8.


Возможно использование функции g_filename_from_uri. В чём преимущества пока не знаю, но она используется, если предполагается открытие не только локальных файлов, но и сетевых ресурсов.


Для дублирование строк используется функция
g_strdup
или 
g_strdup_printf


Файловому диалогу передаётся название файла в filesystem encoding. Устанавливается название файла такой конструкцией:
gtk_file_selection_set_filename(GTK_FILE_SELECTION(opendlg), filename);
Получается название файла так:
filename = gtk_file_selection_get_filename(GTK_FILE_SELECTION(fs));


Вот типичный код получения названия файла в кодировке UTF8 (взят из dia):

Проблемы (с glade)


Система Программа Интерфейс (GTK) Проблемы
koi8-r koi8-r UTF-8 программа должна внутри перекодировать всякое общение с граф. интерфейсом
koi8-r UTF-8 UTF-8 программа должна перекодировать всякое общение с внешним миром (консоль и названия файлов)
UTF-8 UTF-8 UTF-8 самый безпроблемный вариант

Замечания по локализации QT/KDE программ


О интернационализации KDE-программ:

Работа с файлами и файловыми диалогами

При получении названия файла от диалога

перед использованием для открытия файлов нужна перекодировка


Перевод одинаковых строк по-разному


При переводе часто встречается ситуация, когда одинаковые строки, встречающиеся в разных частях программы, должны переводиться по-разному. gettext же объединяет такие строки. Лечится это добавлением комментариев к исходной строке,
для чего существует макрос I18N_NOOP2 в KDE. Совет устарел, см. kde-i18n-howto. Сам макрос, естественно, можно портировать куда угодно, если разработчикам соответствующего софта это интересно. В KDE используется патченный вариант xgettext. Но и в непатченном xgettext должна быть возможность использовать комментарии к строкам, так что какой-то вариант этого решения доступен и в Gtk / GNOME?.

Десятичный разделитель


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


Порядок испытания программы на корректную работу с локалью


Проблема работы с файлами, названными по-русски, может возникнуть в любой программе. Вот примерный план проверки:


  1. Сохранение файла с русским названием в английский каталог
  2. Сохранение файла с русским путём к файлу
  3. Корректное название вновь создаваемого файла (в диалоге Создать)
  4. Открытие файла по русскому пути (во всех возможных диалогах вставки и открытия файла)
  5. Проверка экспортируемых файлов (например EPS на предмет корректности оформления цифр (десятичный разделитель): файлы не должны отличаться при запуске программы просто и через $ LANG=C программа
  6. Запуск программы с указанием русского названия файла в качестве параметра

Дополнительное замечание:
Файловые диалоги при повторном обращении должны помнить предыдущий каталог.


Vitaly Lipatov <lav@altlinux.ru>, 2004–2005
Vyacheslav Dikonov <slava@altlinux.ru>, 2005

Ссылки


Страницы, ссылающиеся на данную: Локализация/НациональнаяСпецификаСистемы


 
Файлов нет. [Показать файлы/форму]
Много комментариев (4). [Показать комментарии/форму]