
        *****************************************************
        *           GENERATED FILE, DO NOT EDIT             *
        * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION *
        *****************************************************

This file was generated by po4a(7). Do not store it (in VCS, for example),
but store the PO file used as source file by po4a-translate.

In fact, consider this as a binary, and the PO file as a regular .c file:
If the PO get lost, keeping this translation up-to-date will be harder.

=encoding UTF-8

=head1 НАЗВАНИЕ

po4a - платформа для перевода документации и других материалов

=head1 Введение

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

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

=head1 Почему именно po4a?

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

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

К счастью, у ПО с открытым исходным кодом достаточно хорошие переводы,
которые удобно поддерживать благодаря инструментам из пакета gettext. Они
извлекают строки для перевода из программ, и предоставляют их переводчикам в
единообразном формате (называемом PO-файлы, или translation catalogs,
каталоги переводов).Целая экосистема различных инструментов выросла вокруг
оных, дабы помочь переводчикам собственно переводить эти PO-файлы. Результат
их работы затем используется библиотекой gettext во время исполнения
программы, чтобы отображать переведённые сообщения пользователю.

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

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

B<Цель проекта po4a - облегчить работу переводчиков документации>.  В
частности, он делает переводы документации I<поддерживаемыми>.

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

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

Полный список достоинств и недостатков этого подхода перечислен в разделе
«B<Часто задаваемые вопросы>» ниже в этом документе.

=head2 Поддерживаемые форматы

На данный момент этот подход был успешно воплощён для нескольких форматов:

=over

=item man (зрелый парсер)

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

Модуль L<Locale::Po4a::Man(3pm)|Man> также поддерживает формат mdoc,
используемый в BSD man pages (они также довольно распространены в Linux).

=item AsciiDoc (зрелый парсер)

Этот формат представляет собой легкий формат разметки, предназначенный для
облегчения составления документации. Например, он используется для
документирования системы git. Эти manpages переведены с помощью po4a.

Подробнее см. в разделе L<Locale::Po4a::AsciiDoc>.

=item pod (зрелый парсер)

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

Подробнее см. в разделе L<Locale::Po4a::Pod>.

=item sgml (зрелый парсер)

Даже если он и заменён XML в наши дни, этот формат всё ещё используется в
тех документах, что длиннее нескольких экранов. Он может даже использоваться
для целых книг. Обновление переводов таких длинных документов может быть
настоящим вызовом. В частности, B<diff> зачастую показывает себя абсолютно
бесполезным, когда в исходном тексте изменяются отступы после обновления. К
счастью, po4a может с этим помочь.

На данный момент поддерживаются только DebianDoc и DocBook DTD, но добавлять
поддержку новых DTD достаточно просто. Возможно даже использование po4a для
перевода неизвестного SGML DTD, вообще не вмешиваясь в исходный код;
достаточно только предоставить всю необходимую информацию в командной
строке. См. подробности в L<Locale::Po4a::Sgml(3pm)>.

=item TeX / LaTeX (зрелый парсер)

Формат LaTeX — это основной формат публикаций, используемый в мире
Свободного ПО.

Модуль L<Locale::Po4a::LaTeX(3pm)|LaTeX> был проверен на документации
Python, одной книге и нескольких презентациях.

=item text (зрелый парсер)

Формат Text является базовым для многих форматов, включающих длинные блоки
текста, включая Markdown, fortunes, YAML-загаловки (Front Matter),
debian/changelog и debian/control.

Поддерживает общий формат, используемый в генераторах статических сайтов,
README и других системах документации. Подробности смотрите в разделе
L<Locale::Po4a::Text(3pm)|Text>.

=item xml and XHMTL (похоже, зрелый парсер)

Формат XML является базовым для многих форматов документации.

На данный момент, po4a поддерживает DocBook DTD
(cм. L<Locale::Po4a::Docbook(3pm)>) и XHTML.

=item BibTex (похоже, зрелый парсер)

Формат BibTex используется наряду с LaTex для форматирования списков ссылок
(библиографий).

Подробнее см. в разделе L<Locale::Po4a::BibTex>.

=item Docbook (похоже, зрелый парсер)

Язык разметки на основе XML, использующий семантические теги для описания
документов.

Более подробную информацию см. в L<Locale::Po4a:Docbook>.

=item Guide XML (похоже, зрелый парсер)

Формат документации XML. Этот модуль был разработан специально для помощи в
поддержке и сопровождении переводов документации Gentoo Linux по крайней
мере до марта 2016 года (по данным Wayback Machine). С тех пор Gentoo
перешла на XML-формат DevBook.

Более подробную информацию смотрите в L<Locale::Po4a:Guide>.

=item Wml (похоже, зрелый парсер)

Язык веб-разметки, не путайте WML с WAP, используемым в мобильных
телефонах.  Этот модуль основан на модуле Xhtml, который сам основан на
модуле XmL.

Более подробную информацию смотрите в разделе L<Locale::Po4a::Wml>.

