Русский Gentoo

Руководство по переводу

Автор — Алексей Чумаков, 2006-04-30

Надо разделить руководство на два, отделив работу с текстом от работы с инструментами

Введение. Процесс перевода

Перевод документации происходит так: перевод — редактирование — публикация.

После изменения оригинала приходит время для обновления перевода, и цикл повторяется.

Переводчик:

Хороший перевод — когда редактору делать нечего!

Редактор:

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

Это руководство обращается в основном к переводчикам. Но его рекомендации распространяются и на редакторов (отличия помечены как «для редакторов»). Переводчики (с хорошим чувством языка) также могут быть замечательными редакторами для переводов своих коллег.

Содержание. Стиль и особенности перевода

Всем советую прочитать эти материалы:

Авторский стиль

По возможности нужно сохранять стиль авторов, но при необходимости допускаются (иногда — рекомендуются) отступления.

Основаниями для отступлений могут быть: попытка избежать тавтологии, очень частое повторение одного и того же термина (необходимость замены на синоним), невозможность близкого перевода (а может, и неблагозвучность перевода), слишком «тяжелый» или «легкий» стиль автора, невозможность прямо передать национальный или субкультурный колорит и т.д.

Личное обращение и одушевление

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

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

Вместо «ваш, вашего, его» нужно использовать «свой», если в предложении есть обращение: «You can rename this file on your system.» — «В своей системе вы можете переименовать этот файл.».

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

Примеры:

«This page will give you a quick overview» — правильно «На этой странице дается краткий обзор», допустимо «на этой странице вы увидите краткий обзор», недопустимо «эта страница даст вам краткий обзор»): обзор доступен для любого читателя, а не только для вас лично, а страница ничего не дает — дают ее авторы.

«…уou'll find a button»«…кнопка находится», а не «…вы найдете кнопку»: ведь выше не было предложения к читателю «найти кнопку».

При этом не нужно стремиться к лишней строгости и обезличивать все обращения подряд (надо — только пассивные): документ должен оставаться легким, а читатель чувствовать личное внимание. Старайтесь завоевать его расположение!

Отождествление пользователя с его компьютером

Как по-английски, так и по-русски компьютер и его составные части (включая программы) уже считаются «продолжением руки» человека, поэтому иногда отождествляются с ним: «архитектура вашего компьютера» = «ваша архитектура»; «вы подключены к интернету» = «ваш компьютер подключен к интернету». Это допустимо, но в меру!

С большой или с маленькой?

Многие слова, которые в английском пишутся с большой буквы (дни недели, названия языков и т.п.), по-русски грамотно писать с маленькой буквы:

«Friday» — «пятница», «English» — «английский» и т.п.

Обращение на «вы» пишется в руководствах также с маленькой буквы (см. выше).

По-русски — с большой буквы пишутся только имена собственные, а большая буква в заголовке ставится как в предложении:

«Gentoo Operating System»«операционная система Gentoo».

«Automatic Network Detection»«автоматическая настройка сети».

Предложения пишутся с большой буквы. Заголовки — тоже (в них точка не ставится!)

Короткие пункты списков и комментарии в листингах (не являющиеся полным предложением) пишутся с маленькой буквы.

Слово «интернет» — пишется с маленькой буквы, да еще и склоняется: «мы довольны нашим интернетом» — такова поэзия Линукс в эпоху интернета.

Иностранные слова и жаргон

Не надо вставлять английские и другие иноязычные термины без нужды (кроме общеупотребительных или отсутствующих в русском языке). Будьте внимательны при переводе многозначных слов. Можно использовать жаргон применительно к программному обеспечению или культурной среде, главное — чувство меры!

Например: «listing» — «перечень» (о документации), «листинг» или «текст» (об исходном тексте программы), «распечатка». «Юзер» или «девелопер» — нет таких слов, если вы, конечно, переводите не панковский текст наподобие руководства к nano.

Если можно использовать как русское, так и иностранное слово — старайтесь использовать русское: «activation» — «включение» (не «активизация»).

