Откомпилированные файлы .mo
помещаются в файл
. На системах GNU/Linux base
является /usr/share/locale
. locale
является обозначением языка, например, 'es
', 'fr
' и т.д. category
является категорией локали; для сообщений это LC_MESSAGES
. textdomain
является текстовым доменом программы, в нашем случае это echodate
. В качестве реального примера в /usr/share/locale/es/LC_MESSAGES/coreutils.mo
находится перевод GNU Coreutils на испанский.
Функция bindtextdomain()
изменяет в местоположении часть base
. В ch13-echodate.c
мы меняем ее на '.
'. Таким образом, нужно создать соответствующие каталоги и поместить туда перевод на свинский латинский:
$ mkdir -р en_US/LC_MESSAGES /* Нужно использовать реальную локаль */
$ cp piglat.mo en_US/LC_MESSAGES/echodate.mo /* Поместить файл в нужное место */
Должна использоваться реальная локаль[148]; мы «притворяемся» использующими "en_US
". Разместив перевод, устанавливаем соответствующим образом LC_ALL
, скрещиваем пальцы и запускаем программу:
$ LC_ALL=en_US ch13-echodate /* Запуск программы */
Enteray A Ateday/imetay asay YYYY/MM/DD HH:MM:SS : 2003/07/14 21:19:26
Otgay: Mon Jul 14 21:19:26 2003
Последнюю версию GNU gettext
можно найти в каталоге дистрибутива GNU gettext
.[149]
Этот раздел лишь слегка коснулся поверхности процесса локализации. GNU gettext
предоставляет множество инструментов для работы с переводами, и в особенности для облегчения поддержания современности переводов по мере развития исходного кода программы. Процесс ручного обновления переводов осуществим, но утомителен. Эта задача легко автоматизируется с помощью make
; в частности, GNU gettext
хорошо интегрируется для обеспечения этой возможности с Autoconf и Automake, снимая с программиста значительный груз по разработке.
Рекомендуем прочесть документацию GNU gettext
, чтобы больше узнать как об этих проблемах в частности, так и о GNU gettext
в общем.
В самые ранние дни вычислительной техники различные системы назначали различные соответствия между числовыми значениями и
Оригинальный семиразрядный набор символов ASCII достаточен для американского английского и большинства знаков пунктуации и специальных символов (таких, как $
, но нет символа для «цента»). Однако, имеется много языков и много стран, которым нужны другие наборы символов. ASCII не оперирует версиями романских символов с надстрочными значками, использующимися в Европе, а во многих азиатских языках тысячи символов. Для устранения этих недостатков были разработаны новые технологии.
Литература по интернационализации изобилует ссылками на три фундаментальных термина. Определив их и взаимоотношения между ними, мы сможем представить общее описание соответствующих функций API С.
Определение значений, присваиваемых различным целым величинам; например того, что A равно 65. Любой набор символов, использующий более восьми битов на символ, называется многобайтным
ASCII использует для представления символов один байт. Таким образом, целое значение хранится само по себе, непосредственно в дисковых файлах. Более современные наборы символов, особенно различные версии Unicode[150], используют для представления символов 16-разрядные или даже 32-разрядные целые значения. Для большинства определенных символов один, два или даже три старших байта целого значения равны нулю, что делает непосредственное хранение таких значений на диске неэффективным. Представление набора символов описывает механизм для преобразования 16- или 32-разрядных значений в последовательности от одного до шести байтов для сохранения на диске таким образом, что в целом наблюдается значительная экономия дисковой памяти.