=item Yaml (похоже, зрелый парсер)

Строгий суперсет JSON. YAML часто используется в качестве системных или
конфигурационных проектов.  YAML лежит в основе программы Ansible компании
Red Hat.

Более подробную информацию см. в разделе L<Locale::Po4a::Yaml>.

=item RubyDoc (похоже, зрелый парсер)

Формат Ruby Document (RD), первоначально формат документации по умолчанию
для Ruby и Ruby-проектов до преобразования в RDoc в 2002 году. Хотя,
по-видимому, японская версия справочного руководства по Ruby все еще
использует RD.

Более подробную информацию см. в разделе L<Locale::Po4a::RubyDoc>.

=item Halibut (похоже, экспериментальный парсер)

Система создания документации, с элементами, похожими на TeX,
debiandoc-sgml, TeXinfo и другие, разработанная Саймоном Тэтхемом,
разработчиком PuTTY.

Более подробную информацию см. в разделе L<Locale::Po4a:Halibut>.

=item Ini (похоже, экспериментальный парсер)

Формат файла конфигурации, популярный в MS-DOS.

Более подробную информацию смотрите в разделе L<Locale::Po4a::Ini>.

=item texinfo (крайне экспериментальный парсер)

Вся документация GNU написана в этом формате (вообще говоря, это одно из
необходимых условий, чтобы стать официальным проектом GNU). Поддержка
L<Locale::Po4a::Texinfo(3pm)|Texinfo> в po4a пока в зачаточном
состоянии. Пожалуйста сообщайте об ошибках и запрашивайте новые возможности,
когда требуется.

=item gemtext (крайне экспериментальный парсер)

Собственный текстовый формат документации протокола Gemini. Обычно он
использует расширение C<.gmi>. Поддержка этого формата в po4a пока находится
в зачаточном состоянии. Если у вас возникнут какие-либо проблемы, то не
стесняйтесь создавать новые сообщения об ошибках или запросы на добавление
функций.

=item org (крайне экспериментальный парсер)

Формат, используемый в Org-mode. Поддержка этого формата в po4a пока
находится в зачаточном состоянии. Если у вас возникнут какие-либо проблемы,
то не стесняйтесь создавать новые сообщения об ошибках или запросы на
добавление функций.

=item vimhelp (крайне экспериментальный парсер)

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

=item simplepod (крайне экспериментальный парсер)

Аналогичен ранее упомянутому I<pod>, но этот модуль использует новый парсер
L<Pod::Simple>. Поскольку он был создан не так давно, на данный момент
возможны некоторые ошибки. Если вы заметите какое-либо странное поведение,
пожалуйста, сообщите нам. В конечном итоге этот модуль заменит I<pod>.

=item Другие поддерживаемые форматы

Po4a также может обрабатывать некоторые более редкие или специализированные
форматы, такие как документация опций компиляции для ядер Linux 2.4+
(L<Locale::Po4a::KernelHelp>) или диаграммы, создаваемые инструментом dia
(L<Locale::Po4a::Dia>). Добавление нового формата часто очень просто, и
главная задача состоит в том, чтобы придумать парсер для вашего целевого
формата. Подробнее об этом см. в L<Locale::Po4a::TransTractor(3pm)>.

=item Не поддерживаемые форматы

К сожалению, в po4a всё ещё нет поддержки нескольких форматов
документации. Поддержку многих из них было бы не так сложно добавить. И это
включает не только форматы документации, но и, например, описание пакетов
(deb и rpm), вопросы, задаваемые интерактивными сценариями установки
пакетов, файлы changelogs для пакетов, и все специализированные форматы
файлов, которые используются в программах, такие как сценарии игр или файлы
ресурсов wine.

=back

=head1 Использование po4a

Самый простой способ использовать данный инструментарий в вашем проекте —
создать файл настроек для утилиты B<po4a> и в дальнейшем взаимодействовать
только с ней. См. подробности в документации L<po4a(1)>. Остальная часть
данного раздела посвящена более подробному описанию работы po4a для
продвинутых пользователей, жаждущих углубить своё понимание.

=head2 Подробная схема рабочего процесса, основанного на po4a

Прежде чем приступить к данному, излишне подробному, разделу, обязательно
прочтите L<po4a(1)>, дабы получить общее представление о рабочем процессе,
которому следует po4a. Возвращайтесь сюда, когда захотите получить
всеобъемлющую страшную картину, которая будет включать практически все
детали.

На следующей схеме F<master.doc> - это документ, подлежащий переводу;
F<XX.doc> - это тот же документ, но переведённый на язык XX, а F<doc.XX.po>
- это каталог переводов для этого документа на язык XX. Авторы документации
в основном будут иметь дело с F<master.doc> (который может быть
man-страницей, XML-документом, файлом AsciiDoc и т.п.); переводчики в
основном будут иметь дело с PO-файлом, а конечные пользователи будут видеть
только файл F<XX.doc>.

