Функции gettext


Содержание

Функции Gettext

Введение

Функции gettext реализуют NLS (Native Language Support) API, который может использоваться для интернационализации ваших PHP-приложений. Просмотрите документацию о gettext для вашей системы по адресу http://www.gnu.org/manual/gettext/index.php.

Требования

Для использования этих функций вы обязаны загрузить и установить пакет GNU gettext с http://www.gnu.org/software/gettext/gettext.php

Установка

Чтобы включить поддержку GNU gettext в ваше построение PHP, вы обязаны добавить опцию
--with-gettext[=DIR], где DIR это директория установки gettext, по умолчанию это /usr/local.

Конфигурация

Это расширение не определяет никаких директив конфигурации.

Типы ресурсов

Это расширение не определяет никакие типы ресурсов.

Предопределённые константы

Это расширение не определяет никаких констант.

Содержание bind_textdomain_codeset — специфицирует кодировку символов, в которой будет написано сообщение, возвращённое из каталога сообщений DOMAIN bindtextdomain — устанавливает путь к домену dcgettext — переопределяет domain для отдельного просмотра dcngettext — множественная версия dcgettext dgettext — переопределяет текущий домен dngettext — множественная версия dgettext gettext — просматривает сообщение в текущем домене ngettext — множественная версия gettext textdomain — устанавливает домен по умолчанию Оглавление

GetText. Многоязычные приложения. Профессиональная работа.

GetText и PHP

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

Организация подобных приложений сложна, потомучто она влечет за собой множество проблем и вопросов, которые разработчику приходится решать. Неправильное проектирование такого приложения ведет к тому, что добавление нового языка в проект сопровождается изменением таблиц, редактированием скриптов и другими всевозможными подводными камнями. В результате таких переработок проект может начать работать нестабильно или вообще перестать работать, такие переделки могут потребовать значительных временных и рабочих ресурсов. В общем, в этом материале мы поговорим с вами о том, как же упростить себе жизнь на этапе проектирования и по максимуму облегчить процессы, описанные выше.

GetText – описание возможностей

В преодолении вышеуказанных препятствий, система GetText предлагает нам помощь в следующем:

  • освобождает наши скрипты от языкозависимых данных, точнее нам не надо будет заботиться о том, с каким языком будут работать наши скрипты;
  • предлагает набор утилит для работы с языковыми данными;
  • а также, разработки сторонних авторов позволяют в значительной степени облегчить труд переводчиков и стандартизировать данные;
  • и, очень важная особенность, если вы по каким-то причинам не перевели те или иные строки, скажем, на китайский, то GetText вернем вам их на языке поумолчанию (обычно английский), что очень удобно, так как освобождает нас от полного перевода всех текстов.

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

От описательной части, перейдем к делу.

Найтройка GetText

Прежде чем перейти к процессу освоения новой технологии, давайте произведем установку нужного софта, или проверим наличие оного.

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

Для получения нужных нам файлов идем сюда: http://sourceforge.net/projects/gettext. На этой странице вы найдете два пакета программ: gettext-win32 и libiconv-win32. Первый – это собственно файлы GetText, второй – это утилита для работы с текстом в разных кодировках, которая таже требуется для нормальной работы GetText. Вам необходимо скачать файлы: gettext-runtime-0.13.1.bin.woe32.zip (это уже скомпилированные под Windows файлы GetText) и gettext-tools-0.13.1.bin.woe32.zip (это скомпилированные вспомогательные утилиты), а также libiconv-1.9.1.bin.woe32.zip (это скомпилированные файлы iconv).

Для дальнейшей установки нам понадобятся файлы: gettext-runtime-0.13.1.bin.woe32.zip и libiconv-1.9.1.bin.woe32.zip.

Скопируйте файлы intl.dll, gettext.exe, asprintf.dll, envsubst.exe, ngettext.exe из первого пакета в папку SYSTEM32 вашей Windows, затем тоже самое проделайте с файлами charset.dll, iconv.dll, iconv.exe из второго пакета.

Теперь перейдите в папку dlls вашей инсталляции PHP и скопируйте из нее файл libintl-1.dll в туже папку, что и предыдущие файлы.

Далее, найдите php.ini (как правило он находится в папке установки PHP или в папке WINDOWS вашей системы). Раскомментируйте в нем 2 строки: extension=php_gettext.dll (чтобы включить поддержку GetText) и extension=php_iconv.dll (чтобы включить поддержку iconv). Теперь перезапустите ваш сервер (например, Apache) и посмотрите phpinfo();. PHP сообщит вам, что GetText и iconv расширения подключены и включены (enabled).

У нас остался еще один пакет: gettext-tools-0.13.1.bin.woe32.zip. Создайте на своем диске отдельную папку и распакуйте эти утилиты туда.

