Далее следует описание складывающейся практики переводов, составленное в двадцатых числах декабря 2009 года. Оно предназначено для тех, кто хотел бы присоединиться к проекту или просто помочь ему. Здесь описаны методы, которые работают в настоящий момент. Если вы придумаете что-то лучше, можете опробовать это и рассказать нам о результатах.
Эта документация может показаться неполной или противоречивой, но ничего другого у нас нет.
Список рассылки проекта <www-ru-list@nongnu.org>. Это — единственный список рассылки проекта, так что здесь можно попытаться обсудить любой вопрос, имеющий отношение к проекту.
Обратите внимание, что письма с приложениями иногда не доходят. Если вы хотите послать файл, лучше поместить его в Bug Tracker проекта и сослаться на него в сообщении. Есть мнение, что с Bug Tracker удобнее работать, когда у вас есть учётная запись на savannah.gnu.org. При переписке, пожалуйста, обращайте внимание на то, чтобы адрес списка рассылки фигурировал среди адресатов (распространённая ошибка — отвечать только одному из участников).
Даёт более удобный доступ к службам проекта, в частности, Bug Tracker. Например, после размещения нового файла система будет оповещать вас по электронной почте, когда кто-нибудь добавляет комментарий к вашему файлу.
В долгосрочной перспективе учётная запись может потребоваться также для того, чтобы получить доступ на запись к материалам проектов savannah.gnu.org, в том числе и нашего проекта.
Регистрация обычно не представляет затруднений. От вас потребуется представиться и указать свой адрес электронной почты.
В 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.
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.
Можно также получать файлы по одному другим способом:
По существу, 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 (см. выше).
Таким образом, перевод в общем случае проходит такие стадии:
Следует иметь в виду, что к работе нашего проекта это описание typical workflow вообще может не иметь никакого отношения; это связано с тем, что коллектив не просто маленький, а очень маленький.
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:
M-x po-mode <RET>
. On some GNU/Linux
distros such as gNewSense, PO mode is available in a separate package,
gettext-el
. See http://www.gnu.org/software/gettext.
wxWidgets
graphical toolkit. See http://www.poedit.net.
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:
Elvis Parsley <king@grassland.com>
French <trad-gnu@april.org>
text/plain; charset=UTF-8
; change the charset
accordingly.
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:
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.
This section contains additional explanations, some in the form of advices and recommendations; not all of them are strictly related to PO files editing.
In the next build, your article.lang.html will be built and the link to it will propagate to all translations, provided that they are under GNUN's control.
TEMPLATE_LINGUAS
or HOME_LINGUAS
for you, as
appropriate.
msgstr
and edit the latter by
translating the English text. In PO mode, this is done by C-j.
This is useful also for large chunks of text in <pre>
elements,
which normally you would want to preserve verbatim.
<address>
; otherwise it looks awkward in most
languages. Example:
# type: Content of: <div><address> msgid "51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA" msgstr "" "Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, " "Boston, MA 02110-1301, USA"
msgstr
using M-q in Emacs (or other means) is
considered harmful. It is best to leave GNUN (or more
precisely, Po4a) to do the wrapping—that way all generated HTML
translations will have predictable results. This will help tremendously
for the conversion to other formats, like Texinfo. Also, note that not
all elements are wrapped by default, so deliberately wrapping the text
inside the msgstr
could lead to an invalid page or a page that is
valid, but is rendered incorrectly by the web browser.
Если вы добрались до этого места, то не исключено, что вы решили взяться за дело всерьёз. Вероятно даже, что вы захотите проверить, как будет выглядеть ваш перевод, перед тем, как его отсылать.
Это сделать не так-то просто, поэтому, хотя все без исключения пункты данного руководства являются факультативными, этот пункт — самый факультативный. Настоящие переводчики сайта 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$