Переходы с пометками в квадратных скобках, например C<[po4a updates po]>,
представляют собой запуск инструментов po4a, а переходы с фигурными
скобками, например C<{обновление master.doc}> — ручное изменение файлов
проекта.

                                   мастер.doc
                                       |
                                       V
      +<----<----+<-----<-----<--------+------->-------->--------+
      :          |                     |                         :
  {перевод}      |           {обновление мастер.doc}             :
      :          |                     |                         :
    XX.doc       |                     V                         V
(необязательно)  |                 мастер.doc ->-------->------->+
      :          |                  (новый)                      |
      V          V                     |                         |
   [po4a-gettextize]  doc.XX.po -->+   |                         |
          |           (старый)     |   |                         |
          |              ^         V   V                         |
          |              |   [po4a обновляет po]                 |
          V              |           |                           V
     перевод.pot         ^           V                           |
          |              |        doc.XX.po                      |
          |              |       (неточный)                      |
      {перевод}          |           |                           |
          |              ^           V                           V
          |              | {ручное редактирование}               |
          |              |           |                           |
          V              |           V                           V
      doc.XX.po --->---->+<---<-- doc.XX.po     аддендум      мастер.doc
     (начальный)                (актуальный) (необязательно) (актуальный)
          :                          |             |             |
          :                          V             |             |
          +----->----->----->------> +             |             |
                                     |             |             |
                                     V             V             V
                                     +------>------+-----<-------+
                                                   |
                                                   V
                                       [po4a обновляет переводы]
                                                   |
                                                   V
                                                 XX.doc
                                              (актуальный)

Опять же, эта схема несколько переусложнена. Для упрощенного обзора
см. L<po4a(1)>.

В левой части показано, как L<po4a-gettextize(1)> можно использовать для
преобразования существующего проекта перевода в инфраструктуру po4a. Этот
скрипт берет оригинальный документ и его переведенный аналог и пытается
построить соответствующий PO-файл. Такое ручное преобразование довольно
громоздко (подробнее см. документацию L<po4a-gettextize(1)>), но оно
необходимо только один раз для преобразования существующих переводов. Если у
вас нет переводов для преобразования, вы можете забыть об этом и
сосредоточиться на нужной части схемы.

В верху правой части, изображены действия автора оригинала — обновление
документации. В середине правой части показываются автоматические действия
по обновлению перевода. Новые материалы извлекаются и сравниваются с
существующим переводом. Для тех частей, которые не были изменены
используется уже существующий перевод, а те части, которые были изменены
частично соединяются с уже существующим переводом, но с пометкой «неточно»
(fuzzy), указывающей, что перевод должен быть обновлён. Новые или сильно
изменённые части оказываются непереведёнными.

Затем, в разделе I<ручное редактирование> описываются действия переводчиков,
которые изменяют файлы PO, чтобы обеспечить перевод каждой оригинальной
строки и абзаца. Это может быть сделано с помощью специального редактора,
такого как B<GNOME Translation Editor>, KDE's B<Lokalize> или B<poedit>, или
с помощью онлайн-платформы локализации, такой как B<weblate> или
B<pootle>. Результатом перевода является набор PO-файлов, по одному на
каждый язык. Более подробную информацию см. в документации gettext.

В нижней части схемы показано, как B<po4a> создаёт переведённый документ из
исходного документа F<master.doc> и каталога переводов F<doc.XX.po>, который
был обновлён переводчиками. Из исходного документа берётся его структура, а
изначальное содержание заменяется его переведенной версией. Чтобы добавить к
переводу некий дополнительный текст, при необходимости можно также
использовать аддендумы (addendum). Обычно, они применяются для добавления,
например, имени переводчика в окончательный документ. Подробности см. ниже.

При запуске B<po4a> автоматически обновляет и файлы перевода, и файлы с
переведённой документацией.

=head2 Начало нового проекта перевода

Если вы начинаете с нуля, то вам нужно только создать файл настроек po4a, и
на этом всё будет готово. Для файлов, которых нет, будут созданы необходимые
шаблоны, которые позволят участникам вашего проекта переводить его на свои
языки. Краткое руководство по началу работы и прочие подробности см. в
L<po4a(1)>.

Если у вас уже есть какой-либо перевод, т.е. файл документации, который был
переведён вручную, то вы можете извлечь из него перевод и встроить его в
рабочий процесс, основанный на po4a с помощью B<po4a-gettextize>. Этот
процесс может быть несколько неуклюжим (как описано на man-странице
утилиты), но как только ваш проект будет преобразован, всё будет обновляться
автоматически.

=head2 Обновление переводов и документов

После первоначальной настройки, простой запуск B<po4a> будет выполнять и
обновление PO-файлов и переведённой документации. Вы можете передать B<po4a>
параметр C<--no-translations>, чтобы не обновлять переводы (т.е. обновлять
только PO-файлы) или параметр C<--no-update>, чтобы не обновлять PO-файлы
(т.е. обновлять только переводы). Эти действия примерно соответствует тому,
что делали специализированные сценарии B<po4a-updatepo> и B<po4a-translate>,
которые сейчас признаны устаревшими (см. «Почему специализированные сценарии
признаны устаревшими?» в разделе «Часто задаваемые вопросы» ниже).