Поскольку мы с вами говорим о профессиональной работе, то нам понадобится бесплатный редактор poedit (http://www.poedit.org/). Установите его, он нам понадобится в дальнейшем.

И так, когда все действующие лица собраны воедино, давайте посмотрим, как же это работает.

взгляд изнутри

Как правило, наши с вами скрипты в той или иной форме выводят данные. Данные эти можно разделить на несколько типов. Нас в данном случае интересуют статические тексты, которые “зашиты” внутри наших скриптов. Это, например, сообщения об ошибках, какие-то другие вспомогательные данные. Наша задача с вами избавиться от необходимости редактирования скриптов (здесь не имеется ввиду доработка скриптов или исправление ошибок).


Для начала, нам необходимо проделать с нашими скриптами несложные изменения, эти изменения вносятся 1 раз и более никогда. В дальнейшем нам просто надо будет сразу придерживаться определенных правил.

В качестве отступления, я приведу некоторые рассуждения. Часто начинающие, и даже не очень, программисты в своих скриптах пишут сообщения на русском языке. Впреть, я советую вам избавляться от такого подхода и писать сообщения латиницей. Причин здесь несколько: во-первых, при использовании нелатиницы возникает вопрос о кодировке, в которой сообщения содержатся в ваших скриптах, что вызывает дополнительные неудобства для пользователей, которые не говорят по-русски или не совсем разбираются в обилии кодировок, во-вторых, это привносит сложность, когда вам внезапно придется изменить кодировку своего приложения – здесь могут полезть разные нестыковки (один скрипт в одной кодировке, другой – в другой), такой подход вызовет много дополнительных действий. Вы плохо знаете английский? Ничего страшного – пишите мета-тэги, переводчик в последующем сможет подправить любую вашу неправильную фразу, не правя для этого скрипты.

И так, вернемся к тому, что же необходимо проделать с нашими скриптами.

Как правило, в скриптах строки используются следующим образом:

Установленное выше расширение PHP добавляет в наш арсенал несколько команд, при помощи которых мы можем преобразовать примеры выше следующим образом:

Эти примеры полностью идентичны. Советую использовать первый способ, так как он более экономичный в плане записи и, на мой взгляд, более наглядный, так как не вносит в структуру скрипта значительного “мусора”.

И так, наши скрипты переделаны указанным способом и мы переходим к следующему этапу.

утилита XGetText

Изменить скрипты – это только половина работы. Что же делать дальше? А дальше нам необходимо создать 2 файла, которые будут содержать в себе все, “обернутые” указанной выше конструкцией, строки. В первом файле они будут содержаться в виде текста, а второй файл – это скомпилированная версия первого.

Для начала нам необходимо извлечь все строки из наших скриптов. Поможет нам в этом утилита xgettext.exe из пакета утилит.

В упрощенном виде, вам необходимо запустить ее следующим образом:

В результате вы получите первый файл: messages.po.

Давайте рассмотрим другие команды этой утилиты:

—files-from=FILE – вы можете составить перечень всех своих скриптов создав отдельный файл, где каждая строка – это название файла. Тогда за один проход утилита может обработать сразу все ваши скрипты. В результате работы вы получите ЕДИНЫЙ .po файл.

—directory=DIRECTORY – добавить директорию в список для поиска скриптов.

—default-domain=NAME – NAME определяет название .po файла (NAME.po).

—output=FILE – перенаправляет вывод данных в указанный (FILE) файл.

—output-dir=DIR – выходящие файл будут созданы в каталоге DIR.

—language=NAME – NAME указывает на каком языке программирования вы написали свои скрипты, в данном случае PHP.

—join-existing – если у вас уже есть .po файл, то вы можете добавлять к нему строковые данные при помощи этой команды не создавая нового файла.

—exclude-file=FILE.po – если в новых скриптах есть строки, которые уже есть в вашем .po файле, вы можете пропустить такие строки при помощи этой команды.

—extract-all – эта команда заставит утилиту извлекать все строки подряд без определения языка программирования. Использование этой опции не рекомендуется – вы получите слишком “мусорный” .po файл.

—keyword[=WORD] – вы можете задать список так называемых стоп слов, которые будут пропущены утилитой.

Остальные опции вспомогательные и вы можете разобраться с ними сами, запустив xgettext —help для вывода англоязычной подсказки.

И так, файл создан, что дальше?

Описание .PO файла

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

Далее я приведу пример такого файла:

По сути, это и есть файл, который вы должны отдать переводчику. Переводчик должен задать значение следующим строкам:

Тут многие из вас, наверное, почешут голову и скажут, что все это полный отстой. Советую дочитать материал до конца и вы поймете, что все вовсе не так плохо, потому что далее мы также рассмотрим заявленную нами в названии статьи “профессиональную” работу.

Далее, давайте рассмотрим структуру заголовка файла (только самые важные):

Укажите здесь свои авторские копирайты.

Версия проекта и его название.

Укажите здесь имя и емаил адрес переводчика.

Название языка (например, Russian).

Кодировка, в которой сделан перевод (например, UTF-8). Рекомендую вам всегда делать переводы в Unicode кодировке UTF-8. Это избавит вас от многих проблем, а данные от GetText вы всегда сможете получить в той кодировке, в которой вам необходимо.

Ну вот, все заголовки заполнены, а сообщения переведены – двигаемся дальше.


утилита MsgFmt

GetText не может работать с .po файлом. Чтобы информация из него стала доступной, его надо скомпилировать. Этим занимается заявленная в названии утилита. В результате ее работы у вас появится второй файл с расширением .mo.

Вот, собственно, и все.

структура каталогов

Для удобства, создайте в корне своего приложения папку locale. Внутри этой директории необходимо создать папки для каждого из поддерживаемых языков: ru/, en/ и так далее. Внутри них необходимо создать папку LC_MESSAGES, а в эту папку, в свою очередь, необходимо поместить созданные нами .mo файлы для каждого языка (.po файлы можете поместить туда же, это не помешает).

Давайте посмотрим, как будет выглядеть дерево папок в финальном виде:

Для правильного нахождения двухбуквенного сочетания для каждого языка воспользуйтесь этой таблицей: http://www.loc.gov/standards/iso639-2/langcodes.html, или документацией по GetText.

В предыдущих нескольких главах мы с вами познакомились с технологией работы GetText. Настало время рассмотреть варианты “Профессиональной работы”.

профессиональная работа

Все описанные выше шаги необходимы для понимания как все это работает и что за чем следует. Но, как вы понимаете, это все очень сложно и не всегда доступно. Например, врядли вы толково сможете объяснить все это переводчику, а уж тем более просить его переводить какой-то файл непонятного формата – это задача не из легких.

На этом этапе мы с вами воспользуемся замечательным бесплатным редакторов poedit, который вы уже скачали и установили себе в одной из первых глав нашего повествования. С запуском этого редактора мы переходим к профессиональной части.

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

При первом запуске выберите язык интерфейса (поддерживается русский). А также редактор попросит ввести ваше имя и емаил. Другие установки оставьте поумолчанию. Во вкладке “Парсеры” удалите все, кроме PHP.

И так – начинаем работать. Во вкладке “Файлы” выбираем “Новый каталог”.

Далее заполняем появившуюся форму.

В следующей вкладке задайте путь (пути), где находятся скрипты вашего проекта.

Теперь жмем “ОК”. Редактор начнет рекурсивно обрабатывать все найденные в указанной папке и ее подпапках скрипты на предмет наличия в них “обернутых” строк.

По окончании работы, редактор создаст .po файл и предложит сохранить его на диск. Это файл-проект, который содержит в себе все сообщения, которые нуждаются в переводе для всего вашего проекта (или тех скриптов, которые редактор нашел по указанному вами пути).

Перед вами появится меню, в котором содержится перечень всех новых строк, которые нуждаются в переводе, а во второй вкладке будут показаны те строки, которые исчезли (удалены за ненадобностью) из ваших скриптов. После нажатия “ОК”, .po файл будет обновлен – новые строки добавятся, старые удалятся.

Редактор сам попробует подобрать перевод к новым строкам из уже имеющихся переведенных строк. Строки, к которым перевод удалось подобрать (обращаю ваше внимание, что редактор делает это по странному алгоритму и вам не стоит на него надеяться), будут выделены коричневым цветом. Строки, к которым перевод не подобран и которые нуждаются в переводе будут сине-зелеными, белые строки – это нормально переведенные строки.

И так, теперь, если передать редактор вместе с .po файлом переводчику, то ему будет очень легко и понятно переводить указанный файл. Редактор поддерживает все языки (в том числе и китайские иероглифы). Давайте рассмотрим все элементы редактора.

БЛОК 1 – это блок вспомогательного меню, куда вынесены некоторые нужные функции. Первые 2 иконки понятны, о третьей я расскажу ниже. Четвертая иконка включает показ кавычек в окнах оригинала (БЛОК 3) и перевода (БЛОК 4). Пятая иконка — если нажата, то это означает что для строки был подобран перевод самим редактором и этот перевод не точен. Следующая иконка вызывает окно редактирования комментария (БЛОК 6). В поле комментария вы можете дать пояснение переводчику к любой, требующей перевода, строке. Следующая иконка убирает заголовок окна, растягивая область экрана на весь декстоп. Последняя иконка – вызов справки. БЛОК 5 – блок автоматических комментариев. БЛОК 2 – это перечень всех переведенных и непереведенных строк. Нажмите на любую строку, чтобы произвести перевод или отредактировать его.

Как видите, процесс перевода очень прост и вот уже скоро (буквально после нажатия кнопки сохранить) редактор создаст для вас автоматически файл .mo.

У редактора есть еще одна крайне полезная функция. Которая прячется за неописанной ранее иконкой . она нам понадобится, когда в наш проект внесены изменения: какие-то скрипты удалены или значительно дополнены или просто внесены в них изменения.

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

Таким образом, вы получаете мощный инструмент для автоматизированного перевода ваших приложений на разные языки, а также удобный инструмент для переводчика.

Теперь мы с вами переходим к финальной части нашего рассказа – а именно к тому, как же всетаки .mo файл заставляет наши скрипты говорить на разных языках.

Do you speak по-русски?

Наконец все нужные файлы созданы и переведены, и вы с чистым сердцем можете заставить ваше приложение бодро откликнуться на нужном вам языке. Давайте посмотрим, как это работает.

Илон Маск рекомендует:  Что такое код swfdisplayitem >move

В конфигурационный файл или в самом начале вашего индексного файла необходимо добавить следующие строки.

Пройдемся по порядку.

Эта строка включает нужную пользователю кодировку. В данном случае русскую. А вот таким образом включаем английскую:

Теперь нам необходимо настроить локаль, в которой работаем. Для русской локали это выглядит так:

Для английской – так:

Все сообщение теперь будут выводиться в кодировке, соответствующей выбранной вами локали. Если это вас по каким-то причинам не устраивает, можно указать кодировку принудительно. Вот такая команда включит принудительно Unicode (UTF-8).

Переменная $domain в данном случае указывает домен (или имя файла .mo) нашего проекта. Все файлы .mo должны называться так: $domain.mo.


Далее указываем корневую папку, где у нас содержатся все переводы (.mo файлы для всех языков).

Как вы понимаете, доменов может быть несколько. Это необходимо, например, если ваше приложение состоит из нескольких самостоятельных частей. У каждой части моет быть свой языковой файл.

Теперь необходимо подключить (выбрать) заданный выше домен:

Все – наше приложение “выучило” язык, заданный вами в настройках!

И вот уже привычное echo _(‘Hellow world’); будет сиять на вашем экране как “Привет мир” или на любом другом языке мира!

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

Функции gettext

The xgettext program extracts translatable strings from given input files.

5.1.1 Input file location

‘ -f file ’ ‘ —files-from= file ’

Read the names of the input files from file instead of getting them from the command line.

‘ -D directory ’ ‘ —directory= directory ’

Add directory to the list of directories. Source files are searched relative to this list of directories. The resulting .po file will be written relative to the current directory, though.

If inputfile is ‘ — ’, standard input is read.

5.1.2 Output file location

Use name .po for output (instead of messages.po ).

‘ -o file ’ ‘ —output= file ’

Write output to specified file (instead of name .po or messages.po ).

‘ -p dir ’ ‘ —output-dir= dir ’

Output files will be placed in directory dir .

If the output file is ‘ — ’ or ‘ /dev/stdout ’, the output is written to standard output.

5.1.3 Choice of input file language

Specifies the language of the input files. The supported languages are C , C++ , ObjectiveC , PO , Shell , Python , Lisp , EmacsLisp , librep , Scheme , Smalltalk , Java , JavaProperties , C# , awk , YCP , Tcl , Perl , PHP , GCC-source , NXStringTable , RST , RSJ , Glade , Lua , JavaScript , Vala , GSettings , Desktop .

This is a shorthand for —language=C++ .

By default the language is guessed depending on the input file name extension.

5.1.4 Input file interpretation

Specifies the encoding of the input files. This option is needed only if some untranslated message strings or their corresponding comments contain non-ASCII characters. Note that Tcl and Glade input files are always assumed to be in UTF-8, regardless of this option.

By default the input files are assumed to be in ASCII.

5.1.5 Operation mode

Join messages with existing file.

‘ -x file ’ ‘ —exclude-file= file ’

Entries from file are not extracted. file should be a PO or POT file.

‘ -c[ tag ] ’ ‘ —add-comments[= tag ] ’

Place comment blocks starting with tag and preceding keyword lines in the output file. Without a tag , the option means to put all comment blocks preceding keyword lines in the output file.

Note that comment blocks supposed to be extracted must be adjacent to keyword lines. For example, in the following C source code:

The second comment line will not be extracted, because there is one blank line between the comment line and the keyword.

Perform a syntax check on msgid and msgid_plural. The supported checks are:


Prefer Unicode ellipsis character over ASCII .

Prohibit whitespace before an ellipsis character

Prefer Unicode quotation marks over ASCII «‘`

Prefer Unicode bullet character over ASCII * or —

The option has an effect on all input files. To enable or disable checks for a certain string, you can mark it with an xgettext: special comment in the source file. For example, if you specify the —check=space-ellipsis option, but want to suppress the check on a particular string, add the following comment:

The xgettext: comment can be followed by flags separated with a comma. The possible flags are of the form ‘ [no-] name -check ’, where name is the name of a valid syntax check. If a flag is prefixed by no- , the meaning is negated.

Some tests apply the checks to each sentence within the msgid, rather than the whole string. xgettext detects the end of sentence by performing a pattern match, which usually looks for a period followed by a certain number of spaces. The number is specified with the —sentence-end option.

The supported values are:

Expect at least one whitespace after a period

Expect at least two whitespaces after a period

5.1.6 Language specific options

Extract all strings.

This option has an effect with most languages, namely C, C++, ObjectiveC, Shell, Python, Lisp, EmacsLisp, librep, Java, C#, awk, Tcl, Perl, PHP, GCC-source, Glade, Lua, JavaScript, Vala, GSettings.

‘ -k[ keywordspec ] ’ ‘ —keyword[= keywordspec ] ’

Specify keywordspec as an additional keyword to be looked for. Without a keywordspec , the option means to not use default keywords.

If keywordspec is a C identifier id , xgettext looks for strings in the first argument of each call to the function or macro id . If keywordspec is of the form ‘ id : argnum ’, xgettext looks for strings in the argnum th argument of the call. If keywordspec is of the form ‘ id : argnum1 , argnum2 ’, xgettext looks for strings in the argnum1 st argument and in the argnum2 nd argument of the call, and treats them as singular/plural variants for a message with plural handling. Also, if keywordspec is of the form ‘ id : contextargnum c, argnum ’ or ‘ id : argnum , contextargnum c ’, xgettext treats strings in the contextargnum th argument as a context specifier. And, as a special-purpose support for GNOME, if keywordspec is of the form ‘ id : argnum g ’, xgettext recognizes the argnum th argument as a string with context, using the GNOME glib syntax ‘ «msgctxt|msgid» ’.
Furthermore, if keywordspec is of the form ‘ id :…, totalnumargs t ’, xgettext recognizes this argument specification only if the number of actual arguments is equal to totalnumargs . This is useful for disambiguating overloaded function calls in C++.
Finally, if keywordspec is of the form ‘ id : argnum . » xcomment » ’, xgettext , when extracting a message from the specified argument strings, adds an extracted comment xcomment to the message. Note that when used through a normal shell command line, the double-quotes around the xcomment need to be escaped.

This option has an effect with most languages, namely C, C++, ObjectiveC, Shell, Python, Lisp, EmacsLisp, librep, Java, C#, awk, Tcl, Perl, PHP, GCC-source, Glade, Lua, JavaScript, Vala, GSettings, Desktop.

The default keyword specifications, which are always looked for if not explicitly disabled, are language dependent. They are:

  • For C, C++, and GCC-source: gettext , dgettext:2 , dcgettext:2 , ngettext:1,2 , dngettext:2,3 , dcngettext:2,3 , gettext_noop , and pgettext:1c,2 , dpgettext:2c,3 , dcpgettext:2c,3 , npgettext:1c,2,3 , dnpgettext:2c,3,4 , dcnpgettext:2c,3,4 .
  • For Objective C: Like for C, and also NSLocalizedString , _ , NSLocalizedStaticString , __ .
  • For Shell scripts: gettext , ngettext:1,2 , eval_gettext , eval_ngettext:1,2 , eval_pgettext:1c,2 , eval_npgettext:1c,2,3 .
  • For Python: gettext , ugettext , dgettext:2 , ngettext:1,2 , ungettext:1,2 , dngettext:2,3 , _ .
  • For Lisp: gettext , ngettext:1,2 , gettext-noop .
  • For EmacsLisp: _ .
  • For librep: _ .
  • For Scheme: gettext , ngettext:1,2 , gettext-noop .
  • For Java: GettextResource.gettext:2 , GettextResource.ngettext:2,3 , GettextResource.pgettext:2c,3 , GettextResource.npgettext:2c,3,4 , gettext , ngettext:1,2 , pgettext:1c,2 , npgettext:1c,2,3 , getString .
  • For C#: GetString , GetPluralString:1,2 , GetParticularString:1c,2 , GetParticularPluralString:1c,2,3 .
  • For awk: dcgettext , dcngettext:1,2 .
  • For Tcl: ::msgcat::mc .
  • For Perl: gettext , %gettext , $gettext , dgettext:2 , dcgettext:2 , ngettext:1,2 , dngettext:2,3 , dcngettext:2,3 , gettext_noop .
  • For PHP: _ , gettext , dgettext:2 , dcgettext:2 , ngettext:1,2 , dngettext:2,3 , dcngettext:2,3 .
  • For Glade 1: label , title , text , format , copyright , comments , preview_text , tooltip .
  • For Lua: _ , gettext.gettext , gettext.dgettext:2 , gettext.dcgettext:2 , gettext.ngettext:1,2 , gettext.dngettext:2,3 , gettext.dcngettext:2,3 .
  • For JavaScript: _ , gettext , dgettext:2 , dcgettext:2 , ngettext:1,2 , dngettext:2,3 , pgettext:1c,2 , dpgettext:2c,3 .
  • For Vala: _ , Q_ , N_ , NC_ , dgettext:2 , dcgettext:2 , ngettext:1,2 , dngettext:2,3 , dpgettext:2c,3 , dpgettext2:2c,3 .
  • For Desktop: Name , GenericName , Comment , Icon , Keywords .

To disable the default keyword specifications, the option ‘ -k ’ or ‘ —keyword ’ or ‘ —keyword= ’, without a keywordspec , can be used.

‘ —flag= word : arg : flag ’

Specifies additional flags for strings occurring as part of the arg th argument of the function word . The possible flags are the possible format string indicators, such as ‘ c-format ’, and their negations, such as ‘ no-c-format ’, possibly prefixed with ‘ pass- ’.
The meaning of —flag= function : arg : lang -format is that in language lang , the specified function expects as arg th argument a format string. (For those of you familiar with GCC function attributes, —flag= function : arg :c-format is roughly equivalent to the declaration ‘ __attribute__ ((__format__ (__printf__, arg , . ))) ’ attached to function in a C source file.) For example, if you use the ‘ error ’ function from GNU libc, you can specify its behaviour through —flag=error:3:c-format . The effect of this specification is that xgettext will mark as format strings all gettext invocations that occur as arg th argument of function . This is useful when such strings contain no format string directives: together with the checks done by ‘ msgfmt -c ’ it will ensure that translators cannot accidentally use format string directives that would lead to a crash at runtime.
The meaning of —flag= function : arg :pass- lang -format is that in language lang , if the function call occurs in a position that must yield a format string, then its arg th argument must yield a format string of the same type as well. (If you know GCC function attributes, the —flag= function : arg :pass-c-format option is roughly equivalent to the declaration ‘ __attribute__ ((__format_arg__ ( arg ))) ’ attached to function in a C source file.) For example, if you use the ‘ _ ’ shortcut for the gettext function, you should use —flag=_:1:pass-c-format . The effect of this specification is that xgettext will propagate a format string requirement for a _(«string») call to its first argument, the literal «string» , and thus mark it as a format string. This is useful when such strings contain no format string directives: together with the checks done by ‘ msgfmt -c ’ it will ensure that translators cannot accidentally use format string directives that would lead to a crash at runtime.
This option has an effect with most languages, namely C, C++, ObjectiveC, Shell, Python, Lisp, EmacsLisp, librep, Scheme, Java, C#, awk, YCP, Tcl, Perl, PHP, GCC-source, Lua, JavaScript, Vala.

Understand ANSI C trigraphs for input.
This option has an effect only with the languages C, C++, ObjectiveC.

Recognize Qt format strings.
This option has an effect only with the language C++.

Recognize KDE 4 format strings.
This option has an effect only with the language C++.

Recognize Boost format strings.
This option has an effect only with the language C++.

Use the flags c-format and possible-c-format to show who was responsible for marking a message as a format string. The latter form is used if the xgettext program decided, the former form is used if the programmer prescribed it.

By default only the c-format form is used. The translator should not have to care about these details.

This implementation of xgettext is able to process a few awkward cases, like strings in preprocessor macros, ANSI concatenation of adjacent strings, and escaped end of lines for continued strings.

5.1.7 Output details

Specify whether or when to use colors and other text attributes. See The —color option for details.

Specify the CSS style rule file to use for —color . See The —style option for details.

Always write an output file even if no message is defined.

Write the .po file using indented style.

Do not write ‘ #: filename : line ’ lines. Note that using this option makes it harder for technically skilled translators to understand each message’s context.


‘ -n ’ ‘ —add-location= type ’

Generate ‘ #: filename : line ’ lines (default).

The optional type can be either ‘ full ’, ‘ file ’, or ‘ never ’. If it is not given or ‘ full ’, it generates the lines with both file name and line number. If it is ‘ file ’, the line number part is omitted. If it is ‘ never ’, it completely suppresses the lines (same as —no-location ).

Write out a strict Uniforum conforming PO file. Note that this Uniforum format should be avoided because it doesn’t support the GNU extensions.

Write out a Java ResourceBundle in Java .properties syntax. Note that this file format doesn’t support plural forms and silently drops obsolete messages.

Write out a NeXTstep/GNUstep localized resource file in .strings syntax. Note that this file format doesn’t support plural forms.

Use ITS rules defined in file . Note that this is only effective with XML files.

Write out comments recognized by itstool (http://itstool.org). Note that this is only effective with XML files.

‘ -w number ’ ‘ —w >number ’

Set the output page w >number .

Do not break long message lines. Message lines whose width exceeds the output page width will not be split into several lines. Only file reference lines which are wider than the output page width will be split.

Generate sorted output. Note that using this option makes it much harder for the translator to understand each message’s context.

Sort output by file location.

Don’t write header with ‘ msgid «» ’ entry.

This is useful for testing purposes because it eliminates a source of variance for generated .gmo files. With —omit-header , two invocations of xgettext on the same files with the same options at different times are guaranteed to produce the same results.

Note that using this option will lead to an error if the resulting file would not entirely be in ASCII.

Set the copyright holder in the output. string should be the copyright holder of the surrounding package. (Note that the msgstr strings, extracted from the package’s sources, belong to the copyright holder of the package.) Translators are expected to transfer or disclaim the copyright for their translations, so that package maintainers can distribute them without legal risk. If string is empty, the output files are marked as being in the public domain; in this case, the translators are expected to disclaim their copyright, again so that package maintainers can distribute them without legal risk.

The default value for string is the Free Software Foundation, Inc., simply because xgettext was first used in the GNU project.

Omit FSF copyright in output. This option is equivalent to ‘ —copyright-holder=» ’. It can be useful for packages outside the GNU project that want their translations to be in the public domain.

Set the package name in the header of the output.

Set the package version in the header of the output. This option has an effect only if the ‘ —package-name ’ option is also used.

Set the reporting address for msgid bugs. This is the email address or URL to which the translators shall report bugs in the untranslated strings:

  • — Strings which are not entire sentences; see the maintainer guidelines in Preparing Strings.
  • — Strings which use unclear terms or require additional context to be understood.
  • — Strings which make invalid assumptions about notation of date, time or money.
  • — Pluralisation problems.
  • — Incorrect English spelling.
  • — Incorrect formatting.
Илон Маск рекомендует:  Что такое код imap_utf7_encode

It can be your email address, or a mailing list address where translators can write to without being subscribed, or the URL of a web page through which the translators can contact you.

The default value is empty, which means that translators will be clueless! Don’t forget to specify this option.

‘ -m[ string ] ’ ‘ —msgstr-prefix[= string ] ’

Use string (or «» if not specified) as prefix for msgstr values.

‘ -M[ string ] ’ ‘ —msgstr-suffix[= string ] ’

Use string (or «» if not specified) as suffix for msgstr values.

Localization software

Локализация приложений с помощью gettext

Ни для кого не секрет, что использование латинского алфавита, а точнее – английского языка, де-факто является стандартом при разработке приложений. Установился ли такой уклад спонтанно или был обусловлен действием сторонних факторов – точно утверждать нельзя, но факт остаётся фактом: практически всегда при создании документации к ПО и элементов взаимодействия с пользователем (интерфейса) используется именно английский язык.
В то же время, наличие локализации и, что ещё важнее – качественной локализации, играет важнейшую роль при коммерческом использовании и/или популяризации ПО.

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

Насколько такой подход неэффективен, говорить не имеет смысла: дополнительные затраты времени, ресурсов, возникновение проблем технического характера (например, несоответствие кодировок символов), кроме того, с выходом новой версии ПО перевод придётся делать заново.

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

Локализация приложений с помощью GetText


Идея системы GetText возникла в рамках проекта GNU для интернационализации (GNU Translation Project), когда разработчики GNU столкнулись с проблемой локализации своих программ. Основой системы является библиотека gettext, которая поддерживается большинством языков программирования: C++, Objective-C, C#, сценарии sh и bash, Python, Perl, PHP, Java, GNU awk, Pascal (Free Pascal Compiler), YCP (язык YaST2), Tcl, Pike (поддержка языков программирования).

Данная библиотека обеспечивает вызов специальной функции gettext (для простых строк) или ngettext (для множественного числа), с помощью которой в исходном коде размечаются строки, подлежащие переводу. Обычно для уменьшения размера исходников и улучшения читаемости кода, для gettext объявляют и используют короткий синоним _ (символ подчёркивания) или __ (двойной символ подчёркивания), реже – символы _c или _e.
Таким образом, вызов

printf («Hello! My name is %s.\n», my_name);

printf(_(«My name is %s.\n»), my_name);

Также, разработчику необходимо установить в программе параметры локализации, к которым относятся: текущий язык и кодировка (локаль); путь к директории с файлами локализации; название файла с переводом (т.н. домен). Для этого, необходимо ориентироваться в двухбуквенных сочетаниях обозначения языков, языковых тэги и кодах, которые можно узнать из специальной таблицы или из документации по GetText.

Кроме библиотек в систему GetText входит набор специальных утилит для работы с размеченными в исходном коде строками. Обратите особое внимание: если вы работаете в ОС Unix (Linux), то дополнительной настройки GetText не требуется – все нужные утилиты и библиотеки уже интегрированы. Для Windows-систем необходимо установить скомпилированные под Win32 файлы библиотеки gettext, файлы iconv (библиотека для преобразования текста из одной кодировки в другую) и вспомогательные утилиты (всё указанные файлы можно взять здесь).

С помощью одной из таких утилит – xgettext – размеченные строки извлекаются из кода (скрипта). Для дополнительного функционала при вызове утилиты xgettext используются определённые параметры (об опциях xgettext можно почитать тут) – в данном примере дополнительно извлекаются комментарии отмеченные символами

Теперь .po-файл готов для передачи переводчикам, задачей которых станет заполнение пустых строк (в кавычках). После окончания перевода необходимо скомпилировать .po-файл, чтобы информация из него стала доступной для интерпретации программой – это обусловлено тем, что в силу особенностей технологии, программа не может работать непосредственно с .po-файлом. Компиляция осуществляется утилитой msgfmt, в результате работы которой появляется бинарный файл с расширением .mo. Важное замечание: редактировать .mo-файл нельзя, а все изменения вносятся в него через соответствующий .po-файл, с последующей его компиляцией.

Практическое использование gettext для перевода строковых ресурсов – редактор poEdit

Возможно, всё сказанное выше кажется достаточно сложным и запутанным. Это не удивительно, потому что до этого момента рассматривались теоретические основы, необходимые для понимания технологии в целом. Далее мы рассмотрим практические приёмы локализации, основанные на применении системы GetText.

Для этой цели воспользуемся бесплатным кросс-платформенным (достоверно проверено в среде Unix/Linux и Windows) редактором каталогов локализации для gettext – программой poEdit (скачать poEdit можно на официальном сайте). Пользователи Unix-систем также могут воспользоваться редакторами KBabel (KDE) или GTranslator (GNOME) – программами, которые по своим возможностям и принципам работы практически идентичны poEdit.

При первом запуске необходимо будет выбрать язык интерфейса – poEdit поддерживает большое количество языков интерфейса, в том числе и русский. Также редактор попросит ввести ваше имя и e-mail; остальные настройки оставляем без изменений, тем более, что их (включая язык интерфейса и личные данные) можно будет в дальнейшем изменить. Небольшое замечание: если в процессе работы вы планируете иметь дело только с одним видом исходных файлов (например, только *.php), то в Установках на вкладке Парсеры желательно оставить только нужный парсер исходного кода, а остальные удалить.

Запускаем программу и через меню Файл создаём новый каталог; в появившемся окне поочередно заполняем все три вкладки. На вкладке Пути задаём путь (пути), где находятся файлы проекта. В нашем случае, указаны точка и две точки – это означает, что файлы проекта и файлы локализации будут находиться в одной директории. На вкладке Ключевые слова задаём символы, указывающие строки, требующие перевода – какие именно это символы, известно из теории. В открывшемся окне выбираем ту же папку, где располагаются файлы проекта, и сохраняем .ро-файл согласно домену, который задал разработчик: обычно, для русской локализации это ru_RU.po или название_проекта-ru_RU.po.

Это и будет файл, содержащий в себе все сообщения, которые нуждаются в переводе. После сохранения появится окно Сводка об обновлении с перечнем всех текстовых строк, которые будут записаны в файл; во второй вкладке будут показаны те строки, которые удалены за ненадобностью из исходников. После нажатия «ОК», .po-файл будет обновлен. Заметьте: по умолчанию бинарный .mo-файл будет компилироваться автоматически при сохранении .po-файла (если данная опция не отключена в настройках). Основное окно редактора разделено на три части.

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

Если по каким-то причинам смысл текста не понятен и/или необходимо посмотреть исходный код, то это можно сделать во встроенном вьюере – правый клик мыши на строке, пункт Связи. Об одной из функций poEdit – автоматическом переводе – имеет смысл сказать отдельно. Суть функции заключается в том, что программа пытается автоматически переводить строки, если они близки к имеющимся записям в базе данных, содержащей набор ранее переведенных текстов, т.е., другими словами, мы имеем дело с памятью переводов (ПП).

Само собой, без такой базы данных функция автоматического перевода особой пользы не представляет, поэтому у пользователя есть возможность, кроме подключения уже имеющейся БД, создать собственную. Последний вариант выглядит особенно предпочтительно для людей, которые работают с шаблонными (однотипными) переводами или стандартизированными терминами – у них есть возможность создать базу «под себя» и экономить время, избавившись от рутинного перевода повторяющихся строк.

Если же использовать стороннюю БД или БД ориентированную на другую тематику, то применение автоматического перевода может и не дать ожидаемого результата – переведенные строки придётся корректировать и уточнять. В любом случае, строки, переведённые автоматически, poEdit помечает как «нечёткие» или «неточные» (от англ. «fuzzy»), т.е. требующие проверки. «Узким местом» реализации памяти переводов в poEdit является отсутствие поддержки наиболее распространенных форматов ПП, в том числе и международного стандарта TMX (Translation Memory Exchange Format).

Для генерации памяти переводов poEdit использует .ро и .mo-файлы, которые «заливаются» в базу, после чего их содержание становится доступным при автоматическом переводе. В настройках poEdit на вкладке Память переводов в строке «Пути к БД» необходимо указать рабочую папку перевода (обычно, директория программы), т.е. папку, где будет храниться созданная БД, и добавить язык, с которым вы собираетесь работать (если перевод будет осуществляться на русский язык, добавляем ru).

Далее, генерируем базу данных, указав .po-файл как источник. После выполненных действий poEdit будет откликаться на выбор Перевести автоматически, используя ПП из меню Каталог, а также задействует автоматический перевод при обновлении каталога (если данная опция не отключена в настройках ПП). После того, как файлы локализации готовы, их оставляют в корневой директории проекта или перемещают в отдельную «языковую» папку с названием lang или languages, в зависимости от того, как предусмотрел разработчик.
Несмотря на то, что для корректной работы локализации необходимы только .mo-файлы, .po-файлы обычно также оставляют, на случай, если в дальнейшем понадобится внести изменения в перевод.

Преимущества и недостатки инструмента локализации (интернационализации) приложений gettext

Не нужно думать, что система GetText является единственной технологией в своём роде. Другое дело, что наряду с другими подобными инструментами она имеет некоторые конкурентные преимущества. Основным отличием GetText от системы, например, catgets или технологии использования функции LoadString в среде MS Windows, является использование оригинальных строк (строк на английском языке) вместо специальных идентификаторов (обычно – числовых) в коде программы, а также поддержка множественного числа.
Кроме этого, в GetText есть ещё одна очень важная особенность: если какие-то строки не были по каким-то причинам переведены, то GetText вернет их на языке по умолчанию (обычно – английский), что очень удобно, так как не приводит к появлению ошибок. В то же время, при использовании GetText существует ряд трудностей на этапе подготовки программного продукта к локализации.

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

Несмотря на это, заслуга создателей технологии GetText состоит в том, что они предложили относительно несложный, достаточно функциональный и, что самое главное, унифицированный инструмент для локализации приложений. Возможно, именно поэтому система GetText на сегодняшний день является одной из самых популярных в сегменте веб-программирования, например, при локализации (часто – силами энтузиастов) бесплатных open-source проектов – шаблонов и «движков» для сайтов, блогов, Интернет-магазинов и т.п., а также дополнений к ним (плагинов, визуальных тем).

Если же говорить о главном инструменте для создания файлов локализации в среде ОС Windows – программе poEdit, то работа с ней не сложнее, по своей сути, работы с обычным текстовым редактором. Наибольшим же недостатком poEdit является, кончено, отсутствие полноценной поддержки памяти переводов.

Конечно, можно сформировать собственную БД на основе уже готовых .po и .mo-файлов, но для профессионального переводчика возможность использования общепринятых систем памяти переводов выглядит намного предпочтительнее.

gettext — конфликт имени функции PHP

У нас есть веб-сайт на основе PHP, который работает с 2005 года. Мы только что добавили нового разработчика. У нас каждый разработчик устанавливает локальный стек Apache для отладки. Когда он запускает сайт на своей рабочей станции, появляется сообщение об ошибке, связанное с конфликтом имен с одной функцией.

В частности, у нас есть функция GetText, которая принимает 5 параметров. В его системе он получает сообщение о том, что функция не может быть повторно объявлена. Это противоречит функции, которая называется gettext (обратите внимание на различие в заглавных буквах), которая, как говорят, принимает одну переменную.

Мы не получаем этот конфликт ни в одном из наших других случаев. Другие примеры включают наш производственный веб-сайт и три веб-сайта разработки. Все эти экземпляры работают в Unix FreeBSD. У нас есть разработчики, работающие под OS OS X и на разных машинах Windows. Рассматриваемый разработчик работает на Windows 7.

Мы не видим никакой подобной функции «gettext» в нашей базе кода, включая библиотеки Pear. В качестве временного решения мы переименовали нашу функцию в «XGetText». Это излечивает проблему.

Откуда этот конфликт?

Решение

Этот разработчик имеет расширение gettext активен в своей установке PHP, которая определяет функцию gettext , Капитализация не имеет значения для PHP. Ему либо придется деактивировать расширение в его php.ini, если это возможно, или перекомпилируйте PHP, чтобы исключить расширение gettext (в этом случае я бы предложил использовать виртуальную машину для установки пользовательской версии PHP).

Кстати, gettext — довольно популярное и часто используемое расширение, которое называет вашу пользовательскую функцию GetText плохой выбор

Другие решения

PHP имеет встроенный gettext функции (как в PHP 4, так и в PHP 5), а имена функций PHP не чувствительны к регистру. Предположительно, ваш PHP не скомпилирован с —with-gettext флаг и его есть.


Отключить Расширение Gettext , как я уверен, вы не собираетесь использовать его в своем проекте

Функции gettext

Кроме стандартного Си, поддерживаются также: C++, Objective-C, сценарии sh/bash, Python, Perl, PHP, GNU CLISP, Emacs Lisp, librep, GNU Smalltalk, Java, GNU awk, Паскаль, wxWidgets (с использованием класса wxLocale), YCP (язык YaST2), Tcl, Pike и R.

Использование в большинстве языков схоже с использованием в Си.

Интернационализация

Для программиста

Простые строки

Строки, которые необходимо перевести, размечаются в исходном коде вызовом функции gettext , ngettext или подобной. Обычно для уменьшения размера исходного кода и улучшения читаемости объявляют и используют короткий синоним функции gettext — _ (символ подчёркивания). Таким образом, вызов

Размеченные строки собираются в каталог с помощью программы xgettext . Например, для вышеприведённой строки в каталоге появится запись вроде этой:

Множественные числа

Для перевода множественного числа используется функция ngettext , которая принимает в качестве параметров две строки (для единственного и множественного числа соответственно) и целое число. В PHP вызов ngettext выглядит следующим образом:

Две строки необходимы для того, чтоб не делать отдельный перевод этой фразы на английский язык, т.к. большинство разрабатываемых приложений и так пишутся на английском. Функция ngettext сама по себе не производит подстановку числового значения вместо %d , поэтому программисту необходимо вызвать функцию printf или подобную ей для формирования нужной строки с числом.

Для переводчика

Простые строки

Переводчик создаёт на основе каталога .po -файл, содержащий перевод на конкретный язык. (Для этого можно использовать программу msginit .) Затем он переводит строки в этом файле, например, для русского перевода:

Для редактирования .po -файлов существует множество инструментов, к примеру:

Для перевода множественных чисел необходимо, чтобы в заголовке (там, где указываются такие данные, как Project-Id-Version и PO-Revision-Date ) .po -файла было указано правило формирования множественных чисел для данного языка. Например, в русском языке существует три формы множественных чисел:

  • 1, 21, 31. день
  • 2, 3, 4, 22, 23, 24, 32, 33, 34. дня
  • 0, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 25, 26, 27, 28, 29, 30, 35, 36. дней

Выбор одной из этих трёх форм в зависимости от числа осуществляется следующей формулой:

Эта формула имеет вид выражения на языке Си, в котором переменная n обозначает число.

После такого объявления формы приобретают номера 0, 1 и 2, и перевод фразы осуществляется следующим образом:

Для пользователя

Обычно пользователю в UNIX-подобных операционных системах не нужно предпринимать дополнительных шагов для выбора конкретного перевода. Перевод определяется системной переменной LANG , которая обычно уже установлена в требуемое значение.

Илон Маск рекомендует:  Скрипт прогресс бара загрузки файлов PHP + jQuery

Поддержка существующих переводов

Обновление переводов с использованием новых и изменившихся строк, появившихся в исходном коде, осуществляется программой msgmerge . При этом сохраняются все уже переведённые строки, а те, которые изменились, помечаются как неточные (англ. fuzzy ). По умолчанию, такие строки не будут использоваться программой. Они нужны для удобства переводчика: часто проще базироваться на существующем, пусть и устаревшем, переводе, чем переводить всю фразу заново.

См. также

Ссылки

В Википедии есть портал
«Свободное ПО»
  • Сайт gettext (англ.) . Проверено 23 ноября 2009.
  • Практическое применение gettext для локализации и интернационализации приложений (рус.) . Проверено 23 ноября 2009.

Wikimedia Foundation . 2010 .

Смотреть что такое «Gettext» в других словарях:


gettext — Developer(s) Various Stable release 0.18 (GNU gettext) / May 9, 2010 (GNU gettext) Operating system Cross platform Type Internationalization and localization … Wikipedia

Gettext — est la bibliothèque GNU d internationalisation (i18n). Elle est couramment utilisée pour écrire des programmes multilingues. Sommaire 1 Processus 1.1 Programmeur 1.1.1 Commentaires pour les traducteurs … Wikipédia en Français

Gettext — es la biblioteca GNU de internacionalización (i18n). Comúnmente se usa para escribir programas con interfaz en varios >Wikipedia Español

Gettext — es la libreria GNU de internacionalizacion (i18n). Es comunmente usada para escribir programas multilenguaje. La ultima version es la 0.14 … Enciclopedia Universal

Gettext — GNU gettext Entwickler: Das GNU gettext Team (Maintainer: Bruno Haible) Aktuelle Version: 0.17 (27. November 2006) Betriebssystem: Unix artige Betriebssysteme, Windows (s. Weblinks) … Deutsch Wikipedia

gettext — GNU gettext Тип локализация программного обеспечения Автор Ульрих Дреппер Разработчики сообщество Написана на C Интерфейс командная строка Операционная система Linux и др … Википедия

GNU gettext — gettext Développeur Projet GNU Dernière version 0.18.1 ( … Wikipédia en Français

GNU gettext — Infobox Software name = gettext developer = The GNU Project latest release version = 0.17 latest release date = November 11, 2007 operating system = Cross Platform genre = Development, Translation license = LGPL (library), GPL (tools), GFDL/GPL… … Wikipedia

GNU gettext — Entwickler Das GNU gettext Team (Maintainer: Bruno Haible) Aktuelle Version 0.18.1.1 (6. Juni 2010) Betriebssystem Unix artige Betriebssysteme, Windows (s. Weblinks) Kategorie … Deutsch Wikipedia

Пример использования методов GetFormat, GetText и SetText GetFormat, GetText, SetText methods example

В следующем примере используются методы GetText, gettext и SetText для передачи текста между объектом DataObject и буфером обмена. The following example uses the GetFormat, GetText, and SetText methods to transfer text between a DataObject and the Clipboard.

Пользователь вводит текст в текстовое поле , а затем может передать его в объект DataObject в стандартном текстовом формате, нажав кнопку CommandButton1. The user types text into a TextBox and then can transfer it to a DataObject in a standard text format by clicking CommandButton1.

Нажатие CommandButton2 получает текст из DataObject. Clicking CommandButton2 retrieves the text from the DataObject.

Нажатие CommandButton3 копирует текст из TextBox1 в DataObject в настраиваемом формате. Clicking CommandButton3 copies text from TextBox1 to the DataObject in a custom format.

Нажатие CommandButton4 копирует текст из DataObject в настраиваемом формате. Clicking CommandButton4 retrieves the text from the DataObject in a custom format.

Чтобы воспользоваться этим примером, скопируйте данный пример кода в раздел описаний формы. To use this example, copy this sample code to the Declarations portion of a form. Убедитесь, что эта форма содержит: Make sure that the form contains:

  • Элемент TextBox с именем TextBox1. A TextBox named TextBox1.
  • Четыре элемента управления CommandButton с именами от CommandButton1 до CommandButton4. Four CommandButton controls named CommandButton1 through CommandButton4.
  • Метка под названием Label1. A Label named Label1.

Поддержка и обратная связь Support and feedback

Есть вопросы или отзывы, касающиеся Office VBA или этой статьи? Have questions or feedback about Office VBA or this documentation? Руководство по другим способам получения поддержки и отправки отзывов см. в статье Поддержка Office VBA и обратная связь. Please see Office VBA support and feedback for guidance about the ways you can receive support and provide feedback.

dsent.me

«Смотритель» Пелевина мне понравился.

Основная мысль книги не станет откровением ни для кого из тех, кто читал хоть один его роман, начиная с «Чапаева». С 1996 года автор подбирает всё новые и новые аналогии для демонстрации всё той же идеи; в этом смысле «Смотритель» ничем не примечателен. По крайней мере, ему далеко до того изящества, с которым тема раскрыта в „t“ (с моей точки зрения — лучшее, что на сегодня написано Пелевиным).

«Смотритель» хорош по другим причинам. Во‑первых, в нём практически нет традиционного авторского обыгрывания текущих политических событий. Это, конечно, всё забавно, но ведь лет через десять никто и помнить не будет, о чём была речь.

Во‑вторых, от чтения остаётся ощущение лёгкости. Нет впечатления, что проглотил концентрат пары сезонов российского постперестроечного телесериала про бандитов и ментов, в отличие от многих других его произведений (Generation «П», ДПП (НН) и далее со всеми остановками вплоть до Бэтман‑Аполло).

В‑третьих, мне понравилось, как здесь написано о счастье и любви. Пелевин вовсе не уходит от констатации биохимической предопределённости и эволюционной обусловленности всего того, что мы считаем тончайшими движениями нашей души, но говорит он об этом не с едким сарказмом прожжённого циника, которым пропитан, например, S.N.U.F.F., а с пониманием и лёгкой грустью. Не пытаясь вызвать в читателе чувство горечи в связи с осознанием себя как мясной машины, автор, мне думается, делает своё высказывание только сильнее.

В‑четвёртых, приятные детали. Хад и Цоф, некрозаклинания инженеров Ветхой Земли, безблагодатность и так далее. Чего у Пелевина не отнять, так это умения подмечать элементы повседневности и обращать на них внимание, подавая в неожиданном ракурсе. Не подкачал.

Героиня книги, журя главного героя за нечаянный акт творения, формулирует «вторую бритву Оккама»: не следует создавать новые сущности без любви. Думаю, что при написании «Смотрителя» автор в полной мере прислушался к рекомендации собственного персонажа.

  • Автор рецензии — Данила Сентябов. По вопросам использования текста за пределами сайта dsent.me пишите сюда: use@dsent.me.
  • Изображение обложки рецензируемой книги не принадлежат автору рецензии и использовано исключительно c информационными целями в соответствии со ст. 1274 Гражданского кодекса РФ и нормами добросовестного использования (fair use).

Чуждый Бог

Эта публикация — часть серии «Эволюция» на сайте dsent.me

Глядя на природу, человек всюду видит предназначение. Заячьи лапы сконструированы для бега. Лисьи челюсти идеально подходят для разрывания добычи. Увы, наше зрение нас здесь подводит: мы видим не то, что есть на самом деле.

Как можно использовать gettext, чтобы помочь мне здесь?

Я пытаюсь создать способ разрешить членам переводить строки на другие языки. Здесь вы можете увидеть пример: ИСПЫТАНИЕ ПЕРЕВОДОВ

Кто-то рекомендовал, чтобы я использовал собственную функцию gettext () php для этого, вместо того, что я уже использую для загрузки языковых файлов, что и есть:


Строки содержатся в файле, который называется так: ManageDPModules.english.php DreamPortal.english.php и т. Д.

Эти файлы могут выглядеть следующим образом: при открытии в любом php-редакторе и могут иметь много из этих переменных $ txt:

Для сохранения переводов я использую следующую функцию:

Я не вижу, как gettext поможет. Невозможно обновить текстовый каталог без перезагрузки сервера каждый раз. Может быть, если кто-то может создать демо для меня?

Кроме того, хотелось бы, чтобы он поддерживал UTF-8. Данные должны быть согласованными.

Итак, что не так с этой реализацией? Зачем использовать gettext? Как его можно использовать для улучшения перевода для работы как с языковыми строками UTF-8, так и с языком UTF-8, чтобы он мог быть переведен.

EDIT: Обратите внимание, что файлы в конечном итоге должны быть переименованы в: ManageDPModules.[language].php , DreamPortal.[language].php и т. Д. И т. Д., Чтобы переводы работали. Итак, как каталоги помогут мне в этом отношении? Если вы хотите увидеть возможные END-RESULT Translations, вы можете скачать языковой пакет, расположенный здесь, и открыть языковые файлы .german.php, чтобы посмотреть, как он будет выглядеть после того, как участник отправит язык в файл по файлу. Отмечено, что некоторые из этих пакетов имеют строки UTF-8, а некоторые нет. Имя файла пакета сообщит вам об этом. Было бы неплохо, если бы я мог также поддержать его UTF-8, но это не является обязательным требованием. Обратите внимание: я не собираюсь создавать полные пакеты здесь. Я просто хочу создать языковой файл. [Language] .php со всеми переведенными строками внутри них (что мой код уже делает).

Хорошо, я предоставил ENTIRE файл index.php для этого, чтобы вы могли видеть, что именно он делает, когда выполняете переводы. Вот файл index.php для этого, и вам понадобятся некоторые файлы на английском языке: DreamPortal.english.php , ManageDPModules.english.php и DreamHelp.english-utf8.php . Теперь, чтобы увидеть это, вам нужно загрузить на сервер, index.php, создать несколько папок, где указан index.php, вызвать 1 английский и создать там папку для каждого дополнительного языка (я сделал 2 папки, испанский и французский), чем загрузить 3 языковых файла в английскую папку. Запустите index.php в своем браузере, и вы увидите, что он работает.

Теперь, как я мог использовать gettext для каталогов с этим SAME. Мне нужно включить онлайн-перевод файлов. Мне нужно создать PHP-файлы переводов в стиле SAME, которые имеют файлы .english.php с тем же PREFIX, что и раньше .english.php , и мне нужно изменить язык в имени файла на тот же язык, определенный для имя папки. Онлайн-переводы – это единственный способ. Необходимость переводчика ТОЛЬКО для перевода строк. Они не должны сосредотачиваться на установке программ, их упаковке, переименовании файлов и т. Д. И т. Д. Это делает этот процесс настолько безболезненным, насколько это возможно, позволяя делать это онлайн. И я знаю, что есть способ сделать это и даже для поддержки UTF-8. Но я использую лучший метод, который я знаю как на данный момент. Но многие из вас МНОГО умнее в этом, чем я, поэтому я прошу помощи у вас, ребята.

Есть ли кто-нибудь, кто может показать мне лучший способ? Пример, подобный тому, который я дал вам в этом вопросе?

Мне нужно, чтобы переводы выполнялись ONLINE от переводчиков, а также хотели бы, чтобы он поддерживал файлы UTF-8, а также файлы без UTF-8. Мне нравится, как у меня есть настройка для ссылки, приведенной выше ( TRANSLATIONS TEST ), чтобы переводчик мог просто выполнять переводы онлайн и не беспокоиться ни о чем другом, и он автоматически создавал нужные файлы. Который будет совпадать с английским именем файла языка с именем папки (представляющим язык) после первого . (точка), и он должен иметь расширение .php (как в коде, который я использую в настоящее время). Поэтому в основном мне нужна адаптация текущего index.php для поддержки UTF-8 и не UTF-8 для всех или большинства языков, и ему сказали, что с помощью gettext () и файлов каталога это поможет.

Ищете модифицированную версию моего текущего index.php для использования gettext () таким образом, чтобы он поддерживал большинство, если не все, языков и переводов. REGEX, который я получил для preg_replace, не является полностью удовлетворительным, потому что он, кажется, помещает переднюю косую перед двойными кавычками при сохранении / отправке переводов. Поэтому, возможно, также потребуется улучшение на preg_replace.

Я представил полный пример с ACTUAL CODE bytheway. Я бы хотел, чтобы кто-то изменил этот пример, с КОДОМ, который я предоставил вместо USE GETTEXT, и поддерживаю UTF-8. Или на самом деле предоставить АКТУАЛЬНЫЙ МЕТОД, чтобы я сделал это сам. Не ищите кучу ссылок, которые я могу найти самостоятельно!

Когда вам рекомендуется использовать gettext, на самом деле рекомендуется использовать gettext- like систему перевода. Ваш текущий код сложный из-за мнемонических текстовых указаний. И проблема, с которой вы столкнулись с регулярными выражениями для редактирования, вызвана путаницей переменных. Позвольте мне предложить альтернативный код для переходных целей.

Красота gettext заключается в использовании ненавязчивого API. Вызов функции _() достаточно прост, чтобы полностью использоваться без добавления синтаксиса или раздувания кода. Он предпочитает такие вещи, как getTextTrans(‘ABBR_TXT_ID’) . Использование таких мнемонических текстовых идентификаторов является широко распространенной ошибкой; потому что на практике не часто повторяются слова и _(«Raw english original text.») . Однако, поскольку у вас уже есть мнемонические ключи, держите их, если это слишком много для изменения. Это всего лишь рекомендация.

Реальная проблема заключается в использовании встроенных выражений PHP для создания строк перевода. Именно поэтому регулярные выражения для вашего редактора переводов стали непрозрачными. Поэтому я настоятельно рекомендую использовать статические строки и предоставить заполнители. Функция перевода должна быть поручена с ее обработкой. (Не беспокойтесь о микрооптимизации здесь!) – Я бы использовал, например, <$url_xy>заполнители стиля PHP / Smarty:

И функция перевода, которая ищет глобальную таблицу-заполнитель или параметры ($ context) для замены:

Оптимизируемое. Но таким образом вы можете использовать статический мнемонический-> текстовый или английский-> текстовый набор трансляционных массивов. Вы используете только статические строки в текстовом редакторе-редакторе. Эти статические строки отображаются как-есть, и ваши переводчики редактируют текст на английском языке, но не в <$placeholders>.

Следовательно, ваш код для функции перевода не будет нуждаться в каких-либо сложных регулярных выражениях (в этом случае они не являются полезными) для сопоставления строк и встроенных переменных PHP. Фактически гораздо более простая комбинация include() и var_export() теперь может занять свое место:

Обработка файлов и многое другое нужно настраивать, конечно. Но все же это более простой подход.

И это также позволит вам перейти к одному из вариантов gettext как backend. Сохраните свою пользовательскую функцию-обертку __() и используйте, например, Zend_Translate в качестве backend. Это позволяет вам использовать файлы перевода .php $ txt = array () (или, я думаю, так), или перейти к файлам .mo / .po gettext-style. Преимущество этого заключается в том, что есть богатая поддержка инструмента в отличие от доморощенных решений.

В любом случае, это то, как вы используете материал в своем основном приложении:

Вначале было бы желательно перейти от клавиш short_txt к англо-английским> чужеродным текстам, но теоретически любой из бэкэндов из ответа dvbs будет применим. Теперь вы уже сказали, что родной gettext не является для вас вариантом (для PHP, не относящихся к fastcgi, сопротивление памяти является недостатком). Но PHP-возможности для встроенных функций INTL могут вам помочь. В частности, http://www.php.net/manual/en/class.messageformatter.php может быть более полезной, чем простая оболочка замены <$ var>, которую я вам дал. Но я никогда не использовал его, и я думаю, что Zend_Translate, скорее всего, более полезен. В частности, любой из этих бэкендов дает вам независимость от набора символов. Лично я бы просто придерживался UTF-8, несмотря ни на что. Но, например, файлы gettext .mo / .po могут иметь свою собственную кодировку.

Зачем изобретать колесо? Может быть, я не понимаю, но я уверен, что то, что вы пытаетесь сделать, было сделано раньше.

Просто используйте одно из многих существующих решений.

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

Вот о чем подумать, когда принимаете решения:

  • Язык, который использует проект
  • Возможность расширения, добавления функций и настройки в соответствии с вашими потребностями
  • Это услуга? или с открытым исходным кодом, который вы можете загрузить и использовать на своем собственном сервере
  • Поддерживает ли он перевод множественных чисел?
  • Сообщество и ресурсы, доступные для этого проекта
  • Имеет ли он также веб-интерфейс, как вы просили?

Вот некоторые (случайным образом упорядоченные):

  • entrans
  • Pootle
  • glotpress
  • Розеттский
  • globalsight
  • tcktranslator
  • kartouche
  • subtitrans
  • tmsphp
  • i18nedit
  • Открытый механизм перевода
  • Переводчик GNU GetText
  • SiteTranslator
  • phptrans
  • Строка myGengo
  • NetBabel
  • translatewiki

Обновление: спасибо, Эль-Йобо. Я отметил это как вики сообщества, любой может отредактировать или ответить другим проектам, если найдет что-то еще.

XXXV. Функции Gettext

Функции gettext реализуют NLS (Native Language Support) API, который может использоваться для интернационализации ваших PHP-приложений. Просмотрите документацию о gettext для вашей системы по адресу http://www.gnu.org/manual/gettext/index.html.

Для использования этих функций вы обязаны загрузить и установить пакет GNU gettext с http://www.gnu.org/software/gettext/gettext.html

Чтобы включить поддержку GNU gettext в ваше построение PHP, вы обязаны добавить опцию
—with-gettext[=DIR] , где DIR это директория установки gettext, по умолчанию это /usr/local.

Это расширение не определяет никаких директив конфигурации.

Это расширение не определяет никакие типы ресурсов.

Это расширение не определяет никаких констант.

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL