Re: [gentoo-doc-ru] Трудности перевода, наша дизорганзация и инфраструктура

[Nav X-ray]

Здравствуйте, 

Я, возможно, вмешиваюсь не в своё дело, поэтому прошу прощения, если кого обижу, Но когда на мой ящик упало с десяток бесполезных писем с Subj., 
у меня возник вопрос: А ЗАЧЕМ ВООЩЕ, ЧТО-ЛИБО ПЕРЕВОДИТЬ? Не лучше ли читать оригинал? Не бесполезен ли вообще весь этот труд.
Мне кажется, (это моё субъективное мнение) Самое важное, чем стоит заняться это написанием нового софта и новой документации, если она нужна и лучше всего на английском языке, дабы она была полезна не только узкому кругу лиц носителей данного языка. 
Для решения ряда проблем мне приходилось читать статьи на немецком и др. языках без знания этих языков, т.к. люди не удосужились поделиться своими знаниями на международном языке, благо язык emerge везде одинаков.

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


-----Original Message-----
From: Peter Volkov <pva@g.o>
To: gentoo-doc-ru <gentoo-doc-ru@l.g.o>
Date: Sat, 02 Feb 2008 23:54:09 +0300
Subject: [gentoo-doc-ru] Трудности перевода, наша дизорганзация и инфраструктура