=head2 Использование аддендумов (addendum) для добавления дополнительного текста к
переводам

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

В po4a для этого необходимо задать B<addendum>-файлы, которые на
концептуальном уровне можно считать некими «патчами», накладываемыми на
локализованный документ после его обработки. Каждый аддендум представляет из
себя отдельный файла, формат которого, однако, сильно отличается от
классических патчей. Первая строка — это I<строка заголовка>, определяющая
точку вставки аддендума (с, к сожалению, загадочным синтаксисом - см. ниже),
в то время как остальная часть файла добавляется дословно в определенную
позицию.

Строка заголовка должна начинаться со строки B<PO4A-HEADER:>, за которой
следует список полей I<key>B<=>I<value>, разделенных запятыми.

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

 PO4A-HEADER: mode=eof

Если вы хотите добавить своё дополнительное содержимое в середину документа,
то всё становится сложнее. Так, следующий заголовок указывает, что аддендум
должен быть вставлен после XML-раздела (ограниченного тегом
C<E<lt>sectionE<gt>>), содержащего строку C<Об этом документе> (в переводе).

 PO4A-HEADER: position=Об этом документе; mode=after; endboundary=</section>

С практической точки зрения, при применении аддендума po4a ищет первую
строку, соответствующую аргументу C<position> (он является регулярным
выражением). Не забывайте, что в данном случае po4a работает с уже
B<переведённым> документом. Например, если вы хотите, добавить аддендум к
французскому переводу документа, то строка может выглядеть следующим
образом:

 PO4A-HEADER: position=À propos de ce document; mode=after; endboundary=</section>

После того как C<position> будет найдена в целевом документе, po4a будет
искать среди строк следующих после C<position> строку, которая соответствует
указанному C<endboundary> (также регулярное выражение). Аддендум будет
добавлен сразу B<после> этой строки (поскольку мы указали I<endboundary>, то
есть границу, заканчивающую текущий раздел).

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

 PO4A-HEADER: position=Об этом документе; mode=after; beginboundary=<section>

Здесь po4a ищет первую строку, которая будет сопоставлена C<< <section> >>
после строки, сопоставленной C<Об этом документе> в переводе, и вставляет
аддендум B<перед> этой строке, поскольку мы указали I<beginboundary>, то
есть границу, обозначающую начало следующего раздела. Таким образом, этот
заголовок указывает po4a, что аддендум должен быть вставлен после раздела,
содержащего C<Об этом документе>, и задаёт, что раздел начинается со строки,
содержащей тег C<< <section> >>. Это эквивалентно предыдущему примеру,
поскольку на самом деле вам нужно добавить аддендум либо после C<<
</section> >>, либо перед C<< <section> >>.

Вы также можете установить режим вставки (I<mode>) в значение C<before> с
аналогичной семантикой: при указании C<mode=before> совместно с
C<endboundary> аддендум будет размещён сразу B<после> строки сопоставленной
C<endboundary>, которая расположена до C<position>; при указании
C<mode=before> совместно с C<beginboundary> аддендум будет размещён сразу
B<перед> строкой сопоставленной C<beginboundary> которая расположена до
C<position>.

  Режим  |  Вид границы  |    Используемая граница    | Точка вставки относительно границы
 ========|===============|============================|===================================
 'before'|'endboundary'  | последняя перед 'position' | Прямо после выбранной границы
 'before'|'beginboundary'| последняя перед 'position' | Прямо перед выбранной границей
 'after' |'endboundary'  | первая после 'position'    | Прямо после выбранной границы
 'after' |'beginboundary'| первая после 'position'    | Прямо перед выбранной границей
 'eof'   | (нет)         | н/д                        | Конец файла

=head3 Советы и хитрости при использовании аддендумов

=over

=item

Запомните, что параметры аргументов аддендумов — это регулярные
выражения. Например, если вы хотите сопоставить конец секции nroff, которая
заканчивается строкой C<.fi>, то не стоит использовать C<.fi> в качестве
B<endboundary>, ибо в таком случае также будет сопоставлена строка C<the[
fi]le>, что, очевидно, не то, что вы ожидаете. Правильный B<endboundary> в
этом случае будет: C<^\.fi$>.

=item

Для параметров C<position> и границ пробелы ВАЖНЫ. Например, две следующие
строки B<различны>. Вторая из них будет найден только в том случае, если в
переведенном документе окажутся лишние пробелы на конце строки.

 PO4A-HEADER: position=Об этом документе; mode=after; beginboundary=<section>
 PO4A-HEADER: position=Об этом документе ; mode=after; beginboundary=<section>

=item

