
        *****************************************************
        *           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 section, 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::Yaml>.



=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 Другие поддерживаемые форматы

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

Исторически po4a был построен на основе четырех скриптов, каждый из которых выполнял определенную задачу. L<po4a-gettextize(1)> помогает загружать переводы и, по желанию, конвертировать существующие проекты переводов в po4a. L<po4a-updatepo(1)> отражает изменения в оригинальной документации в соответствующих po-файлах.  L<po4a-translate(1)> создает переведенный исходный файл из исходного файла и соответствующего PO-файла. Кроме того, L<po4a-normalize(1)> в основном полезен для отладки парсеров po4a, так как он создает непереведенный документ из исходного. Это облегчает поиск ошибок, вносимых процессом синтаксического анализа.

Most projects only require the features of L<po4a-updatepo(1)> and L<po4a-translate(1)>, but these scripts proved to be cumbersome and error prone to use. If the documentation to translate is split over several source files, it is difficult to keep the PO files up to date and build the documentation files correctly. As an answer, a all-in-one tool was provided: L<po4a(1)>. This tool takes a configuration file describing the structure of the translation project: the location of the PO files, the list of files to translate, and the options to use, and it fully automates the process. When you invoke L<po4a(1)>, it both updates the PO files and regenerate the translation files that need to. If everything is already up to date, L<po4a(1)> does not change any file.

В остальной части этого раздела приводится обзор использования интерфейса скриптов po4a. Большинство пользователей, вероятно, предпочтут использовать инструмент "все в одном", который описан в документации L<po4a(1)>.

=head2 Наглядный обзор сценариев po4a

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

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

Эта схема сложна, но на практике только правая часть (включающая L<po4a-updatepo(1)> и L<po4a-translate(1)>) используется после установки и настройки проекта.

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

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

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

В нижней части рисунка показано, как L<po4a-translate(1)> создает переведенный исходный документ из исходного документа F<master.doc> и каталога переводов F<doc.XX.po>, который был обновлен переводчиками. Структура документа используется повторно, а оригинальное содержание заменяется его переведенным аналогом. По желанию можно использовать дополнение, чтобы добавить к переводу дополнительный текст. Это часто используется для добавления имени переводчика в окончательный документ. Подробности см. ниже.

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

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

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

Если вы предпочитаете использовать отдельные скрипты по отдельности, то для создания файла POT следует использовать L<po4a-gettextize(1)> следующим образом. Затем этот файл можно скопировать в F<XX.po>, чтобы инициировать новый перевод.

  $ po4a-gettextize --format <формат> --master <мастер.doc> --po <переводы.pot>

Мастер-документ используется на входе, а файл POT является выходом этого процесса.

=head2 Интеграция изменений в исходный документ

Для этого следует использовать скрипт L<po4a-updatepo(1)> (подробности см. в документации к нему):

  $ po4a-updatepo --format <формат> --master <новый_мастер.doc> --po <старый_doc.XX.po>

Мастер-документ используется на входе, а файл PO обновляется: он используется как на входе, так и на выходе.

=head2 Генерация переведённого документа

Когда вы закончите с переводом, вы захотите получить переведённую документацию и распространять её своим пользователям вместе с оригиналом. Для этого используйте программу L<po4a-translate(1)> следующим образом:

  $ po4a-translate --format <формат> --master <мастер.doc> --po <doc.XX.po> --localized <XX.doc>

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

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

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

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

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

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

 PO4A-HEADER: mode=eof

Things are more complex when you want to add your extra content in the middle of the document. The following header declares an addendum that must be placed after the XML section containing the string C<About this document> in translation.

=pod

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

In practice, when trying to apply an addendum, po4a searches for the first line matching the C<position> argument (this can be a regexp). Do not forget that po4a considers the B<translated> document here. This documentation is in English, but your line should probably read as follows if you intend your addendum to apply to the French translation of the document.

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

Once the C<position> is found in the target document, po4a searches for the next line after the C<position> that matches the provided C<endboundary>. The addendum is added right B<after> that line (because we provided an I<endboundary>, i.e. a boundary ending the current section).

The exact same effect could be obtained with the following header, that is equivalent:

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

