Проект по переводу сайта www.gnu.org на русский язык

О порядке работы

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

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

Список рассылки

Список рассылки проекта <www-ru-list@nongnu.org>. Это — единственный список рассылки проекта, так что здесь можно попытаться обсудить любой вопрос, имеющий отношение к проекту.

Обратите внимание, что письма с приложениями иногда не доходят. Если вы хотите послать файл, лучше поместить его в Bug Tracker проекта и сослаться на него в сообщении. Есть мнение, что с Bug Tracker удобнее работать, когда у вас есть учётная запись на savannah.gnu.org. При переписке, пожалуйста, обращайте внимание на то, чтобы адрес списка рассылки фигурировал среди адресатов (распространённая ошибка — отвечать только одному из участников).

Регистрация на savannah.gnu.org

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

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

Регистрация обычно не представляет затруднений. От вас потребуется представиться и указать свой адрес электронной почты.

Bug Tracker проекта

В Bug Tracker можно помещать файлы с переводами. Имеет смысл сообщать о новых файлах в списке рассылке проекта. Обсуждать файлы можно либо в списке рассылки, либо в том же Bug Tracker.

Общая документация по переводам

На сайте www.gnu.org есть общие указания по переводам. Если вы собираетесь делать что-то большее, чем докладывать об опечатках и прочих несуразностях, то, видимо, имеет смысл прочесть руководство по переводам. На сегодня предпочтительная форма переводов — так называемые PO-файлы. Присылать материалы можно и в любом другом виде, но тогда оформлять их придётся действительным членам проекта, а у них очень мало времени.

В списке документации по переводам находится также документация по GNUN — набору программ, с помощью которых PO-файлы транслируются в страницы сайта. Её читать не обязательно. То, что может быть важно для переводчика, собрано ниже на этой странице.

Рабочие копии страниц

Рабочая копия нужна, чтобы получить исходные PO-файлы для редактирования.

Рекомендуется освоить команды CVS checkout и особенно update.

Рабочая копия проекта по переводу

Страницы, переведённые в историческое время, находятся в Web CVS:

	cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/webcvs/www-ru co www-ru

Переводы сайта www.gnu.org находятся в каталоге www-ru/translations.

Рабочая копия www.gnu.org

	cvs -d:pserver:anonymous@cvs.sv.gnu.org:/web/www co www

Команда выполняется достаточно долго, файлы занимают порядка трёхсот мегабайт.

Как уже отмечено, вас интересуют файлы с расширением .po (или, если вы делаете новый перевод, .pot). Они находятся в каталогах po, например, файл rms-lisp.ru.po, соответствующий файлу gnu/rms-lisp.html, должен быть в каталоге gnu/po. Если такого файла нет, вы переименовываете файл gnu/po/rms-lisp.pot в rms-lisp.ru.po.

Можно также получать файлы по одному другим способом:

ViewVC для проекта www-ru

ViewVC для проекта www

PO-файлы

По существу, PO-файл — это текстовый файл, в котором строкам оригинала сопоставлены строки перевода. Примерно так:

     # знаком `#' в первой позиции начинаются комментарии
     msgid "Gnu's Not Unix!"
     "subsequent line"
     msgstr ""
     "ГНU - не Unix!"
     "следующая строка"

В файлах используется кодировка UTF-8.

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

The following diagram illustrates a typical workflow—it is applicable for small, medium and large teams:

     +----------+                   +-------------------+
     | ``www''  |                   |   ``www-LANG''    |
     |   Web    |------>---->-------|Sources repository |
     |repository|  automatic merge  +-------------------+
     +----------+                         |    |     |
          |                               |    |     `-- Member A
          +------------<----<-------------'    |
                       Leader                  `---Member B

All members and the team leader(s) commit in their project's repository—when a translation is ready, the leader checks it in in the official `www' repository. If an original article changes, a build could be invoked to synchronize (i.e. merge) the changes and optionally automatically commit them so that the draft PO files are updated. A translator would then normally update the PO file, and commit it again in the project's Sources repository, from where the coordinator will pick it up and install it in `www'.

Подразумевается, что Member A и Member B могут получать переводы от людей, которые не являются членами проекта. Также следует обратить внимание, что Sources repository на схеме в нашем случае нужно читать как Web repository (см. выше).

Таким образом, перевод в общем случае проходит такие стадии:

  1. Первоначальный перевод (или поправки к переводу), помещаемый в Bug Tracker с возможным сообщением в списке рассылки
  2. Проверка перевода одним или несколькими действительными членами проекта
  3. Размещение перевода на сайте проекта www-ru
  4. Проверка перевода координаторами проекта
  5. Размещение перевода на www.gnu.org

Следует иметь в виду, что к работе нашего проекта это описание typical workflow вообще может не иметь никакого отношения; это связано с тем, что коллектив не просто маленький, а очень маленький.