> Доброе всем время!
>
>
> В связи с появившейся активностью в сообществе gentoo в целом и, в
> частности, в команде gentoo.ru, я решил написать это письмо, в котором
> хотелось бы подытожить свои наблюдения, и высказать мнение, о том, почему
> перевод стоит на месте. Возможно, это позволит не только определить
> проблему, но и подскажет как её решать.
>
> На мой взгляд сейчас у нас две основные трудности: организационная -
> процесс перевода возлагает много на редактора, который один, и
> техническая - место где мы на данный момент хостимся, и то, что мы там
> имеем, не вполне удовлетворяет нашим нуждам.
>
> До сих пор перевод происходил следующим образом: переводчик брал
> оригинал, переводил его и отдавал редактору на редактирование, который
> должен был отредактировать перевод и выложить на сайт. Проблемы при
> таком подходе следующие:
> 1. редактор один
> 2. процесс "затеняет" от переводчика исправленные редактором ошибки -
> редко кто просматривает логи, чтобы узнать, что же изменил редактор
> 3. наличие редактора, в обязанности которого входит выправлять перевод,
> успокаивает переводчика и качество перевода из-за этого снижается, а в
> итоге многие не простые места просто остаются на доперевод редактору
>
> Попытки решить эти проблемы предпринимались, но в итоге уткнулись в
> технические проблемы: наш текущий сайт[1] плохо отражает (совсем не
> отражает) состояние перевода, исправить это там нет возможности, так как
> доступа у меня туда нет, да и стало сложнее предоставлять доступ
> переводчикам к svn-репозиторию  - я так и не получил ответа от voxus'а,
> а его away статус не изменился с августа[2]. На этом всё в очередной раз
> заглохло.
>
> Таким образом, сейчас продолжать переводить как есть большого смысла не
> имеет, до тех пор пока не удастся решить хотя бы часть технических
> проблем, которые, в свою очередь, стоит решать исходя из того, как мы
> хотим организовать нашу работу. Собственно обсудить это и является целью
> этого письма и далее я опишу то, как мне кажется должен быть построен
> процесс перевода, критика которого, конечно, приветствуется.
>
>
> Первое, что мне хочется сделать, это определить перемен^H^H^H^H^H^H^H
> роли. Здесь даже придумывать ничего не надо. В [3] в самом начале в
> разделе "Введение. Процесс перевода" описаны необходимые роли.
> Прервитесь, пожалуйста на минутку, просмотрите первые три абзаца.
>
> Теперь, после того как вы прочитали, мне хотелось бы сразу отметить,
> что, по моему, редактор должен действовать немного по другому. Он не
> должен исправлять перевод, и допереводить то, что переводчик недоделал,
> но должен дать комментарии, что нужно исправить в переводе: какие
> предложения переведены не верно, где за лесом слов пропал смысл,
> отвергнуть перевод с большим количеством орфографических ошибок и т.д.
> Редактор правит только стиль и оставшиеся после, сделанного переводчиком
> spellchecker'а, ошибки. Это вполне соответствует тому, как живут многие
> научные журналы, где сначала рецензент, а потом редактор в случае
> большого количества ошибок обязательно попросит Вас переделать Вашу
> статью. Это очень похоже на то, как повсеместно отклоняются патчи,
> которые не выдержаны в духе остального когда программы (indentation,
> style). Но главное, что такой подход позволит переводчику быстрее
> набрать необходимую квалификацию и вынудит сразу переводить текст, по
> возможности, правильно. Несомненно в таком раскладе должно пройти
> несколько итераций прежде чем редактор пропустит перевод, но результат
> будет лучше и его действительно можно будет публиковать.
>
> То есть я вижу процесс перевода следующим:
>
> переводим();
> while (!редактирование_успешно();)
> 	переводим();
> окончательное_редактирование();
> commit();
>
> Причём я предполагаю, что переводчик задаёт вопросы по поводу сложных
> мест в списке рассылки или в IRC'е. У всех разный уровень знания
> английского языка, и всегда найдутся сложные места. Зато переводчик
> будет действительно человеком, который перевёл текст от и до и, в
> дальнейшем, ему будет проще поддерживать перевод в актуальном состоянии.
>
> Да. У переводов тоже должны быть maintainer'ы - переводчики, которые
> отвечают за поддержание перевода в актуальном состоянии. Если уж вы
> взялись переводить, так поддерживайте перевод, иначе совсем устаревшие
> переводы координатор будет удалять (на самом деле менять ссылку на
> английский вариант, подобно тому, как сейчас нет совсем русского языка
> на страницах gentoo :(). Сильно устаревшие переводы скорее вредны, чем
> полезны, да и политика [4] требует, чтобы переводы были аккуратными.
>
>
> Процесс ясен, но чтобы ему следовать нам нужны инструменты, чем
> переводить, общаться, видеть в каком состоянии находиться перевод
> (перевод, рецензия, доперевод, отрецензирован, готов к публикации) и кто
> отвечает за этот перевод, хранить документ и поддерживать словарь. Думаю
> это основное, что нужно.
>
> Переводить можно любым редактором текста, и лучшего, как известно не
> существует. У всех свои вкусы, мне нравиться vim, gdp предлагают
> попробовать app-editors/xmlcopyeditor. Тут всё боле-менее ясно.
>
> Для общения у нас уже есть список рассылки и IRC и думаю появиться (уже
> есть!) jabber.
>
> Поддержание словарика по моему не тормозит процесс, и обсудить его имеет
> смысле только после того как мы решим оставшиеся две проблемы: как
> следить что и кем переводится, и найти место, куда публиковать
> черновики, переводы, рецензии и готовые к публикации переводы. И именно
> эти две задачи нужно решить прежде, чем мы сможем продолжать
> переводческую деятельность!
>
> =============================================================
> Заметьте:
>
> Чтобы следить что и кем переводиться страницы типа overview [5] или
> лучше trads [6] в том виде как они есть не подходят, так как показывают
> лишь состояние уже переведённого текста? gnome для этого использует
> обычную wiki [7]. Debian использует почту с web интерфейсом [8]. GNU и
> ещё пара проектов также используют обычный список рассылки.
>
> ИМО список рассылки плох тем, что вновь подключившиеся к переводу
> вынуждены искать по рассылке в поисках взял ли кто-нибудь перевод или
> нет и не позволяет увидеть общее состояние перевода, поэтому нужно место
> где отмечаться.
> =============================================================
>
> Были разные идеи, использовать систему управления запросов типа
> bugzilla, trac или mantisbt, и это может быть удобно, учитывая, что
> последние две позволяют связаться с svn, но я пока не вижу как это может
> быть удобнее более простого и понятного в настройке варианта:
>
> каждого переводчика мы регистрируем в ldap и тем самым создаём ему
> account на выделенной для этого машине (а-ля dev.gentoo.org). Этот
> account так же является account'ом для svn в котором мы все храним свои
> переводы. Далее на сервере
> у каждого будет папочка translations в которой будут подкаталоги:
> draft
> translated
> edited
> ... и так далее в соответствии со статусом перевода.
>
> Как только переводчик берёт что-нибудь на перевод он кладёт doc.xml в
> папочку draft. Это удобно. Мастера консоли легко овладеют командой scp,
> а любители GUI заценят протокол fish:// в kde или winscp в windows,
> позволяющие простым переносом файла переместить файл на сервер. Далее на
> сервере настраивается скрипт, который прочёсывает каталоги и формирует
> страничку с отчётом, кто-чем сейчас занимается и в случае изменений
> будет создавать письмо в рассылку.
>
> Как только перевод завершён переводчик переносит файл в translated,
> откуда редактор забирает его, на редактирование (перекладывает к себе в
> translated). И так далее.
>
> Так же скрипт можно научить тривиальный тест файла (xmllint --valid и
> diff с репозиторием и в случае изменения файла, обновлять документ
> (вернее делать запрос на обновление, реальный коммит должен делать
> человек...) в snv-репозитории и тем самым отгородит переводчиков от svn,
> при этом сохранив его для тех, кому дорога история коммит.
>
> Такую настройку можно сделать достаточно просто, позволяет действительно
> видеть сколько нас и кто-что делает, и в случае необходимости, ничто не
> мешает нам подцепить к тому же ldap систему тикетов/wiki и подобное,
> если потребуется.
>
> Можно ли с помощью trac/bugzilla сделать что-нибудь более удобное? Что
> команда gentoo.ru думает по этому поводу? Сейчас, пока Архимед на
> реконструкции, самое время такое спланировать и сделать.
>
>
> Уфф. Теперь критиковать! :)
>
>
> Ссылки:
> [1] rugentoo.org
> [2] http://www.gentoo.org/proj/en/devrel/roll-call/devaway.xml?select=voxus#voxus
> [3] http://www.rugentoo.org/technology/translators-howto.html
> [4] http://www.gentoo.org/proj/en/gdp/doc/translators-howto.xml#doc_chap3
> [5] http://www.gentoo.org/doc/ru/overview.xml
> [6] http://gentoo.neysx.org/mystuff/trads/doc/trads-doc.xml
>     пример использования: http://www.gentoo.de/trads/
> [7] http://gnome.org.ru/wacko/CurrentTasks
> [8] http://ddtp.debian.net/ddtss/index.cgi/xx
>
>
> С наилучшими пожеланиями,
> --
> Peter.
> ATTACHMENT: application/pgp-signature (signature.asc)
>