Хотя и можно считать, что этот контекстный поиск, грубо говоря, перебирает
текст B<перевода> построчно, но на самом деле он работает со строками во
внутреннем представлении данных документов. Этой строкой может быть,
например, текст целого абзаца, разбитый на несколько фактических строк или
один XML-тег сам по себе. Непосредственная I<точка вставки> аддендума должна
быть или до, или после таковой строки во внутреннем представлении и не может
быть вставлена в середину оной.

=item

Чтобы лучше понять, как аддендумы добавляются к переводу, передайте B<po4a>
параметр C<-vv>. Также, когда ваш аддендум не применяется и вы не можете
определить, почему, то может быть полезно запустить B<po4a> в режиме
отладки, чтобы непосредственно увидеть строку с данными во внутреннем
представлении.

=back

=head3 Примеры аддендумов

=over

=item

Если вы хотите добавить что-то после следующего раздела nroff (формат
man-страниц):

  .SH "АВТОРЫ"

Вам следует выбрать подход с двумя регулярными выражениями, т.е. задать
B<mode=after>. Затем сузьте поиск до строк идущих после B<АВТОРЫ> с помощью
регулярного выражения в аргументе B<position>. После этого вы должны
сопоставить начало следующей секции (например, с помощью B<^\.SH>) в
аргументе B<beginboundary>. Короче говоря:

 PO4A-HEADER: mode=after; position=АВТОРЫ; beginboundary=\.SH

=item

Если вы хотите добавить что-то сразу после конкретной строки (например,
после «Copyright Большая Шишка»), используйте значение B<position>,
соответствующее этой строке, задайте B<mode=after>, а B<beginboundary> —
значение, соответствие любой строке.

 PO4A-HEADER:mode=after;position=Copyright Большая Шишка, 2004;beginboundary=^

=item

Если вы хотите добавить что-то в конец документа, то присвойте B<position>
регулярное выражение, сопоставляемое любой строке вашего документа (но
только одна строке; po4a выдаст ошибку, если она будет не уникальна), и
задайте B<endboundary> не соответствующее ни чему. Лучше не использовать
здесь простые строки, например B<"EOF">, а отдать предпочтение тем, у
которых меньше шансов оказаться в вашем документе.

 PO4A-HEADER:mode=after;position=О программе;beginboundary=FakePo4aBoundary

=back

=head3 Более подробный пример

Исходный документ (формат POD):

 |=head1 NAME
 |
 |dummy - a dummy program
 |
 |=head1 AUTHOR
 |
 |Me <me@example.com>

Тогда следующий аддендум обеспечит добавление раздела о переводчике (на
русском) в конец файла.

 |PO4A-HEADER:mode=after;position=АВТОР;beginboundary=^=head
 |
 |=head1 ПЕРЕВОД
 |
 |Я <me@example.ru>
 |

Чтобы поместить свой аддендум перед «АВТОР», используйте следующий
заголовок:

 PO4A-HEADER:mode=after;position=ИМЯ;beginboundary=^=head1

Это работает, так как следующая сопоставляемая B<beginboundary> C</^=head1/>
строка после раздела «NAME» (переведённого как «ИМЯ» на русский) и начинает
раздел с перечислением авторов. Таким образом, аддендум будет помещено между
этими двумя разделами. Заметьте, что если в дальнейшем какой-либо другой
раздел будет добавлен между разделами «ИМЯ» и «АВТОР», то данный пример
будет работать не корректно, ибо аддендум будет вставляться перед этим новым
разделом.

Чтобы избежать этого, можете использовать аналогичный заголовок с
B<mode>=I<before>:

 PO4A-HEADER:mode=before;position=^=head1 АВТОР

=head1 Как это работает?

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

=head2 TransTractors и архитектура проекта

В сердце всего проекта po4a находится
L<Locale::Po4a::TransTractor(3pm)|TransTractor>, общий предком всех
классов-парсеров. Своё странное имя он получил оттого, что он одновременно
отвечает и за перевод документа и извлечение строк.

Если точнее, TransTractor берёт документ для перевода плюс PO-файл с
переводами, кои являются его входными данными, и производит два отдельных
набора выходных данных: другой PO-файл (как результат извлечения переводимых
строк из входного документа) и переведённый документ (с той же структурой,
что и входной, но со всеми переводимыми строками заменёнными содержимым
входного PO-файла). Ниже приведено графическое представление этого процесса:

   Входной документ -\                            /---> Выходной документ
                      \      TransTractor::      /       (переведённый)
                      +-->--   parse()  --------+
                     /                           \
   Входной PO ------/                             \---> Выходной PO
                                                       (извлечённый)

Эта маленькая косточка и является ядром всей архитектуры po4a. Если вы
предоставляете оба входных файла и игнорируете выходной PO-файл, вы
получаете B<po4a-translate>. Если вместо этого вы проигнорируете выходной
документ то, вы получите B<po4a-updatepo>. B<po4a> сначала использует один
TransTractor для получения актуального выходного POT-файла (игнорирую
выходные документы), вызывает B<msgmerge -U> для обновления PO-файлов
перевода, а затем создаёт второй TransTractor, который использует эти файлы
для обновления уже выходных документов. Короче говоря, B<po4a> предоставляет
комплексное решение для обновления всего, что нужно обновить, используя
всего одну команду и один файл настроек.