2.3 Working with PO Files

We anticipate that some gnu.org translators will find this format odd or inconvenient, if they never happened to work with PO files before. Don't worry, you will soon get accustomed to it. It is the established format for translations in the Free World, and you should have no problems if you have translated software before.

The most efficient way to edit a PO file is using a specialized PO editor, because each of them represents and treats gettext messages in a consistent and predictable way. It is possible to edit a PO file with an ordinary plain text editor, but extra effort would be necessary to make it valid. Here is a list of widely used PO editors:

2.3.1 Starting a New Translation

To start a new translation, the easiest way is to copy the existing POT as article.lang.po, where lang is your language code. For example, to prepare for a new translation of the essay http://www.gnu.org/philosophy/free-sw.html, you can simply do cd philosophy/po ; cp free-sw.pot free-sw.lang.po and then edit the latter. If free-sw.pot does not exist it is because either the article is not yet “templated” (i.e. migrated to the new style), or the GNUN maintainers have not yet added it to the value of the appropriate variable in server/gnun/gnun.mk. In that case, just ask them to do the necessary in order the POT to be generated.

You could also use the msginit utility that would populate the PO file header with the right information, provided your environment is set up correctly. See msginit Invocation.

The PO file header as generated usually looks like this:

     # SOME DESCRIPTIVE TITLE
     # Copyright (C) YEAR Free Software Foundation, Inc.
     # This file is distributed under the same license as the PACKAGE package.
     # FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
     #
     #, fuzzy
     msgid ""
     msgstr ""
     "Project-Id-Version: PACKAGE VERSION\n"
     "POT-Creation-Date: 2008-02-06 16:25-0500\n"
     "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
     "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
     "Language-Team: LANGUAGE <LL@li.org>\n"
     "MIME-Version: 1.0\n"
     "Content-Type: text/plain; charset=CHARSET\n"
     "Content-Transfer-Encoding: ENCODING\n"

You have to edit the header to match the already established conventions, and the rules for gnu.org translations. For reference, here is a list with all fields explained:

`Project-Id-Version'
Add here the filename of the original article, without the sub-directory, like “body-include-1.html” or “free-sw.html”.
`POT-Creation-Date'
Do not edit this field, it is already set when the POT is created.
`PO-Revision-Date'
Likewise, do not edit. This field is automatically filled in when you save the file with any decent PO editor.
`Last-Translator'
The name and email address of the last translator who have edited the translation. Pay attention that normally this is the name of a member of your team, it can be the translation team leader if he/she was the person who updated the translation. For example:
          Elvis Parsley <king@grassland.com>
     