Множественное число слов «сервер», «драйвер» и подобных — «серверы» и «драйверы», а не «сервера» или «драйвера».

Термины, названия команд и сокращения

Названия команд системы в переводе следует указывать по-английски, строго соблюдая исходный регистр (обычно — только строчные буквы), например: «sudo», «dump».

Если английский термин одновременно имеет русский перевод и является названием команды (параметра) или пользователь увидит его на экране по-английски, для сохранения смысла при переводе указывайте исходный термин в скобках: «уровень запуска (runlevel)». При этом русский перевод обязателен! Этот прием можно использовать и в других случаях.

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

Перевод выражений, где часть терминов остается на английском языке, нужно делать так: «Linux partition» — правильно «раздел Linux», допустимо «Linux-раздел», неправильно «Linux раздел», «раздел Linux'а».

Переменная часть названий файлов и переменных, приведенная для примера, переводится: «kernel-[arch]-[version].tgz» — «kernel-[архитектура]-[версия].tgz».

Сочетания клавиш указываются одинаковым способом (даже если в оригинале по-другому). Используется нотация «CTRL+N» (заглавные буквы, соединение — знаком «+»).

Кило-, мега- и гигабайты обозначаются как «КБ», «МБ», «ГБ», двумя заглавными буквами. Килобиты (и прочие подобные) — как «Кбит» (слово «бит» — все строчные буквы).

Листинги

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

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

Существующие комментарии в листингах переводятся.

Лишние слова, времена и строение фразы

Который, это — самые распространенные лишние слова. Такой перевод: «был добавлен этот пользователь, который имеет права администратора» нужно перефразировать: «добавлен новый пользователь с правами администратора».

Если текст кишит словами был и будет, то он переведен не в том времени или ошибочно переведены вспомогательные глаголы. Простое прошлое и будущее время английского языка обычно передается в русском языке так: «There was an error while creating a file» — «[Произошла] ошибка при создании файла»; «Failed to create a window» — «Не удалось создать окно»; «Now we will create...» — «Теперь создадим...».

Порядок слов в предложении и употребление местоимений обычно приходится менять: «We'll need some help while copying over this file.» — «При копировании этого файла нам понадобится помощь.».

Будьте кратки! Хороший русский перевод вопреки распространенному заблуждению не длиннее оригинала: дословный перевод «After you've done this,..»«После того как вы все это проделаете,..», правильный перевод — «Сделав это,..»... Короче вдвое, чем оригинал, и вчетверо, чем дословный перевод!

Надо стараться писать и говорить по-русски, не переводя предложения дословно, а передавая их смысл (для этого полезно начинать перевод предложения, прочитав его до конца). Помогает чтение своего перевода вслух — где споткнетесь, там и «ляп».

Ссылки

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

Текст ссылок переводится. В переводе он склоняется, согласуясь с основным предложением. Название должно совпадать с названием по ссылке; если оно явно неточное, укажите свое и оставьте замечание для редактора.

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

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

Примечания

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

Примечания можно заключать в отдельный блок:

<note>
А в русском выпуске все не так, а вот так! — <e>прим. пер.</e>
</note>

и просто включать в текст в скобках:

...заходите на канал #gentoo сервера irc.freenode.net (на английском языке; русскоязычный ресурс &mdash; форум сайта gentoo.ru. &mdash; <e>прим. пер.</e>)...

Слова «прим. пер.» — обязательны.

Для редакторов: вместо «прим. пер.» используйте «прим. ред.».

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

Имена людей

Имена людей в указаниях авторства или ссылках не переводятся и сохраняются как есть.

В тексте имена упоминаются так:

Имена, написанные латиницей, как правило, не склоняются: правильно светлый путь Eugene, неправильно светлый путь Eugene'а. Ведь не всегда можно гарантировать, что Eugene — не женщина!

Упоминание авторов

Указанный состав авторов, фамилии и адреса электронной почты оставляются как есть и не переводятся.