B<po4a-gettextize> также использует два экземпляра TransTractor, но
по-другому: она создаёт по одному TransTractor для каждого языка, а затем
создаёт новый PO-файл, используя значения msgid из исходного документа в
качестве, собственно, msgid и значения msgid из переведённого документа в
качестве msgstr. При этом требуется значительная осторожность, чтобы
гарантировать, что строки, сопоставленные таким образом, действительно
соответствуют друг другу, как описано в L<po4a-gettextize(1)>.

=head2 Парсеры, специфические для конкретных форматов

Парсеры всех форматов в po4a реализованы поверх TransTractor. Некоторые из
них очень простые, например Text, Markdown и AsciiDoc. Они загружают строки
одну за другой, используя C<TransTractor::shiftline()>, и накапливают
содержимое абзацев (или что-то еще). После того как целая логическая строка
(обычно, абзац) будет прочитана и разобрана, парсер использует
C<TransTractor::translate()>, чтобы (1) добавить эту строку в выходной
PO-файл и (2) получить перевод из входного PO-файла. Далее парсер отправляет
результат в выходной файл с помощью C<TransTractor::pushline()>.

Некоторые другие парсиры более сложны, поскольку для анализа входного
документа они полагаются на сторонние парсеры. Так например, парсеры Xml,
HTML, SGML и Pod построены на основе SAX-парсеров. Они создают обратные
вызовы для таких событий, как «Я нашёл новый заголовок со следующим
содержимым», чтобы обновить выходной документ и выходные POT-файлы в
соответствии со входным содержимым, используя C<TransTractor::translate()> и
C<TransTractor::pushline()>. Парсер Yaml также похож, но отличается: он
сохраняет структуру данных, созданную парсером YAML::Tiny. В этом причина
того, что Yaml-модуль po4a не может корректно сохранять сноски на
расположение строк в исходном файле: синтаксический анализатор не сохраняет
расположение каждой строки, поэтому всё что мы можем, это только добавить
«$имя_файла:1» в качестве местоположения строки. Парсеры же, основанные на
SAX-модели, используют глобальные переменные и другие приёмы для сохранения
имен файлов и номеров строк в сносках.

Особый класс проблем возникает из-за кодировок файлов и маркера порядка
байт. Более простые парсеры могут не волноваться об этом, так как
C<TransTractor::read()> (используется внутри пасеров для чтения входного
документа) сам заботится об обработке кодировок. А вот модули, использующие
внешний парсеры, должны сами контролировать, что все файлы, которые они
читают проходят через соответствующие уровни декодирования PerlIO. Самое
простое — открыть файл самостоятельно и передать внешнему парсеру или
дескриптор файла, или прочитать его самостоятельно и передать всё его
содержимое парсеру в виде строки. В качестве примера см. C<Pod::read()> и
C<Pod::parse()>. В случае, когда дескриптор файла передаётся внешнему
парсеру, то то, что читает TransTractor, должно быть проигнорированно, а
также важно, чтобы при открытии файла perl-функции B<open()> передавалась
корректная кодировка: C<< <:encoding($charset) >>.

=head2 PO-объекты

Класс L<Locale::Po4a::Po(3pm)|Po> отвечает за загрузку PO и POT-файлов, а
также запрос переведённых строк из них. Если кратко, то вы можете читать
файл, добавлять в него записи, получать из него переводы с помощью
B<gettext()> и снова сохранять PO-файл. Более сложная функциональность,
вроде объединение PO-файлов с POT-файлами или проверка файлов, отдаётся уже
на откуп утилитам B<msgmerge> и B<msgfmt> соответственно.

=head2 Внесение своего вклада в po4a

Даже если вы никогда раньше не участвовали в каких-либо проектах с открытым
исходным кодом, мы будем вам рады: здесь мы готовы помочь вам и,
по-необходимости, можем дать вам некоторые наставления. po4a в настоящее
время в основном поддерживается пользователями. Поскольку нам не хватает
рабочей силы, мы стараемся сделать проект приветливым и привлекательным,
улучшая документацию и автоматизированные тесты, чтобы вам было проще внести
свой вклад в проект. Более подробную информацию можно найти в файле
CONTRIBUTING.md.

=head1 Проекты с открытым исходным кодом, использующие po4a

Вот очень неполный список проектов, которые используют po4a при переводе
своей документации. Если вы хотите добавить свой проект в список, то просто
напишите нам e-mail (или запрос на слияние).

=over

=item

adduser (man): инструмент по управлению пользователями и группами.

=item

apt (man, docbook): менеджер пакетов Debian.

=item

aptitude (docbook, svg): консольный менеджер пакетов для Debian

=item

L<F-Droid website|https://gitlab.com/fdroid/fdroid-website> (markdown):
каталог свободных и открытых приложений (Free and Open Source Software) для
платформы Android.

=item