`Language-Team'
This field should contain the mailing list on which the translation team can be reached—sometimes this is the alias web-translators-LANG@gnu.org, but in some cases it is a separate, non-GNU list. It could be a URL of the team's homepage, provided that it contains contact details. Example:
          French <trad-gnu@april.org>
     

`MIME-Version'
Leave it like it is.
`Content-Type'
Usually this is text/plain; charset=UTF-8; change the charset accordingly.
`Content-Transfer-Encoding'
Set this to 8bit. Note that the PO file header ends with this field, and it should contain a newline (`\n'). Unfortunately, some PO editors remove the newline, which causes an unnecessary revision when the file is automatically modified by GNUN's rules.

Here is an example of a properly edited header:

     # Bulgarian translation of http://www.gnu.org/philosophy/free-sw.html
     # Copyright (C) 2008 Free Software Foundation, Inc.
     # This file is distributed under the same license as the gnu.org article.
     # Yavor Doganov <yavor@gnu.org>, 2008.
     #
     msgid ""
     msgstr ""
     "Project-Id-Version: free-sw.html\n"
     "POT-Creation-Date: 2008-02-06 16:25-0500\n"
     "PO-Revision-Date: 2008-02-09 15:23+0200\n"
     "Last-Translator: Yavor Doganov <yavor@gnu.org>\n"
     "Language-Team: Bulgarian <dict@fsa-bg.org>\n"
     "MIME-Version: 1.0\n"
     "Content-Type: text/plain; charset=UTF-8\n"
     "Content-Transfer-Encoding: 8-bit\n"

Notice the absence of the “fuzzy” marker; you should “unfuzzy” the header after entering the necessary information (this is done by simply pressing <TAB> in PO mode).

There are some special messages that appear in the POT and PO:

`*GNUN-SLOT: TRANSLATOR'S NOTES*'
This is for translator's notes that are injected in the resulting translation. See Notes Slot, for more information. If your translation does not have notes, you must translate this as a space, that is, <SPC>.


`*GNUN-SLOT: TRANSLATOR'S CREDITS*'
This is again optional, and should contain the name (and address) of the person who made the translation. “Translate” this string as a space (<SPC>) if you do not want your name to appear there. See Credits Slot.

Most of the PO editors do not wrap long lines that inevitably appear in msgstr's. If that happens, long lines make reading subsequent diffs harder, and are generally annoying for most people. If this issue bothers you, you can “normalize” the already finished PO translation by executing on the command line msgcat -o file.po file.po, before installing it in the repository. Either way, the build system will treat it is a valid PO file.

For those lucky Emacs users, here is a code snippet that you can put in your .emacs; doing M-x po-wrap while in PO mode will wrap all long lines:

     (defun po-wrap ()
       "Filter current po-mode buffer through `msgcat' tool to wrap all lines."
       (interactive)
       (if (eq major-mode 'po-mode)
           (let ((tmp-file (make-temp-file "po-wrap."))
     	    (tmp-buf (generate-new-buffer "*temp*")))
     	(unwind-protect
     	    (progn
     	      (write-region (point-min) (point-max) tmp-file nil 1)
     	      (if (zerop
     		   (call-process
     		    "msgcat" nil tmp-buf t (shell-quote-argument tmp-file)))
     		  (let ((saved (point))
     			(inhibit-read-only t))
     		    (delete-region (point-min) (point-max))
     		    (insert-buffer tmp-buf)
     		    (goto-char (min saved (point-max))))
     		(with-current-buffer tmp-buf
     		  (error (buffer-string)))))
     	  (kill-buffer tmp-buf)
     	  (delete-file tmp-file)))))

It is highly desirable that you check if the PO file you finished translating (or editing) is valid, before committing it. This is done by running msgfmt -cv -o /dev/null file or by simply pressing V in PO mode. The build system automatically verifies each PO file when invoked with VALIDATE=yes, but you won't get a warm and fuzzy feeling if a stupid typo you made halts the whole update of all translations. Such things happen to everyone, so it is a good practice to check before you actually commit.

2.3.4 Useful Hints For Editing PO Files

This section contains additional explanations, some in the form of advices and recommendations; not all of them are strictly related to PO files editing.

Предварительный просмотр переводов

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

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

Дальше подразумевается, что у вас есть общие представления о том, как конфигурируются, собираются и устанавливаются пакеты, использующие GNU Autotools. Также подразумевается, что вы работаете в GNU. В других системах это не проверялось.

Сначала вы устанавливаете GNUN: gnun-0.4.tar.gz, gnun-0.4.tar.gz.sig. Для работы GNUN требуется Perl, GNU make 3.81 (с более старыми версиями не работает) и PO4A.

Опыт показывает, что PO4A можно устанавливать в домашний каталог таким образом:

	tar xzf po4a-v0.37.1.tar.gz; cd po4a-v0.37.1;
	mkdir ~/gnun;cp -a lib ~/gnun
	mkdir ~/gnun/bin
	cp po4a{,-gettextize,-normalize,-translate,-updatepo} ~/gnun/bin
	export PERLLIB=$HOME/gnun/lib
	export PATH=$HOME/gnun/bin:$PATH

Обратите внимание на переменные PERLLIB и PATH. Не исключено, что вы захотите добавить их в сценарий инициализации своего командного интерпретатора.

Установка собственно GNUN:

	f=gnun-0.4.tar.gz;gpg --verify $f.sig&&tar xzf $f
	cd gnun-0.4;./configure --prefix=$HOME/gnun
	make&&make install

После этого вы делаете рабочую копию проекта www и копируете файлы config.mk и GNUMakefile из gnun-0.4 в www/server/gnun. В файле NEWS GNUN описана другая практика, но так, кажется, проще.

Обновление файлов HTML производится из каталога www командой

	make -C server/gnun

На самом деле зависимости между файлами HTML и PO достаточно сложны, в процессе обновления регенерируются POT-файлы, изменения в них транслируются во все имеющиеся PO-файлы переводов, и уже после этого генерируются переведённые файлы HTML.

Это означает, что для надёжного обновления файлов с помощью текущей версии GNUN нужно, чтобы исходный файл HTML (оригинальный текст на английском) был новее, чем файл POT, что не всегда гарантируется, если использовать CVS. Нужное состояние достигается командой

	touch gnu/rms-lisp.html

(замените gnu/rms-lisp.html на файл, с которым собираетесь работать)

В результате вы получаете обновлённые файл в каталоге po (gnu/po/rms-lisp.ru.po) и файл HTML с переводом (gnu/rms-lisp.ru.html

На самом деле gnu/rms-lisp.ru.html — это не совсем то, что будет на сайте. Некоторые части там опущены, например, может потребоваться вручную указать браузеру кодировку UTF-8. Но основной текст всё же можно просмотреть.

Других способов неизвестно.

Переведённые страницы

Главная страница проекта на savannah.gnu.org


Обновлено: $Date$ $Author$