Названия ролей (отношение участников к материалу) переводятся единообразно:

По-русски названия ролей пишутся со строчной буквы.

В список авторов обязательно нужно добавить себя в роли переводчика.

Для редакторов: указывайте себя в роли редактора перевода.

Оформление текста, пунктуация и типографика

В перечислениях англоязычное многоточие заменяется на родное «и т. д.», а запятая перед «или» не нужна. Тире — часто заменяется на двоеточие в соответствии со строением предложения.

Употребление скобок вида «нужен (опытный) разработчик» и косой черты как в «сделаем красивый/строгий текст» в русском тексте не принято, предложение следует перефразировать (если это не «программизм»).

Указание знаков ™ и ®, которое принято в США, не нужно: они не дают дополнительный защиты прав владельца, не требуются по закону, не приняты и только засоряют русский текст.

В русскоязычном тексте принято использовать русские двойные угловые кавычки («Double angle quotes» — «»), а кавычки пишущей машинки ("") используются только в листингах (где они соответствую конкретной клавише) или вынужденно, при отсутствии нормальных кавычек. В GuideXML двойные угловые кавычки вводятся как &laquo; (левая) и &raquo (правая).

Когда текст выделяется шрифтом или цветом, заключать его в кавычки не надо.

В качестве тире используется длинное (кегельное) тире (Em dash, «—»), а не дефис, причем с пробелами с обеих сторон. Оно же применяется для указания диапазона, например, «10—100 человек», но уже без пробелов. Полукегельное тире (En dash, «–») не употребляется. В GuideXML — &mdash;.

Когда нужно расположить два слова строго на одной и той же строке, используется неразрывный пробел («Non-breakable space»). В GuideXML — &nbsp;. Неразрывный пробел ставится:

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

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

Уточнения и рабочие пометки

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

Советую использовать знак (**) (это — пустой комментарий языка Паскаль, и в мире Linux, Си и Явы он почти не встречается). Рядом с ним я обычно описываю суть возникшего вопроса, например: «partition dump»«сброс дампа (**)резервное копирование??? раздела».

Да простят меня прихожане, Java произносится по-русски как Ява, как небезызвестный остров, названный по имени вкуснейшего сорта кофе, названного в честь этого замечательного языка программирования. Ср. тж.: «Микрософт» (не «Майкрософт»), «Гентý» (не «Дженту»)