Here, po4a searches for the first line matching C<<section>> after the line matching C<About this document> in the translation, and add the addendum B<before> that line since we provided a I<beginboundary>, i.e. a boundary marking the beginning of the next section. So this header line requires to place the addendum after the section containing C<About this document>, and instruct po4a that a section starts with a line containing the C<<section>> tag. This is equivalent to the previous example because what you really want is to add this addendum either after C</section>> or before C<<section>>.

You can also set the insertion I<mode> to the value C<before>, with a similar semantic: combining C<mode=before> with an C<endboundary> will put the addendum just B<after> the matched boundary, that the last potential boundary line before the C<position>. Combining C<mode=before> with an C<beginboundary> will put the addendum just B<before> the matched boundary, that the last potential boundary line before the C<position>.

  Mode   | Boundary kind |     Used boundary      | Insertion point compared to the boundary
 ========|===============|========================|=========================================
 'before'| 'endboundary' | last before 'position' | Right after the selected boundary
 'before'|'beginboundary'| last before 'position' | Right before the selected boundary
 'after' | 'endboundary' | first after 'position' | Right after the selected boundary
 'after' |'beginboundary'| first after 'position' | Right before the selected boundary
 'eof'   |   (none)      |  n/a                   | End of file

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

=over 

=item 

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

=item 

White spaces ARE important in the content of the C<position> and boundaries. So the two following lines B<are different>. The second one will only be found if there is enough trailing spaces in the translated document.

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

=item 

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

=item 

Pass the B<-vv> argument to po4a to understand how the addenda are added to the translation. It may also help to run po4a in debug mode to see the actual internal data string when your addendum does not apply.

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

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

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

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

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

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

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

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



Эта маленькая косточка и является ядром всей архитектуры po4a. Если вы уберёте входной PO и выходной документ, вы получите B<po4a-gettextize>. Если предоставите оба набора входных данных и проигнорируете выходной PO, вы получите B<po4a-translate>. B<po4a> вызывает TransTractor дважды и вызывает B<msgmerge -U> между оными вызовами, дабы это было комплексное решение с одним файлом настроек. См. подробности в L<Locale::Po4a::TransTractor(3pm)>.

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

Here is a very partial list of projects that use po4a in production for their documentation. If you want to add your project to the list, just drop us an email (or a Merge Request).

=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)

This project provides an infrastructure for translating many manpages to different languages, ready for integration into several major distributions (Arch Linux, Debian and derivatives, Fedora).

=item 

L<Stellarium|https://github.com/Stellarium/stellarium> (HTML): a free open source planetarium for your computer. po4a is used to translate the sky culture descriptions.

=item 

Other item to sort out: L<https://gitlab.com/fdroid/fdroid-website/> L<https://github.com/fsfe/reuse-docs/pull/61>

=back

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

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

I personally vocalize it as L<pouah|https://en.wiktionary.org/wiki/pouah>, which is a French onomatopoetic that we use in place of yuck :) I may have a strange sense of humor :)

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

There are a few of them. Here is a possibly incomplete list, and more tools are coming at the horizon.

=over 

=item B<poxml>

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

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

=item B<po-debiandoc>

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

=item B<xml2po.py>

Used by the GIMP Documentation Team since 2004, works quite well even if, as the name suggests, only with XML files and needs specially configured makefiles.

=item B<Sphinx>

The Sphinx Documentation Project also uses gettext extensively to manage its translations. Unfortunately, it works only for a few text formats, rest and markdown, although it is perhaps the only tool that does this managing the whole translation process.

=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 

The documentation of the all-in-one tool that you should use: L<po4a(1)>.

=item 

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

=item 

The additional helping scripts: 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::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::Pod(3pm)>, L<Locale::Po4a::Sgml(3pm)>, L<Locale::Po4a::TeX(3pm)>, L<Locale::Po4a::Wml(3pm)>, L<Locale::Po4a::Xml(3pm)>.

=item 

The implementation of the core infrastructure: L<Locale::Po4a::TransTractor(3pm)> (particularly important to understand the code organization), L<Locale::Po4a::Chooser(3pm)>, L<Locale::Po4a::Po(3pm)>, L<Locale::Po4a::Common(3pm)>. Please also check the F<CONTRIBUTING.md> file in the source tree.

=back

=head1 АВТОРЫ

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