L<git|https://github.com/jnavila/git-manpages-l10n> (asciidoc):
распределённая система контроля изменений исходного кода.

=item

L<Linux manpages|https://salsa.debian.org/manpages-l10n-team/manpages-l10n>
(man)

Также этот проект предоставляет инфраструктуру для перевода на разные языки
множества разношёрстных man-страниц, которые затем интегрируются во многие
основные дистрибутивы (в частности, Arch Linux, Debian и его производные,
Fedora).

=item

L<Stellarium|https://github.com/Stellarium/stellarium> (HTML): свободный
планетарий для Вашего компьютера с открытым исходным кодом. po4a
используется для перевода названий созвездий в различных культурах.

=item

L<Jamulus|https://jamulus.io/> (markdown, yaml, HTML): FOSS-приложение для
онлайн джем-сессий в режиме реального времени. Переводы документации и
веб-сайта на несколько языков поддерживаются с использованием po4a.

=item

И другие проекты, в которых мы пока не разобрались:
L<https://gitlab.com/fdroid/fdroid-website/>
L<https://github.com/fsfe/reuse-docs/pull/61>

=back

=head1 Часто задаваемые вопросы

=head2 Как вы произносите «po4a»?

Лично я произношу это как L<pouah|https://en.wiktionary.org/wiki/pouah>, это
французское междометие, подобное русскому «фу!» :) Возможно, у меня странное
чувство юмора :)

=head2 Почему специализированные сценарии признаны устаревшими?

B<po4a-updatepo> и B<po4a-translate>, действительно, считаются устаревшими
(depricated) в пользу B<po4a>. Причина в том, что, с одной стороны, B<po4a>
можно использовать в качестве прямой замены этих сценариев, а с другой —
между ними довольно много дублирующегося кода, который сложно
поддерживать. Отдельные сценарии состоят примерно из 150 строк кода, а
утилита B<po4a> — из 1200, так что она имеет куда более изощрённую логику. К
тому же, дублирование кода приводит к тому, что ошибки, возникающие в обеих
версиях, требуют того, чтобы их исправляли дважды. Одним из таких примеров
может служить баг #1022216 в Debian и сообщение об ошибке #442 на GitHub,
для которых требовались практически одинаковые действия по исправлению, но
одно было в B<po4a>, а другое в B<po4a-updatepo>.

В долгосрочной перспективе я бы хотел полностью отказаться от
специализированных сценариев и поддерживать только одну версию этого
кода. Разумеется, в специализированные сценарии больше не будет добавляться
ни какой новой функциональности, которая будет только в B<po4a>. При этом
нет никакой срочности в полном отказе от оных. Я планирую сохранять
специализированные сценарии как можно дольше, по крайней мере, до 2030
года. Если в 2030 году ваш проект по-прежнему будет использовать
B<po4a-updatepo> и B<po4a-translate>, то у вас могут возникнуть проблемы.

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

=head2 Как насчёт других инструментов перевода документации, использующих gettext?

Таковых есть несколько. Вот их (возможно неполный) список, а также на
горизонте маячат несколько новых инструментов.

=over

=item B<poxml>

Это инструмент, разработанный командой KDE для работы с DocBook XML. На
сколько я знаю, это была первая программа, которая извлекала переводимые
строки из документации в PO-файлы и подставляла их обратно после перевода.

Она может обрабатывать только XML и только с определённым DTD. Мне не очень
нравится, как она обрабатывает списки, которые представляются одним большим
msgid. Когда список становится большим, весь этот кусок становится сложно
переработать.

=item B<po-debiandoc>

Эта программа, созданная Денисом Барбье, является своего рода
предшественником модуля SGML в po4a, который более или менее делает её
устаревшей. Как становится ясно из названия, она обрабатывает только DTD
DebianDoc, который также относительно устарел.

=item B<xml2po.py>

Используется командой документации GIMP с 2004 года; работает достаточно
хорошо, даже с учётом того, что, как следует из названия, она работает
только с XML-файлами, а также она требует специализированных make-файлов.

=item B<Sphinx>

Генератор документации Sphinx также активно использует gettext для
управления переводами. К сожалению, он работает только с ограниченным
набором текстовых форматов: rest и markdown, хотя это, пожалуй, единственный
инструмент, который полностью управляет всем процессом перевода.

=back

Основные преимущества po4a перед оными — это простота добавления
дополнительного содержипого (по крайней мере там это реализовано ещё хуже) и
возможность проведения геттекстизации.

=head2 РЕЗЮМЕ преимуществ подхода, основанного на gettext

=over 2

=item

Переводы хранятся отдельно от оригиналов, что позволяет определить, устарели
ли первые.

=item

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

=item

Внутренне устройство основано на B<gettext> (но B<po4a> предлагает простой
интерфейс, так что вам не нужно понимать его внутреннее устройство, чтобы
просто пользоваться им). Таким образом, нам не приходится заново изобретать
колесо, а, так как B<gettext> широко используется, мы можем считать, что в
нём остаётся относительно мало программных ошибок.