После завершения перевода — все такие знаки нужно проверить и удалить (при совместной работе можно временно оставлять нужные пометки, заключая их в комментарий.

Термины и словарь

Добавляйте термины в словарь (предлагайте добавить) сразу, как только в вашу светлую голову пришла гениальная идея по поводу их перевода. А то забудутся!

Что добавлять в словарь? Все термины, над переводом которых вы хоть на минуту задумались.

Форма. Формат файла GuideXML и Метаданные

Формат и структура файла

В документации Gentoo используется строго формат GuideXML, кодировка UTF-8. Начальные байты идентификатора кодировки — недопустимы.

Длина любой строки (кроме служебной отметки CVS и строк без единого пробела) не должна превышать 80 знаков. Разрыв строки служебной отметки CVS, наоборот, не допускается.

Файл должен успешно проходить тестирование командой:

xmllint --valid --noout <имя_файла.xml>

или другим средством проверки xml.

Метаданные исходного документа

Дата и версия оригинала при переводе оставляется без изменений. Если в оригинале дата указана в неверной форме, (должна быть ГГГГ-ММ-ДД), это нужно исправить:

<date>2005-07-21</date>

Автоматическая отметка CVS («$Header...»), если есть, не изменяется переводчиком!

В ссылку на документ включается указание языка, а если в ней указан путь, то /en/ меняется на /ru/. Если пути нет, его надо указать:

<guide link="/doc/en/index.xml">
меняется на
<guide link="/doc/ru/index.xml" lang="ru">

Дополнительные метаданные перевода

Нужно сформулировать предложение по расширению GuideXML и избавиться от нестандартных метаданных перевода.

При переводе мы сталкиваемся со следующим:

Для отражения этого потребовались метаданные, не предусмотренные GuideXML.

Дополнительный блок метаданных перевода вставляется в конец документа в виде XML-комментария. Все строки в блоке должны начинаться с первой колонки (отступы не допускаются). Пример:

<!-- *$Localization:
target-language: Russian
target-version: 2.16-r1
target-date: 2005-04-28
source-cvs-revision: 1.28
translated-by: Alexey Chumakov
edited-by: Vasily Golubev

notes: A reference to Russian typographic conventions is needed here
-->

Поле Назначение
target-language Язык перевода, Russian
target-version

Версия перевода, включающая версию оригинала, 2.16-r1 означает редакцию 1 перевода исходной версии 2.16. Нумерация начинается с 1, указывать редакцию всегда обязательно.

Если в оригинале нет номера версии, нужно указывать известную дату публикации (если есть — дату помещения в CVS) так: 0.0.20050416-r1

При каждом изменении в файле перевода номер редакции увеличивается на 1: 2.16-r2.

При обновлении версии оригинала номер версии обновляется, номер редакции устанавливается в 1: 2.17-r1.

target-date Дата перевода в формате ГГГГ-ММ-ДД: 2005-05-03
source-cvs-revision (необязательно): номер редакции исходного файла в CVS; нужен для систематизации ранее сделанных переводов
translated-by Переводчик (имя и фамилия по-английски), указание обязательно. Имена нескольких переводчиков разделяются запятыми.
edited-by

Текущий редактор перевода (или none). Отсутствие означает, что документу требуется редакторская правка. При обновлении версии сбрасывается на none.

При этом предыдущие редакторы перевода сохраняются в общем списке авторов в соответствующей роли.

notes Рабочие замечания и мысли о недоделанном. По-английски.

Групповая работа: как взять и отдать документ

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

Выбор документа

Посмотрите список состояния переводов.

Выберите документ из списка (желательно — тот, который еще никто не переводил, но если вы хотите обновить перевод, который давно не обновлялся — это тоже отлично, берите!)

Для редакторов: выбирайте переведенный документ с пометкой «для редактирования».

Объявление о начале работы

Просмотрите список открытых запросов Bugzilla.

Убедитесь, что ни один из них не связан с вашим документом.

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

Если есть старые запросы — опирайтесь на список состояния переводов, скорее всего, координатор просто не закрыл их (и не верьте глазам своим!)

Создайте новый запрос в Bugzilla: (вручную — Product=Doc Translations, Component=[RU]).

В поле Summary запроса укажите [ru] имя_файла версия started translation.

Пишите в bugzilla только по-английски (без исключений)!

Так вы дадите другим знать, что начали работу над переводом, а координатору — возможность обновить статус.

Напишите письмо в список рассылки rugentoo:

From: mad_translator
Subj: взял в перевод hb-cray-intro.xml v1.2-r1
http://bugs.gentoo.org/show_bug.cgi?id=150000
//mad translator

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

Получение документов

Исходный английский документ для перевода или сверки загружайте одним из способов:

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

Вопросы коллегам

Пока коллективные (подобные wiki) средства работы не используются. Один текст переводит и редактирует один человек, пока не передаст его другому.

Если вы хотите обсудить варианты перевода слова или фразы, или другой вопрос по переводу — напишите в список рассылки. В теме письма старайтесь указывать название файла (если вопрос по нему) или слово (если вы спрашиваете его значение). По возможности не пишите лично координатору или другим участникам — тема может быть интересна всем. Внимание! Письма в список с неподписанных адресов молча игнорируются! Будьте внимательны.

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

Не надо вставлять в письмо файл с переводом — если есть такая необходимость, опубликуйте его в Bugzilla и укажите ссылку!

Вам обязательно подскажут!

Как выкладывать перевод

Нужно выкладывать в Bugzilla не только окончательную, но и промежуточные версии перевода, если вы хотите их обсудить, или передать работу другому участнику (например, на редактирование). Отредактированный перевод выкладывается так же.

Помещение файла в Bugzilla

Откройте свой запрос на изменение, который вы создали, когда брали документ в перевод или редактирование (если он еще не создан, создайте его).

Если запрос на изменение назван «file… started translation», исправьте название на «file… translated».

Приложите (Create a new attachment) файл с переводом к запросу.

Файлы, которые не соответствуют формату GuideXML, лучше не выкладывать (разве что вы делаете это осознанно, явно указываете на отклонения, и знаете, кто согласился за вами это доделывать)!

Если файл заменяет уже выложенный (например, вы что-то исправили), не создавайте новый запрос: приложите новый файл к тому же запросу, обязательно указав, что предыдущий файл устарел (obsolete)

Если вы дополняете чей-то запрос, и у вас не хватает прав — указывайте все изменения в примечаниях; отразить их в запросе — дело инициатора или координатора.

Всегда указывайте цель запроса или приложения («needs editing», «for publication», «for editing, not for publication» и т.п.) — особых требований нет, но всегда должно быть ясно, что именно надо сделать с вашим материалом!

Поля нужно заполнять так:

Поле Значение
Product Doc Translation (в шаблоне запроса уже заполнено)
Component [RU] (в шаблоне запроса уже заполнено)
Summary Если файл один:
[ru] <имя_файла> <версия> <состояние перевода>
Если файлов несколько:
[ru] описание группы файлов.
Attachment Приложите переведенные файлы:
имя и расширение файла должно соответствовать оригинальному;
формат — text/plain (по словам Xavier Neys, text/xml предназначен для просмотра в браузере, и хотя удобен, не проходит, когда используются сущности типа «&nbsp;»; в формате text/plain, скорее всего, браузер придется переключать из iso-8859-1 в utf-8)
description (описание) — название файла и версия
Comments Все, что стоит знать читателям вашего запроса о файле, его назначении и последующих действиях; все примечания

Сообщение о публикации

Помните, что (пока) о публикации через bugzilla узнает только координатор и зарубежные товарищи. Поэтому, после публикации просто напишите письмо в список рассылки, например:

From: mad_translator
Subj: готов перевод hb-cray-intro.xml v1.2-r1

http://bugs.gentoo.org/show_bug.cgi?id=150000
Надо вычитать и покритиковать, кто возьмется?
//mad translator

или:

From: cool_editor
Subj: отредактирован hb-cray-intro.xml v1.2-r1

http://bugs.gentoo.org/show_bug.cgi?id=150000
Для публикации.
//cool editor

Еще раз: не надо выкладывать непосредственно в рассылку ваши переводы: им место в системе распределения запросов Bugzilla!

Дополнительно: создание файла исправлений — «заплатки»

Инструкция о порядке создания заплатки предоставлена Camille Huot, GDP.

Если по ходу работы вы заметили ошибку в другом или исходном документе, и хотите ее исправить, лучше всего создать заплатку, и опубликовать ее в Bugzilla.

Заплатка (patch) — это специальный файл, в котором перечислены только отличия одного документа от другого.

Ниже дан пример для консоли; в графической среде принцип тот же.

Загрузите исходный файл:
wget http://www.gentoo.org/doc/en/kernel-upgrade.xml?passthru=1 > kernel-upgrade.xml

Создайте копию:
cp kernel-upgrade.xml kernel-upgrade.xml.orig

Исправьте документ:
(ваш любимый редактор) kernel-upgrade.xml

Создайте заплатку (внимание: -Nut обязательно!):
diff -Nut kernel-upgrade.xml.orig kernel-upgrade.xml > kernel-upgrade.xml.patch

Войдите в bugzilla:
http://bugs.gentoo.org/

Создайте новый запрос (для компонента «user documentation») и приложите файл заплатки. При прикреплении файла в bugzilla нужно отметить флажок «patch».

Разработчики Gentoo рассмотрят ее, и если все в порядке, опубликуют.