Пока я описывал, как заставить различные программы понять кириллицу. Обычно каждая программа требовала, чтобы это был ее собственный метод, как правило, чрезвычайно отличный от других. Кроме того, у некоторых программ была незавершенная поддержка языков, отличных от английского, не говоря уж об их неспособности взаимодействовать, используя родной язык пользователя вместо английского.
Проблемы, перечисленные выше, сильно подавляют, так как программное обеспечение редко создается только для местного рынка. Переработка существенных частей программного обеспечения каждый раз при входе на новый международному рынок очень неэффективна; а интернациональная поддержка, осуществляемая собственными средствами программы, уникальным и присущим только ей способом, в терминах долгосрочного планирования также не блестящая идея.
Следовательно, возникает потребность в стандартизации. И стандарт есть.
Все связанное с вышеперечисленными проблемами разделено в соответствии c двумя базисными концепциями: localization и internationalization. Под локализацией мы имеем в виду создание программ, способных обрабатывать различные языковые соглашения для различных стран. Позвольте привести пример. Формат даты, принятый в Соединенных Штатах, имеет вид ММ/ДД/ГГ. Однако в России наиболее популярный формат -- ДД.ММ.ГГ. Другие проблемы включают в себя представление времени, форматы числа и представления валюты. Кроме этого, один из наиболее важных аспектов локализации -- это определение соответствующих классов символов, то есть определение, какие символы в наборе символов являются "кирпичиками" языка (буквами) и как они упорядочиваются. С другой стороны, локализация не работает со шрифтами.
Интернационализация (или i18n для краткости), как предполагается, решает проблемы, связанные со способностью программы взаимодействовать с пользователем на его родном языке.
Обе эти концепции должны быть стандартизованы, давая программистам непротиворечивый путь создания программ, работающих в национальной среде.
Хотя стандартизация еще в процессе, много ее частей уже фактически являются стандартом, так что они могут использоваться без особых проблем.
Я опишу общую схему создания программ, использующих описанные выше возможности стандартным способом. Так как это заслуживает отдельного документа, я буду давать только очень общее описание и указатели на более полные источники.
Одно из основных понятий локализации -- locale. Под locale подразумевается набор соглашений, специфических для отдельно взятого языка в отдельно взятой стране. В общем случае говорить, что locale определяется только страной, неправильно. Например, в Канаде могут быть определены два locale -- язык Канада / Английский и язык Канада / Французский. Более того, язык Канада / Английский не является эквивалентом языку Великобритания / Английский или Американский / Английский, точно так же Канада / Французский язык -- не эквивалент языку Франция / Французский или языку Швейцария / Французский.
Более подробное описание проблем/возможностей/достоинств локализации на русском языке можно найти на страничке Локализация, как она есть.
Каждая locale -- это специальная база данных, определяющая, по крайней мере, следующие правила и соглашения:
Прежде всего -- подробная документация о локали имеется на www.sensi.org/~alec/locale Обращайтесь туда, если вам нужны нестандартные варианты (например, отключение русскоязычного интерфейса с сохранением правильной сортировки и т.д.)
Документацию по иксовой локали можно найти по адресу www.tsu.ru/~pascal/x_locale/
Вот инструкция для нетерпеливых (только для glibc).
Вам нужно:
/usr/share/locale и создать там симлинк
ru_RU.KOI8-R,
указывающий на ru_SU.
Эта операция необходима только для glibc < 2.1.2.
/etc/sysconfig/i18n, где, кроме прочего, должна быть строчка
LANG=ru_RU.KOI8-RВ общем случае можно прописать в
/etc/profile
LANG=<ваша кодировка> export LANG
Гораздо же честнее сделать отдельный настоящий каталог:
/usr/share/locale/ru_RU.KOI8-R/ (конечно, если его нет в
данном дистрибутиве).
Некоторые дистрибутивы неправильно включают
LANG=ru LC_ALL=ru_RU.KOI8-R
Это НЕПРАВИЛЬНО, почему так делать нельзя -- описано ниже.
А теперь поговорим о том же, но гораздо подробнее. Итак:
Как включить локализацию?
Если на UNIX машине (с POSIX:1996) средства locale правильно установлены и программы правильно написаны, то локализация включается путем задания строки окружения LANG:
$ export LANG={язык}
Если такой строки окружения нет, то работает значение локализации
по умолчанию: LANG="C" или LANG="POSIX"
(что то же самое) -- минимальный набор параметров, необходимый
для функционирования программ на ANSI C (ISO 9899:1990), в
кодировке US-ASCII (7 bit) (
Portable Character Set).
Если ваша система имеет полный набор утилит POSIX.2, то узнать
установленные в системе и допустимые значения для LANG= можно
командой locale:
$ locale -a
По новому стандарту (POSIX.2 приложение E (?)) значения локализации записываются в форме:
language_TERRITORY.Codeset
или формально:
language[_TERRITORY[.Codeset[@modifier]]]
Стандарт ISO 639 описывает "language names",
ISO 3166 -- "territory names". Территории _SU более не
существует (вернее, теперь она означает Судан), однако для
совместимости некоторые системы продолжают ее
поддерживать как alias: ru_SU --> ru_RU.
Для русского языка LANG устанавливается, как правило,
равным LANG="ru_RU.KOI8-R" или LANG="ru_RU.ISO_8859-5". То есть:
$ export LANG="ru_RU.KOI8-R"
Согласно стандарту допустимы также короткие именования значений locale,
которые часто оформляются как aliases (псевдонимы) полного наименования.
Например "C" --> "POSIX".
$ export LANG=ru $ export LANG=ru_RU $ export LANG=ru_RU.KOI8-R
Однако, если вы указываете короткое имя, может оказаться, что ваша кодировка оказывается вовсе не KOI8-R (почему следует использовать именно koi8-r, описано в разделе Символы и кодировки). Лучше не пользоваться значениями по умолчанию, а указывать точное длинное имя.
Во FreeBSD 2.x так и есть. Для Linux -- зависит от дистрибутива. В коммерческих реализациях (Solaris, SCO, AIX etc) как правило используется значение LANG="ru_RU", или укороченное LANG="ru" (и как правило, Codeset ISO8859-5 по умолчанию).
Некоторые могут пожелать сделать себе локализацию в другом наборе символов:
ru_RU.X-CP-866 (ru_RU.IBM866), ru_RU.x-mac-cyrillic,
ru_RU.ISO_8859-5 или даже ru_RU.CP1251 -- на это нет никаких
ограничений. Все эти кодировки совершенно равноправны и
зарегистрированы (кроме x-mac-cyrillic) в IANA.
Только не забудьте, что локализация, ввод-вывод и отображение
национальных символов на терминале -- это совершенно разные вещи.
Если система локализована не полностью и использовать полное
переключение на другой язык (с помощью export LANG={язык}) нельзя,
можно включить locale только для функций locale API
библиотеки libc, задав значение категорий локализации. Можно
также присваивать разные значения разным категориям, задавая их
имена в строках окружения:
Если вас раздражают русские даты, сообщения и man-ы, но нужно обрабатывать русские буквы и т.д., то сделайте:
$ export LANG="C" $ export LC_CTYPE="ru_RU.KOI8-R" $ export LC_COLLATE="ru_RU.KOI8-R" $ export LC_TIME="C"
Не рекомендуется использовать строку окружения:
$ export LC_ALL={язык}
поскольку формально такой категории локализации нет, она
"виртуальная" и обозначает "одновременно все категории". Из-за этого
во многих реализациях locale API возникают проблемы.
Проблемы могут возникнуть также с программами, работающими с
PostScript: в категории LC_NUMERIC
локализации ru_RU в соответствии со стандартом ГОСТ в качестве
десятичного разделителя используется символ 'запятая': "," в то время,
как в стандарте языка PostScript -- точка "." А категория LC_NUMERIC
оказывает влияние на printf("%f",float);. Используйте значение
C (POSIX) для LC_NUMERIC, если вы работаете с PostScript:
$ export LC_NUMERIC="POSIX"
Посмотреть текущие значения категорий локализации можно все той же утилитой locale (без параметров).
$ locale
ПРИМЕЧАНИЕ: В некоторых современных системах начинает появляться локализация в UNICODE. Включается она заданием строки окружения LANG="ru_RU.UTF-8" для России.
В RedHat Linux (как, вероятно, и во многих других дистрибутивах Linux),
имеются фактически две базы
данных locale: одна для библиотеки C (libc), а другая - для X
библиотек. В идеальном случае должна иметься только одна база
данных locale для всего.
Чтобы изменить значение locale по умолчанию, обычно
достаточно установить системную переменную LANG. Например, как
это делается в sh:
LANG=ru_SU export LANG
Вы можете проверить действие этой команды сразу же, если запустите
команду date. Результатом должен быть вывод дня, недели и месяца на
русском языке.
RedHat 5.x определяет KOI8-R locale как ru_SU.
Более очевидное название ru_RU используется
для locale, основанного на iso-8859-5 кодировки.
Иногда вы можете захотеть изменить только один аспект locale
без изменения других. Например, вы можете захотеть (всякое в жизни
случается) пользоваться ru_SU locale, но печатаемые числа должны
будут соответствовать стандарту POSIX один. В подобных случаях
имеется набор системных переменных, которые Вы можете задать,
чтобы сконфигурировать соответствующие части locale. Например, в
нашем случае это бы выглядело так:
LANG=ru_SU LC_NUMERIC=POSIX export LANG LC_NUMERIC
Подробнее см. locale(7).
Теперь давайте держаться поближе к специфике Linux.
К сожалению, в Linux libc версии 5.3.12 (пример: дистрибутив
RedHat 4.1), отсутствует русская locale. В данном случае ее надо
скачать из Interneta (я, однако, не знаю точного адреса).
Чтобы проверить, для каких языков у вас есть locale, выполните
'locale -a'. Это выведет список всех locale из баз данных,
доступных libc.
Что касается библиотек X, то они имеют свою собственную базу
данных locale. В версии XFree86 3.3 уже
имеется российская база данных locale. Я не уверен, есть ли она в
предыдущей версии. В любом случае вы можете проверить это,
изучив директорию /usr/lib/X11/locale/ (в большинстве систем). В
моем случае уже есть подкаталоги, именованные koi8-r и даже
iso8859-5.
С locale программа не должна знать о различных символьных преобразованиях и правилах сравнения, описанных выше. Вместо этого они используют специальный API, который действует по правилам, определенным locale. Кроме того, нет необходимости для программы пользоваться только одной locale для соблюдения всех правил -- возможно пользоваться другими правилами, описанными в других locale (хотя такой метод не очень хорош).
Из man setlocale(3):
Программа может быть сделана переносимой для всех locale, вызываяsetlocale(LC_ALL, "" )после инициализации программы, используя значения, возвращенные из запросаlocaleconv()для locale-зависимой информации, и используяstrcoll()илиstrxfrm()для сравнения строк.
Довольно легко определить четыре уровня программной локализации:
setlocale(). Она не делает каких-либо предположений
относительно 8-ого бита каждого символа, используя
пользовательские функции из ctype.h и ограничения из limits.h, а также
заботится относительно signed/unsigned результата.
Очень важно, чтобы программа не делала каких-либо предположений
относительно характера набора символов и их упорядочения. То есть
следует воздержаться от следующих конструкций при
программировании:
if (c >= 'A' && c <= 'Z') {
...
ctype.h.
Например:
if (isalpha(c) && isupper(c)) { ... или
if (isascii(c) && isupper(c))
strcoll() и strxfrm() вместо strcmp() для строк,
использует time(), localtime(), и strftime() для работы со
временем, и в заключение, использует localeconv() для
правильного представления чисел и валюты.
gettext() (Sun/POSIX стандарт), или catgets()
(X/Open стандарт). Подробнее см. раздел
i18n
.
char. Взамен этого она использует wchar_t, который
определяет объекты, достаточно большие, чтобы содержать символы
Unicode. ANSI C определяет этот тип данных и соответствующий API.
Для выяснения подробностей смотрите, например, ( Voropay1 ) или ( SingleUnix ).
В то время как локализация описывает как адаптировать программу к иностранному окружению, интернационализация (или i18n для краткости) детализирует способы общения программы с не-англоговорящим пользователем.
Прежде это делалось с помощью создания абстракций сообщений для вывода их из кода программы. Теперь такой механизм (более или менее) стандартизирован. И, конечно, есть его free реализации!
Проект GNU, наконец, стал на путь создания
интернационализированных прикладных программ. Ulrich Drepper
(drepper@ipd.info.uni-karlsruhe.de) разработал пакет gettext.
Этот пакет лежит во всех GNU архивах, например, в
prep.ai.mit.edu.
Он позволяет вам разрабатывать программы в направлении, двигаясь
в котором вы можете легко заставить их поддерживать большее
количество языков. Я не предполагаю описывать методы
программирования еще и потому, что gettext пакет поставляется с
превосходным руководством.
Просьба о сотрудничестве: Если вы хотите изучить пакет gettext
и сделать свой вклад в проект GNU или просто сделать вклад без
всякого изучения, то вы можете сделать это! GNU становится
международным, так что все утилиты делаются locale зависимыми.
Проблема состоит в том, чтобы переводить сообщения с Английского
языка на Русский (и другие языки, конечно если захотите). В
общем, что следует сделать: вы должны получить специальный .po
файл, состоящий из Английских сообщений для неких утилит, и
связать каждое сообщение с его эквивалентом на русском. В конечном
счете, это заставит говорить систему по-русски, если пользователь
захочет этого! Для для подробностей войдите в контакт с Ulrich
Drepper (
drepper@ipd.info.uni-karlsruhe.de).