=item

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

=item

Переводчикам не нужно изучать новый синтаксис файлов, и их любимого
редактора PO-файлов (например, PO-режим Emacs, Lokalize или Gtranslator)
будет вполне достаточно.

=item

gettext предлагает простой способ получить статистику о том, что готово, что
должно быть проверено и обновлено, а что ещё предстоит сделать. Некоторые
примеры можно найти по следующим ссылкам:

 - https://docs.kde.org/stable5/en/kdesdk/lokalize/project-view.html
 - http://www.debian.org/intl/l10n/

=back

Но не всё так радужно, и этот подход также имеет некоторые недостатки, с
которыми нам приходится смириться.

=over 2

=item

Аддендумы несколько странные на первый взгляд.

=item

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

=item

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

Одна моя мечта состоит в том, чтобы каким-то образом интегрировать po4a в
Gtranslator или Lokalize. Тогда при открытии файла документации, строки
автоматически извлекались бы, а когда он сохранялся, переведённый файл и
PO-файл мог ли бы записываться на диск. Если бы нам удалось сделать модуль
MS Word (TM) (или, по крайней мере, RTF), то даже профессиональные
переводчики могли бы использовать po4a.

=back

=head1 СМОТРИТЕ ТАКЖЕ

=over

=item

Документацию L<po4a(1)>, основной утилиты, которую вы должны использовать.

=item

Документация отдельных сценариев po4a: L<po4a-gettextize(1)>,
L<po4a-updatepo(1)>, L<po4a-translate(1)>, L<po4a-normalize(1)>.

=item

Дополнительные вспомогательные сценарии: L<msguntypot(1)>,
L<po4a-display-man(1)>, L<po4a-display-pod(1)>.

=item

Парсеры для каждого отдельного формата, в особенности обратите внимание на
параметры, принимаемые каждым из них: L<Locale::Po4a::AsciiDoc(3pm)>
L<Locale::Po4a::Dia(3pm)>, L<Locale::Po4a::Gemtext(3pm)>,
L<Locale::Po4a::Guide(3pm)>, L<Locale::Po4a::Ini(3pm)>,
L<Locale::Po4a::KernelHelp(3pm)>, L<Locale::Po4a::Man(3pm)>,
L<Locale::Po4a::RubyDoc(3pm)>, L<Locale::Po4a::Texinfo(3pm)>,
L<Locale::Po4a::Text(3pm)>, L<Locale::Po4a::Xhtml(3pm)>,
L<Locale::Po4a::Yaml(3pm)>, L<Locale::Po4a::BibTeX(3pm)>,
L<Locale::Po4a::Docbook(3pm)>, L<Locale::Po4a::Halibut(3pm)>,
L<Locale::Po4a::LaTeX(3pm)>, L<Locale::Po4a::Org(3pm)>,
L<Locale::Po4a::Pod(3pm)>, L<Locale::Po4a::Sgml(3pm)>,
L<Locale::Po4a::TeX(3pm)>, L<Locale::Po4a::VimHelp>,
L<Locale::Po4a::Wml(3pm)>,
L<Locale::Po4a::Xml(3pm)>.L<Locale::Po4a::Dia(3pm)>,
L<Locale::Po4a::Gemtext(3pm)>, L<Locale::Po4a::Guide(3pm)>,
L<Locale::Po4a::Ini(3pm)>, L<Locale::Po4a::KernelHelp(3pm)>,
L<Locale::Po4a::Man(3pm)>, L<Locale::Po4a::RubyDoc(3pm)>,
L<Locale::Po4a::Texinfo(3pm)>, L<Locale::Po4a::Text(3pm)>,
L<Locale::Po4a::Xhtml(3pm)>, L<Locale::Po4a::Yaml(3pm)>,
L<Locale::Po4a::BibTeX(3pm)>, L<Locale::Po4a::Docbook(3pm)>,
L<Locale::Po4a::Halibut(3pm)>, L<Locale::Po4a::LaTeX(3pm)>,
L<Locale::Po4a::Org(3pm)>, L<Locale::Po4a::Pod(3pm)>,
L<Locale::Po4a::SimplePod(3pm)>, L<Locale::Po4a::Sgml(3pm)>,
L<Locale::Po4a::TeX(3pm)>, L<Locale::Po4a::VimHelp>,
L<Locale::Po4a::Wml(3pm)>, L<Locale::Po4a::Xml(3pm)>.

=item

Реализации базовых классов: L<Locale::Po4a::TransTractor(3pm)> (особенно
важно для понимания организации кода), L<Locale::Po4a::Chooser(3pm)>,
L<Locale::Po4a::Po(3pm)>, L<Locale::Po4a::Common(3pm)>. Также проверьте файл
F<CONTRIBUTING.md> в дереве исходного кода.

=back

=head1 АВТОРЫ

 Денис Барбье (Denis Barbier) <barbier,linuxfr.org>
 Мартин Кенсон (Martin Quinson) (mquinson#debian.org)
