Трудности перевода, наша дизорганзация и инфраструктура

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Трудности перевода, наша дизорганзация и инфраструктура

pva0xd
Доброе всем время!


В связи с появившейся активностью в сообществе 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.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Трудности перевода, наша дизорганзация и инфраструктура

pva0xd
К сожалению убедить всех в команде gentoo.ru отвечать в этот список
рассылки мне не удалось, но я получил разрешение пересылать ответы сюда,
сохраняя всё цитирование. Это мой ответ Антону, на его ответ мне.

==========================================================================


В Пнд, 04/02/2008 в 09:45 +0300, Chaplygin Anton пишет:
> > Друзья, это обещанная во время митинга затравка для обсуждения проблем
> > перевода. Так как я уверен, что обсуждение будет интересно всем, в том
> > числе потенциальным переводчикам, прошу отвечать в gentoo-doc-ru, куда
> > это же письмо было отправлено минуту назад. Спасибо.
>
>
> --1--
> Ох, слишком много букаф. Асилил с трудом и то со второго раза.  

Ух. А первый абзац осилить видимо вообще не получилось. :(
Придётся мне форвардить ибо не хочу терять историю. Я её иногда
просматриваю...

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

Антон, я овлёк тебя от перевода? Хм, не уверен, и когда перевод в
очередной раз зачах, мне думается стоит оглянуться и попробовать понять
почему это произошло. Это поможет избежать этих проблем в будующем...

> Не стоит забывать, что все мы - люди, а не машины, и способны  
> воспринимать информвцию только сравнительно небольшими квантами,

Квант это сколько строчек? Сколько раз мне надо будет написать, чтобы
освятить всё то, что я написал? В конце концов, если нет времени
прочитать несколько страниц текста, то не удивительно, что мы ещё ничего
не сделали. Очевидно что, процесс работы не всегда только fun и нужны
усилия. Было бы желание осилить всё можно.

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

Вопрос, а сколько из существующих ссылок в конце письма ты открыл?

> Не стоит обязывать  
> переводчиков читать мануал полностью, не не удивляться, если они не  
> будут этого делать.

Где я писал про обязывание переводчиков?

> Просто, отвечая на вопрос, будем давать ссылку, и  
> постепенно человек будет вникать в процесс, допуская все меньше и  
> меньше недочетов, и, что очень важно, предоставляя нам очень важную  
> обратную связь насчет орагнизации процесса переводов, коммуникации и пр.

Этого никто не отменял.

> То же самое касается и писем!
>
> Я понимаю стремление руководителей и координаторов по возможности  
> максимально формализовать процесс, сделать его логичным и исключить  
> возможность ошибиться. Но в проектах с нематериальной мотивацией, тем  
> более, если команда географически распределенная, эта склонность  
> может сильно навредить, потому что не у всех есть лишний час времени  
> на чтение пространных руководств о том, как надо помогать проекту.

Где я писал про пространные руководства? То есть стоит обязывать
редакторов раз по сто писать одно и тоже, чем один раз написать как что
делать и направлять переводчиков туда читать? Пример из жизни: у вас в
рассылке лежит несколько неотвеченных писем потенциальных переводчиков.
Им даже не послали ссылку :(

> Мы должны быть благодарны даже за одну строку переведенного текста,

Зависит от того, это перевод или ручной аналог prompt'а.

>  даже  
> если этот перевод сделан не совсем в соответствии с требуемым стилем.

Я писал, что за стиль отвечает (если хочет) редактор, но не переводчик.
Опять не понимаю, к чему это написано...

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


> --2--
> Не понимаю, зачем отгораживать переводчиков от SVN-репозитория

Зачем знать svn переводчику? Разве знание svn помогает переводить? Мне
писали переводчики, которые вообще не слышали такого слова. Значит мы
хотим, чтобы переводчики не читали документ о том, как переводить, но
разобрались с svn? На что лучше направить усилия переводчиков?

> создавать ненужный шаг в цикле - для SVN'а есть куча неплохих  
> клиентов с GUI и без, с которыми справится любой человек с головой.
> Для того, чтобы отслеживать, кто чем занимается, можно использовать  
> одну из 2 схем:
> 1. Папки draft, translated и т.п. можно создать прямо в репозитории.  
> Переводчик делает checkout, потом средствами SVN переносит файл в  
> папку соответствующего статуса и делает commit.

Ок. Но опять же изучать svn? И кто будет писать к нему хуки, что бы не
было одного и того же файла в двух папочках одновременно? Но, наверное,
это можно сделать. Я поэкспериментирую.

> 2. Договариваемся, что начиная работу над переводом переводчик просто  
> изменяет статус тикета в системе Trac на "assigned". Для того, чтобы  
> псмотреть, кто чем занимается, достаточно будет посмотреть на  
> стандартный отчет {9} (вот пример: http://trac.edgewall.org/report/ 

То есть, кроме работы над переводом мы заставляем ещё открыть браузер и
изменить статус (см. ниже(*))?

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

Хм, похоже действительно осилить несколько страниц текста это ад... Я
там упоминал скрипт, который написать легко и он будет составлять
отчёты, чтобы не считать пальцем...

> - это большой плюс, который, imho, покрывает все минусы.

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

(*) Но ты не понял главной проблемы! Нам нужно видеть не что уже
переведено, а что в процессе перевода. Редко кто писал в рассылку письмо
о том, что взял то-то или то-то на перевод, так почему ты думаешь, что
кто-то будет в траке менять статус? Когда я говорил про связь svn и
$issue_tracker я понимал, что коммитом, я смогу закрывать/менять
состояние тикета. Это можно сделать в trak? Я не нашёл и поэтому ищу
другой путь.

> Мне второй вариант видится более простым для всех. Посмотрел я  
> Mantisbt (я им не пользовался, но о нем слышал), но скажу честно, что  
> меня он совсем не впечатлил. Если есть желание посмотрите на систему  
> http://unfuddle.com -  это коммерческий аналог системы Trac, но  
> большинство функций (например, контроль времени на закрытие тикетов,  
> иерархическое связываение тикетов и т.п.) доступно и в Trac'е, если  
> повозиться с хаками и модулями. Лучшей в смысле удобства системы я  
> пока не видел - даже аккаунт там купил.

Ок. Если мы начинаем обсуждать багзилы, то первое, что нужно решить это
возможно ли не открывать браузер всякий раз, когда я закоммитил, изменил
что-нибудь? Как? (опять же см. выше (*))

> --3--
> В очередной (не помню уже какой по счету) раз озвучу схему работы с  
> резпозиториями, которую я предлагаю.

Схема не единственная проблема. Эта схема упирается в технические
проблемы и именно поэтому моё письмо получилось длинным.

> В данной схеме выделяется 3 основных цикла:
> 1. Цикл подготовки подстрочных переводов. Участвуют все желающие,  
> имеющие доступ к репзиторию (Community Translators или CT).  
> Повторяется пока кто-нибудь из переводчиков, стоящих на втором  
> уровне, не возьмет подстрочник в работу.

Как говорил Азамат, и я с ним согласен: "отсутствие видимого результата
- главный дестимулирующий фактор." Поэтому думаю повторение циклов
подстрочников быстро остановиться. Другое подтверждение этому факту сайт
it.kondopoga.ru.

> 2. Во втором цикле участвует переводчик (Translator) и один из  
> ответственных за качество и стилистику (назову эту группу QA -  
> Quality Assurance). QA может отправлять текст переводчику на  
> доработку, скажем, до 5 раз (через svn-репозиторий, делая пометки и  
> замечания в соответствующем тикете). После того, как перевод принят,  
> он поступает к координатору (Coordinator - C).
> 3. 3-й цикл охватывает весь процесс, и за него отвечает координатор.  
> Данный цикл состоит из коммитов переводов в официальный репозиторий  
> Gentoo.org, выкладывания в наш репозиторий новых и обновленых  
> англоязычных текстов для работы CT и создания тикетов.
Если убрать тикеты, чем он отличается от того, что я предлагал?

> Таким образом у нас получается 4 уровня ответственности (каждый тикет  
> проходит через все 4 уровня):
> 1. На самом верху стоит координатор проекта переводов на русский  
> язык, на котором лежит весь груз ответственности. В его обязанности  
> входит общение с руководством межунароной команды переводов, решение  
> нестандартных проблем, работа с QA (ибо они - его щит и опора).
> 2. QA - команда из 2-3 человек, которая отвечает за качество  
> переводов. Они же будут заниматься составлением и актуализацией  
> словарей терминов, FAQ' а и контроллировать процесс.
> 3. Переводчики - занимаются переводами текстов в полном объеме, на  
> основе подстрочников, подготовленных CT. Взаимодействуют с QA.
> 4. CT - молодняк и неофиты,
Лучше избегать таких слов. Думаю, не всем потенциальным переводчикам
будет приятно слышать про себя такое от умудрённого гуру...

>  которые занимаются подстрочниками, учатся  
> работать с SVN (если не умеют) и т.п.

Антон. Подстрочник не нужен ибо править подстрочник сложно. Правя
handbook и GWN'ы я много раз ловил себя на том, что удалить абзац
перевода и перевести заново значительно проще, чем пользоваться
переводом. Да это даже был не подстрочник. А вот яркий пример
подстрочников это сайт Banderazzz'а. Ну что делать с теми кусками
текста? Очевидно, заново переделывать.

> Систему продвижения вверх по лестнице уровней ответственностей,  
> думаю, стоит построить на основе рекомендаций. Например, координатор  
> чувствует, что QA-группа не справляется, и если для решения проблемы  
> нужны кадры, то он просит у QA порекомендовать кого-нибудь из  
> переводчиков (1-2 кандидатуры, скажем). Естественно, для QA клавным  
> критерием будет то, насколько просто было с переводчиком работать:  
> если переводчик присылал почти идеальные тексты, то у его шансы  
> сильно возрастают. Решение о переводе в QA принимает координатор.  
> Аналогично с переводчиками: переводчики рекомендуют QA особо  
> отличившихся из CT (тех, чей подстрочник был максимально точен и  
> близок к готовому переводу). Решение о изменении статуса CT->T  
> приниают QA коллегиально. Кто-то из них становится супервайзером  
> нового переводчика (т.е. с ним работает только он) и по истечении  
> определенного срока, отчитывается перед остальными QA, можно ли этому  
> переводчику доверять или, иными словами, прошел ли он испытательный  
> срок.
Пока нас мало и кого продвигать будет видно.

> Такой подход позволит:
> 1. сделать систему продвижения понятной и прозрачной для всех - это  
> большой плюс к мотивации:
> 2. четко распределить зоны ответственности и избежать самодурства;
> 2. все кадровые решения будут приниматься на основе оценки полезности  
> человека: от кого много проблем, продвигаться не сможет, а те, кто  
> проблемы помогает решать или хотя бы их не создает, будет  
> продвигаться быстро.
>
> Если есть вопросы, то готов на них ответить.
Да, и много. Выше по тексту :)

Peter.


signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Трудности перевода, наша дизорганзация и инфраструктура

pva0xd
В Пнд, 04/02/2008 в 15:30 +0300, Anton пишет:

> Здравствуйте.
>
> On 2/4/08, Chaplygin Anton <[hidden email]> wrote:
> > 2. Договариваемся, что начиная работу над переводом переводчик просто
> > изменяет статус тикета в системе Trac на "assigned". Для того, чтобы
> > псмотреть, кто чем занимается, достаточно будет посмотреть на
> > стандартный отчет {9} (вот пример: http://trac.edgewall.org/report/
> > 9). Соответственно координатору, конечно, придется создавать эти
> > тикеты - это минус, но, с другой стороны, зато ему будет проще
> > отслеживать по отчетам общую динамику работы команды переводчиков без
> > необходимости пальцем считать файлы в каталогах - это большой плюс,
> > который, imho, покрывает все минусы.
>
> Согласен с Антоном, использование trac в этом случае более естественно
> и позволит избежать многих костылей.
Наличие trac не избегает того, что сам по себе он может быть ещё одним
костылём.

> > --3--
> > В очередной (не помню уже какой по счету) раз озвучу схему работы с
> > резпозиториями, которую я предлагаю.
> >
> > В данной схеме выделяется 3 основных цикла:
> > 1. Цикл подготовки подстрочных переводов. Участвуют все желающие,
> > имеющие доступ к репзиторию (Community Translators или CT).
> > Повторяется пока кто-нибудь из переводчиков, стоящих на втором
> > уровне, не возьмет подстрочник в работу.
>
> Мне кажется это правильный подход к орагнизации нашей деятельности. Я
> думаю многие хотят просто попробовать свои силы в переводе, но не
> готовы к ответственности. В этом случае деление на CT и Translator
> выглядит разумно.
Это можно оставить, но нужно ли? Не лучше ль сразу помочь человеку стать
переводчиком указывая ему на его ошибки перевода?

> > 4. CT - молодняк и неофиты, которые занимаются подстрочниками, учатся
> > работать с SVN (если не умеют) и т.п.
> >
>
> Порог вхождения в CT разумно сделать довольно низким. Написать
> небольшое howto с обзором программ (и картинками! :) )

Антон говорил, что руководства не нужны. А порог, сейчас вообще нулевой
и никто никогда не говорил о повышении порога. Было бы желание, а
желание пропадает, если нет отдачи...

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

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

> Для меня неясным остается вопрос реализации взаимопомощи и
> консультаций переводчиков. Наверно, использовать для этого комментарии
> к тикетам trac'а не удобно, так лучшим выбором станет список рассылки.

Самое удобное ИМО это комментарий в тексте:
<!-- EDITOR: текст -->

А переводчик читает исправляет убирает...

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

> Имеющийся список терминов (http://rugentoo.org/glossary/index.html)
> логичней перевести в wiki (как и остальную документацию) на основе,
> например, того же trac.

ИМО, главная проблема словарика - он не должен быть частью нашего
маленького проекта. Пока мне кажется логичней сделать его частью engcom
и подцеплять в stardict. ebuild написать не сложно ... Проблема с engcom
лишь в том, что сейчас не ясно как найти людей за него отвечающих, но я,
пока, не сдался :) И об этом потом... Впрочем, как запасной вариант,
можно сделать частью wiktionary... Но надо поисследовать этот вариант
тоже...

--
Peter.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Трудности перевода, наша дизорганзация и инфраструктура

pva0xd
В Пнд, 04/02/2008 в 17:54 +0500, Azamat Hackimov пишет:
> Эту техническую подробность попрошу осветить отдельно. Сможет ли trac
> удовлетворить потребности как команды gentoo.ru, так и переводчиков?
>
> Давайте накидаем, что нам нужно от проект менеджера!

Именно поэтому я начал с того, как организовать переводчиков. Исходить
нужно из того, чтобы этот проект менедежр давал то что нужно и не больше
того, что нужно. Лишние элементы интерфейса лишь отвлекают тех, кто
хочет присоединиться к проекту. Можно ли его "заточить" под нашу
структуру?

> Вот мое видение:
>
> Объективные требования, данные свыше и которые нужны обеим ветвям:
>
> - поддержка ldap
> - поддержка системы запросов a-la bugzilla

Зачем? Отслеживать переводы? Как это удобно? Это добавляет следующие
проблемы:
* нужно открыть баг, чтобы видеть что не переведно (и дублирует
overview.xml)
* нужно открыть браузер и изменить статус, чтобы показать, что перевод
взят, не верю, что это будут делать ибо две строчки в рассылку проще, но
и этого не делали
* нужно закоммитеть и в нагрузку изменить статус бага

и так для каждого документа. Вот это действительно сложно, особенно для
тех, кто никогда не работал с багзилой...

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

> - wiki-система

Для чего? Можно конечно решить все документы gentoo.ru в неё оформить,
но нужно ли? Разве это тормозит развитие статической составляющие сайта?
Разве удобно к wiki приделывать скрипты для автоматизации сбора нужной
нам информации, типа состояние переводов?

> Требования для команды g.ru:
> - поддержка svn

сам по себе он мало решает

> - почтовая служба

без неё никуда... любой web требует почты.

> Требования от переводчиков:
> - среда для обсуждения переводов

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

> - среда для контроля свежести документов

overview.xml
trads, может быть лучше, но он не решает дополнительных проблем поэтому
нужен ли он?

> Возможно что-то я упустил, дополните меня. Прошу также высказать свои
> предложения по конкретным платформам, которые будут точно
> удовлетворять Объективным требованиям. В идеале - какой-нибудь
> groupware с уклоном для разработчиков.

> Просто я хочу сказать, давайте сделаем мудрую и взвешенную платформу,
> а не в стиле "давайте возьмем то-то, а потом когда-нибудь приделаем
> все остальное"

Именно. Я не против web'а если он будет удобным. А удобным это и значит
то что нужно и быстро. Сделать веб быстрым очень и очень сложно. Кроме
того нужно чтобы и браузер быстро создавал страницу и не тормозил, а
firefox-2 как известно тормоз, и значит нужны альтернативные клиенты к
web'у. Какие? Или мы уберём всё что тормозит из веб'а? И ещё одно. web
очень плох тем у кого модемы.

--
Peter.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Трудности перевода, наша дизорганзация и инфраструктура

pva0xd
В Пнд, 04/02/2008 в 17:16 +0300, Anton пишет:

> > Объективные требования, данные свыше и которые нужны обеим ветвям:
> >
> > - поддержка ldap
> > - поддержка системы запросов a-la bugzilla
> > - wiki-система
>
> Trac вроде всё это поддерживает. LDAP - через плагин
> (http://trac-hacks.org/wiki/LdapPlugin).
>
> > Требования для команды g.ru:
> > - поддержка svn
> > - почтовая служба
>
> Поддержка SVN через trac имеется (пример -
> http://trac.edgewall.org/browser/). Почтовая служба? Не совсем понимаю
> о чем именно идет речь. Если о возможности отправлять друг-другу
> e-mail, то возможно предоставление ящика на gentoo.ru c ldap
> интеграцией.
>
> > Требования от переводчиков:
> > - среда для обсуждения переводов
> > - среда для контроля свежести документов
>
> Обсуждение переводов. Я так понимаю что речь идет о коментариях
> проверяющего перевод, о его просьбах что-то исправить или поменять.
> Мне этот процес видится следующим образом:
>
> 1. Переводчик завершивший перевод направляет его вверх по цепочке, -
> проверяющему (делает reassign в терминах trac).
> 2. Проверяющий (QA) видит что у него появился новый тикет, смотрит
> перевод и далее возможны варианты:
> - принимает перевод, вносит свои коррективы и отправляет  "вверх"
> координатору (опять reassign);
> - либо отклоняет перевод, пишет в комментарии к тикету причину и то
> что нужно исправить, и переназначает тикет обратно переводчику.
> 3. Если перевод отклонен, переводчик опять увидит у себя этот тикет со
> статусом open, прочитает комментарий и продолжит работу.
Ок. Где здесь CT? Они как работают?

> Среда для контроля свежести перевода. Я пока не знаю как
> автоматизировать этот пункт. Возможно есть возможность получать время
> последней правки с gentoo.org (например через SVN) и сравнивать с
> датой в нашем SVN.

В trac'е есть какой-нибудь внешний API? Номер тикета можно засунуть в
перевод, сравнение версий (а именно на них нужно смотреть) сделать не
сложно...

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

В matisbt есть MantisConnect, который вроде может помочь в
автоматизации. Но я пока не изучал это.

--
Peter.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Трудности перевода, наша дизорганзация и инфраструктура

pva0xd
In reply to this post by pva0xd
On 2/4/08, Dmitri Varenov <[hidden email]> wrote:

> > Добрый день, господа...
> >
> > Вот читаю, читаю я ваши письма и думаю а как же быть с самым основным
> > вопросом - кадрами...
> >
> > Предложена система в 4 уровня (СТ, Т, QA, С). процесс "повышений" должностей
> > тоже продуман.
> >
> > Но вот только где нам даже на первое время найти людей для организации сразу
> > 4х ступеней?
> >
> > Помнится за тот год что мы переводили GWN активно этим занимались не более
> > 3-4 человек (включая Антона (Aluk'a)).
> >
> > --
> > Dmitri  'Barrell' Varenov
В Пнд, 04/02/2008 в 19:06 +0300, Anton пишет:

> Дима, привет.
>
> Я тоже думал об этом. Но потом вспомнил сколько появлялось желающих
> попробовать себя после публикации призывов на gentoo.ru. Желающие
> были, но мы их всех потеряли из-за неорганизованности процесса.
>
> Рассчитывать на то что в команде будут работать 4 человека было бы
> ошибкой. Тогда не надо ничего городить, не надо инфраструктуры. 4
> челдовека "по мылу" договорятся.
>
> Вернее делать из расчета на широкий круг переводчиков с разной
> подготовкой, только так может получится что-то стоящее. Только так к
> нам будут приходить новые люди. А там, кто знает, может этот процесс
> захлеснет десятки (сотни!) человек? :)
>
> --
> aluk
Лично мне не верится что будут сотни человек. Я практически уверен, что
в лучшие времена будет 10 активных человек. Но это не отменяет
необходимости в единой инфраструктуре, где в одном месте будет, что
переводить, кто переводит и в каком состоянии мы находимся...

Основное зачем мы определяем роли это, чтобы "заточить" наши
инфраструктуру под процессы, которые будут в ней происходить. Это как
ООП сначала определяют объекты и дествия ;)

Помимо этого ничто не мешает одному человеку занимать две и более роли.
Роль скорее определяет желания, активность и знания человека, нежели
возможности. Каждый может получить доступ к дереву gentoo.org, для этого
лишь нужно разобраться в документации и пройти некоторые quiz'ы. Далее,
чтобы редактировать, нужно знать лексику и стиль нашего проекта, что
можно узнать, лишь переводя и получая инструкции от редакторов и так
далее. Но ничто не мешает переводчику взять и поредактировать, вот
только знает ли переводчик на что стоит обратить внимание?

--
Peter.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Трудности перевода, наша дизорганзация и инфраструктура

pva0xd
In reply to this post by pva0xd
В Пнд, 04/02/2008 в 18:56 +0300, Anton пишет:

> On 2/4/08, Peter Volkov <[hidden email]> wrote:
> >
> > В Пнд, 04/02/2008 в 15:30 +0300, Anton пишет:
> > > Здравствуйте.
> > >
> > > On 2/4/08, Chaplygin Anton <[hidden email]> wrote:
> > > > 2. Договариваемся, что начиная работу над переводом переводчик просто
> > > > изменяет статус тикета в системе Trac на "assigned". Для того, чтобы
> > > > псмотреть, кто чем занимается, достаточно будет посмотреть на
> > > > стандартный отчет {9} (вот пример: http://trac.edgewall.org/report/
> > > > 9). Соответственно координатору, конечно, придется создавать эти
> > > > тикеты - это минус, но, с другой стороны, зато ему будет проще
> > > > отслеживать по отчетам общую динамику работы команды переводчиков без
> > > > необходимости пальцем считать файлы в каталогах - это большой плюс,
> > > > который, imho, покрывает все минусы.
> > >
> > > Согласен с Антоном, использование trac в этом случае более естественно
> > > и позволит избежать многих костылей.
> >
> > Наличие trac не избегает того, что сам по себе он может быть ещё одним
> > костылём.
>
> Я пока не вижу более удобного способа организации работы.
> Используя trac очень удобно брать текст на перевод, достаточно взять
> на себя соответствующий тикет и кто угодно, в любой момент времени,
> может посмотреть кто занимается данным переводом. Если в публикации
> перевода было отказано, можно легко установить причину, просто
> посмотрев комментарии к тикету. Уведомить проверяющего о окончании
> перевода так же не составит труда переноправив тикет ему. Да, придется
> запускать браузер, но я не вижу как иначе мы получим всю информацию в
> одном месте.
Всё-таки хотите трак? Возможно ли решить в нём наши задачи, о которых я
писал в других письмах, хотя бы внешний API, для автоматизации хотя бы
некоторых процессов? Я не против, но решение должно исходить не из
предпочтений, а из того, что лучше нам подойдёт.

> > > > --3--
> > > > В очередной (не помню уже какой по счету) раз озвучу схему работы с
> > > > резпозиториями, которую я предлагаю.
> > > >
> > > > В данной схеме выделяется 3 основных цикла:
> > > > 1. Цикл подготовки подстрочных переводов. Участвуют все желающие,
> > > > имеющие доступ к репзиторию (Community Translators или CT).
> > > > Повторяется пока кто-нибудь из переводчиков, стоящих на втором
> > > > уровне, не возьмет подстрочник в работу.
> > >
> > > Мне кажется это правильный подход к орагнизации нашей деятельности. Я
> > > думаю многие хотят просто попробовать свои силы в переводе, но не
> > > готовы к ответственности. В этом случае деление на CT и Translator
> > > выглядит разумно.
> >
> > Это можно оставить, но нужно ли? Не лучше ль сразу помочь человеку стать
> > переводчиком указывая ему на его ошибки перевода?
>
> Возможно. Я не против это обсуждать.
Я думаю нет смысла разделять переводчиков на "совсем плохих" и
"получше". Пусть уровень у всех разный, но это лишь должно влиять на
количество итераций между редактором и переводчиком и всё!

> > Антон говорил, что руководства не нужны. А порог, сейчас вообще нулевой
> > и никто никогда не говорил о повышении порога. Было бы желание, а
> > желание пропадает, если нет отдачи...
>
> Порог сейчас далеко не нулевой, так как нет инфраструктуры.
>  Желания так же прибавится когда человек увидит что о нем уже
> позаботились. Сделали для него удобное starting guide. Показали как с
> этим работать и как организовать свою работу.
>
> > > , о том как
> > > помочь сообществу с переводами. Помимо перевода документации и GMN,
> > > включим в работу перевод небольших заметок для новостей, чтоб новичкам
> > > было на чем тренироваться.
> >
> > Эти новости публикуются на заглавной странице сайта. Очень плохое место
> > для тренировок...
> >
>
> Редактора никто не отменял, но из-за "срочности" перевода и маленького
> объема текста человек может "просто попробывать". Это как игра. Он за
> полчаса получает свою фамилию с благодарностью (как переводчика) на
> первой странице gentoo.ru, это хорошо мотивирует и дает возможность
> втянуться в работу, а потом и переводить документацию.
Как раз наоборот. Срочность перевода не означает, что на нём нужно
тренироваться, а значит, что за него должны браться люди, которые
уверены в своих силах/времени - то есть, те, кто уже переводил и знают,
что это такое.

А чтобы втягивать, лучше может быть легко брать в команду переводчиков,
делать отчёты о том, кто-что сделал за месяц, давать клоаки в irc'е и
почту на gentoo.ru.

> > > Для меня неясным остается вопрос реализации взаимопомощи и
> > > консультаций переводчиков. Наверно, использовать для этого комментарии
> > > к тикетам trac'а не удобно, так лучшим выбором станет список рассылки.
> >
> > Самое удобное ИМО это комментарий в тексте:
> > <!-- EDITOR: текст -->
> >
> > А переводчик читает исправляет убирает...
> >
> > И вот именно, trac и здесь не способствует. Когда мы до этого его
> > обсуждали я думал, что там можно сделать вещи, упомянутые в ответе
> > Антону. Сейчас я не вижу как это удобно сделать, поэтому ищу реализуемые
> > альтернативы...
>
> Я писал о взаимопомощи и консультаций переводчиков подразумевая
> вопросы типа: "Как лучше перевести ****?". Для этого ставить
> комментарии в тексте не удобно и именно для этого я предлагал список
> рассылки.
Да, конечно. Я подразумевал, что редактор говорит то-то и то-то не
правильно, а переводчик, если сам не знает как переводить, спрашивает
список рассылки.

> Говоря об исправлении перевода или указании на ошибки перевода можно
> использовать и тег <!-- EDITOR: текст -->, и просто заменив, например,
> неверный оборот в тексте. Все исправления вытягиваются trac из SVN в
> очень наглядной форме (см. например
> http://trac.edgewall.org/changeset/6425/trunk/contrib/bugzilla2trac.py ).

Да, отлично!

> > > Имеющийся список терминов (http://rugentoo.org/glossary/index.html)
> > > логичней перевести в wiki (как и остальную документацию) на основе,
> > > например, того же trac.
> >
> > ИМО, главная проблема словарика - он не должен быть частью нашего
> > маленького проекта. Пока мне кажется логичней сделать его частью engcom
> > и подцеплять в stardict. ebuild написать не сложно ... Проблема с engcom
> > лишь в том, что сейчас не ясно как найти людей за него отвечающих, но я,
> > пока, не сдался :) И об этом потом... Впрочем, как запасной вариант,
> > можно сделать частью wiktionary... Но надо поисследовать этот вариант
> > тоже...
>
> Мне всё-таки кажется что удобней хотя бы на первой стадии сформировать
> и обкатать свой вариант. Возможно некоторые переводы не приживуться
> или изменятся. Будут вносится правки. Я не знаю сколько времени
> занимает внесение правки в engcom, но в wiki это быстрей и можно
> видеть всю историю обсуждений. Я не против того чтобы отдать его "в
> народ", напротив, я "за". Но и иметь свой рабочий словарик тоже не
> помешает.
>
> --
> aluk
Потом, когда слов будет штук 600, кто будет их копировать из нашей wiki
в другую? Уверен это будет ад, а поэтому лучше сразу делать эти вещи на
более широкую ногу. Потом опять же, wiki хранит хистори, как нам её не
потерять?

--
Peter.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Трудности перевода, наша дизорганзация и инфраструктура

pva0xd
In reply to this post by pva0xd

В Пнд, 04/02/2008 в 19:05 +0300, Chaplygin Anton пишет:
> > Последний вопрос ко всем ответившим. Есть ли возражения, если я, как и
> > хотел, буду форвардить свои ответы с цитированием ваших ответов
> > gentoo-doc-ru?
>
> Я лично непротив. Но у меня складывается ощущение, что у нас как-то  
> неконструктивно получается - ты очень напорист, имхо, и считаешь, что  
> знаешь все лучше всех.

Если я написал по сути что не так, так прошу придраться к словам. Зачем
переходить на личности?

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

Именно, но

> В целом по технике между  
> нами противоречий нет - есть нюансы, но дьявол как раз в мелочах.

Именно. И поэтому я пытаюсь прежде, чем начать, что-нибудь делать
описать всё и как можно подробнее. А в итоге оказывается, что прочитать
"много букаф" сложно. Так как добиться концептуального понимания?

> Пока то, о чем ты говоришь, очень сильно напоминает подход Алексея  
> Чумакова - так все обстоятельно, правильно, систематично и объемно.  
> Но как народ не бился, результатов особых не получилось достичь, если  
> я не ошибаюсь.

Ошибаешься. Посмотри, всё что переведено на сайте было переведено в его
время, а это очень не мало. Это 150 документов... И это не считая
GWN'ов, а страниц сайта.

> У меня сложилось ощущение, что все было достигнуто  
> какими-то нереальными усилиями.

Что удалось достичь с другим подходом? Про нереальные усилия ниже.

> И построить самоподдерживающийся процесс не удалось.

Вот тут не соглашусь. Я не верю и не видел документации которая сама по
себе обновлялась и поэтому "самоподдерживающийся" процесс не возможен -
это делают люди! Можно лишь сделать процесс более удобным для людей:
более прозрачным, более понятным, менее подверженным ошибкам. Можно
ввести в процесс элементы взаимопомощи, чтобы отказ редактора коммитеть
был не как снег на голову переводчику, а явным элементом системы и вид
отказа должен быть тоже понятным. Можно не пытаться сделать всё в одном,
как это пытался сделать Алексей, а ограничиться одной целью - перевод
документации gentoo.org и только когда эта цель будет достигнута,
ставить новые...

А по поводу нереальных усилий. Алексей хотел начав с перевода gentoo
сделать проект по переводу всего и делающий кроме перевода ещё кучу
всего. Поизучай сайт rugentoo.org. Там находятся очень удивительные и
интересные идеи. И конечно, такая цель требует нереальных усилий...

Кстати совсем процесс перевода зарубил я :( По разным причинам. Например
Алексей ушёл и я был вынужден в 80% случаев разбираться по логам, что
долго, и до последнего момента я находил новые вещи. Документы по
переводу никак не систематизированы и дублируют друг друга. И самое
главное, я оказался не в силах редактировать всё, что нужно, и хотя на
призыв о помощи откликнулись люди, за что им огромное СПАСИБО, мне не
удалось их подключить к переводу по техническим причинам.

> Ты говоришь, что подстрочник не нужен, а я не могу с этим  
> согласиться, потому что мое предложение как раз и строится на  
> противоречии между качеством перевода и возможностью постоянной  
> подкачки команды свежими силами.

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

> Я уверен, что среди сотни товарищей,  
> которые делают промто-подобные переводы найдется 1-2 человека,  
> которые возмьмут и сделают качественный подстрочник, потому что им  
> будет хотеться получить дополнительный статус в сообщесте или просто  
> потому что они предпочитают делать работу, за которую берутся,  
> хорошо.. С другой стороны, у них не будет психологического барьера из-
> за боязни что-то не так перевести, ошибиться и быть осмеянными  
> "небожителями" с высокими правами доступа и самомнением, мешающего  
> оперативно закоммитить пусть не идеальный, но перевод, который сможет  
> подхватить более опытный переводчик, сказав "Круто! Тут совсем чуть-
> чуть осталось!"
Говорить нужно правду. А психологический барьер ИМО можно разрушить
больше общаясь с переводчиками. Создавая сообщения о том, что сделано,
как делалось, и, в частности, не уводя все обсуждения в закрытый список
рассылки и не используя слова типа "молодняк и неофиты" ;)

> Я уверен, что современем между переводчиками и теми,  
> кто делает хорошие подстрочники, установятся более-менее  
> доверительные отношения, переводчики начнут делать ценные замечания  
> или просить что-то доделать, чтобы перевод пошел дальше. Самые  
> разумные начнут растить себе замену.

Нет, это нужно делать сразу. Зачем это откладывать на потом, в чём
преимущество? Как человек поймёт, что он делает ошибки, если ему об этом
не говорить? Посмотри, ошибок и стало меньше и качестов ebuild'ов
действительно выросло, как только QA команда стала бороться с ошибками и
ещё лушче, когда делаются обзоры реальных ошибок в gentoo-dev.

Тоже самое с редакторами. Я вообще иногда думаю, что указывать на ошибки
стоит прямо в gentoo-doc-ru. Тогда другие переводчики смогут учиться на
чужих ошибках. Это нормально когда есть ошибки, хуже когда на них
настаивают и не исправляют. Впрочем можно сделать раздел "работа над
ошибками" в сообщении о состоянии проекта.

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

Я тоже :)

> К тому же Open Source - это  
> тоже в некотором смыле утопия, в который мы все участвуем и  
> пользуемся ее плодами. Короче, я настаивать на своем предложении не  
> стану - решайте сами.

Open Source работает - это не утопия :P

> --
> Best regards,
> Chaplygin Anton
> Leading coordinator
> Russian Gentoo Linux Community
> http://gentoo.ru

Антон, ты сам сказал, что суть наших разногласий в мелочах. Так укажи
конкретно, с чем ты не согласен? Ответь, пожалуйста, на конкретно
поднятые вопросы а не общим письмом обо всём.

--
Peter.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Трудности перевода, наша дизорганзация и инфраструктура

pva0xd
В Втр, 05/02/2008 в 00:19 +0300, Vadim Efimov пишет:
> я вот тоже боюсь что-то переводить так как я не переводчик, но читая
> местами переводы на русский мне хочется что-то поправить, хотя я и не
> собираюсь становиться переводчиком - кто знает что будет дальше...

Править это замечательно! И это то, что нужно. Почему не открыть по
этому поводу баг, на gentoo.org или просто написать мне? Это уже
законченные переводы и поэтому такие исправления довольно просто
сделать.

> поэтому подход с подстрочниками мне с первого взляда нравиться.

Чем? Вы будете их делать? Почему с помощью редактора не довести его до
перевода?

> Темболее их будут читать люди которые тоже не настолько крутые как я
> понимаю в переводах - а тот кому проще заново перевести будет ещё выше
> и читать их небудет...

> P.S. про успешность предидущего подхода говорит то что Алексея
> Чумакова убрали из девелоперов за неактивность...

У него семья, дети и работа и времени не осталось ;) Что в этом такого?
У каждого может такое случиться...


--
Peter.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Трудности перевода, наша дизорганзация и инфраструктура

navX
In reply to this post by pva0xd
Здравствуйте,

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

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


-----Original Message-----
From: Peter Volkov <[hidden email]>
To: gentoo-doc-ru <[hidden email]>
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)
>

Reply | Threaded
Open this post in threaded view
|

Re: Трудности перевода,наша дизорганзация и инфраструктура

Горлов М.В.
В сообщении от 5 февраля 2008 Nav X-ray написал(a):

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

Честно говоря, согласен.
имхо лучше не переводить, а писать свою документацию. Решили проблему - написали статью, решили проблему - написали статью....
А еще лучше (если есть возможность) назначить какое-ть вознаграждение за статьи (не за перевод)
Reply | Threaded
Open this post in threaded view
|

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

Be UNIX
05.02.08, [hidden email] <[hidden email]> написал(а):
А еще лучше (если есть возможность) назначить какое-ть вознаграждение за статьи (не за перевод)

Где Вы предлагаете брать вознаграждение? У сообщества достаточно финансовых средств для этого?

Reply | Threaded
Open this post in threaded view
|

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

ANA-22
In reply to this post by navX
>> Я, возможно, вмешиваюсь не в своё дело, поэтому прошу прощения, если кого обижу, Но когда на мой ящик упало с десяток бесполезных
>> писем с Subj.,
>> у меня возник вопрос: А ЗАЧЕМ ВООЩЕ, ЧТО-ЛИБО ПЕРЕВОДИТЬ? Не лучше ли читать оригинал? Не бесполезен ли вообще весь этот труд.

>Честно говоря, согласен.
>имхо лучше не переводить, а писать свою документацию. Решили проблему - написали статью, решили проблему - написали статью....
>А еще лучше (если есть возможность) назначить какое-ть вознаграждение за статьи (не за перевод)

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

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


Reply | Threaded
Open this post in threaded view
|

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

Be UNIX
In reply to this post by navX
05.02.08, Nav X-ray <[hidden email]> написал(а):
Здравствуйте,

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

Я, возможно, вмешиваюсь не в своё дело, поэтому прошу прощения, если кого обижу, Но когда на мой ящик упало с десяток бесполезных писем с Subj.,

Возможно, Вам кажется бесполезными не письма, а то, что с их помощью пытаются сделать?

у меня возник вопрос: А ЗАЧЕМ ВООЩЕ, ЧТО-ЛИБО ПЕРЕВОДИТЬ? Не лучше ли читать оригинал? Не бесполезен ли вообще весь этот труд.

У линукса (генту, в частности) есть русскоязычная публика. Не у всех, кто составляет эту публику, есть достаточные знания английского языка, возможность, способность или желание его изучать. Но среди этих людей есть люди, работающие с линуксом (генту), использующие его или желающие начать делать первое или второе. Наличие документации на русском языке _помогает_ этим людям работать с ним, использовать его и изучать его. Одним из эффектов этого является его большее распространение. Поскольку линукс (генту) и сопутствующее ему (программное обеспечение, форумы, документация, проблемы) приносит с _собой_ культуру свободного программного обеспечения, то если Вы — сторонник философии свободного ПО, Вас не может не волновать эта сторона вопроса.
Таким образом, я вижу два аргумента за то, что перевод документации — небесполезное занятие: 1) помощь людям, по тем или иным причинам не знающим английский язык, и 2) распространение идей и самого свободного ПО. Если ни один из аргументов Вам не подходит — что ж, это Ваш выбор.

Мне кажется, (это моё субъективное мнение) Самое важное, чем стоит заняться это написанием нового софта и новой документации, если она нужна и лучше всего на английском языке, дабы она была полезна не только узкому кругу лиц носителей данного языка.

Без сомнения, создание нового свободного ПО, улучшение уже существующего и написание документации для широкого использования являются важными задачами. И если у вас есть возможность и желание этим заниматься — это замечательно. Но, опять же, не все пользователи в достаточной мере владеют искусством (ремеслом) программирования или написания документации, не у всех есть желание или возможность это делать. Но некоторые из них хотят внести посильный вклад в общее дело и те, у кого есть возможность и желание заниматься переводом, делают это с помощью переводов.
Одним из эффектов переводов документации, как я уже отмечал, является более широкое распространение свободного ПО. Это в свою очередь проводит к тому что, появляется большее количество людей, желающих участвовать в том, что Вы предлагали: в создании свободного ПО и написании документации к нему.

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

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

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

Похоже, в течение этого продолжительного периода рассылка была скорее мертва, чем жива.

--be

Reply | Threaded
Open this post in threaded view
|

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

navX
In reply to this post by ANA-22
Возможно, если перевод актуален, то его проще читать на родном языке, но, к сожалению, а может и к счастью, практика показывает, что переводы бесполезны, когда они устарели.

Reply | Threaded
Open this post in threaded view
|

Re: Трудности перевода, наша дизорганзация и инфраструктура

pva0xd
In reply to this post by navX
Доброе время.

В Втр, 05/02/2008 в 22:10 +0600, Nav X-ray пишет:
> Я, возможно, вмешиваюсь не в своё дело, поэтому прошу прощения, если
> кого обижу, Но когда на мой ящик упало с десяток бесполезных писем с
> Subj.,
> у меня возник вопрос: А ЗАЧЕМ ВООЩЕ, ЧТО-ЛИБО ПЕРЕВОДИТЬ?

Вы просто подписались на не правильный список рассылки. ;)

gentoo-doc-ru - Russian Gentoo Documentation Translation List

>  Не лучше ли читать оригинал? Не бесполезен ли вообще весь этот труд.

Нет. Не смотря, что уже лет 5 я читаю большую часть информации на
английском языке, живя в русскоязычной среде мне всё равно проще
воспринимать русский текст. Поищите в google. Уверен, что вам удастся
найти и какие-нибудь психологический исследования на эту тему. Кроме
того, вам уже писали, но повторю, что есть люди, которые просто не знают
язык...

> Мне кажется, (это моё субъективное мнение) Самое важное, чем стоит
> заняться это написанием нового софта и новой документации, если она
> нужна и лучше всего на английском языке, дабы она была полезна не
> только узкому кругу лиц носителей данного языка.

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

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

Её никто не получал, потому что в неё никто не писал.

--
Peter.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

pva0xd
In reply to this post by navX
В Срд, 06/02/2008 в 14:39 +0600, Nav X-ray пишет:
> Возможно, если перевод актуален, то его проще читать на родном языке,
> но, к сожалению, а может и к счастью, практика показывает, что
> переводы бесполезны, когда они устарели.

Именно поэтому ссылки на русскоязычную документацию на сайте gentoo.org
удалены. Наша цель - исправить положение.

--
Peter.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Инякин Александр
Не знаю, кому как, но я потратил не зря два часа, прочитав внимательно эту рассылку, поэтому тоже хочу поделиться своими мыслями и идеями. =)

Сначала мысли и возражения.

1. Переводы НУЖНЫ! В не зависимости от того, владеет конечный потребитель английскими или нет. Даже если он знает английский язык в совершенстве и читает Шекспира в подленнике, скорее всего, сидя в туалете он размышлет о смысле жизни
все-таки на русском, поскольку этот язык впитан с молоком матери.

2. С иерархией и обязанностями переводчиков и редакторов более или менее понятно. Тут мало что можно добавить. Действительно, роль редактора - указать не неточности и ошибки. Роль переводчика - их исправить, но с ОБЯЗАТЕЛЬНЫМ участием редакторов, чтобы исправление ошибок не превратилось в "футбол" с пинанием перевода туда-сюда, пока переводчик все-таки не догадается, что же от него хочет редактор. С другой стороны редактор должен владеть английским очень хорошо, иначе проверка соответствия перевода оригиналу может затянуться на период, гораздо больший, чем сам перевод...

3. Организация порядка и правил работы тоже необходимы. Думать, что 2-4 человека договорятся как-нибудь сами может и верно, но четкие правила работы - это уже на 70% процентов удачно сделанная работа. Это утверждение можно встретить в любой книге по разработке программного обеспечения и оно работает. Перевод документов в этом смысле мало чем отличается. Причем правила будут эффективны и при наличии 2 человек, и при 20. А вот "как-нибудь сами" во втором случае уже не сработает.


4. Теперь по поводу выполнения "этих самых правил". "Хочу-не хочу, буду-не буду" можно говорить, когда ты работаешь один, но если ты присоединяешься к группе, то установленные правила выполнять необходимо. Это про требования к людям, которые проявят желание присоединится к проекту. Поэтому, если человеку лениво отправить письмо в рассылку о взятом переводе, запостить баг на багзилле о статусе документа или сменить этот статус в траке, то может его и не стоит брать? Зачем, если эту работу за него придется делать другим? Может тогда переводом документа займется кто-нибудь, кто уже в группе? Пусть и по позже. Почитайте, например, требования для желающих переводить man-ы. Фиг вас возьмут, пока не сдадите мини-экзамен. И тем не менне манам это переводиться не мешает.

5. По поводу системы слежения за переводами. Может я конечно и не прав, но у меня сложилось впечатление, что выбор системы превратился в поиск панацеи от всех проблем, чтобы человек только переводил, а все остальное за него делала система. Извините, но так не бывает. Волшебную палочку еще не изобрели. Поэтому необходимо понять, что можно поручить системе, а что должен все-таки делать человек.
Системе можно доверить сбор статистики, хранение истории изменений, отслеживаение статуся и прочие рутинные автоматизируемые операции. А вот принятие решений должен делать человек. Никаких изменений статуса или тикета при commit быть не должно! Решать, когда документ получит тот или иной статус должен только человек, хочется нам этого или нет. Поэтому ситуация когда кто-то не может/не умеет/боиться поправима, можно объяснить, показать, научить. А если не хочет, то на этот случай я уже высказал мнение. Здесь можно только сделать, чтобы эта операция занимала не 10 минут в багзилле (как у меня было в свое время =), а один-два щелчка мышью.

Честно говоря, я не знаком с системами bugzilla и trak с точки зрения возможностей и принципов работы, но я неплохо знаком с svn и у меня есть несколько идей, как это можно реализовать здесь. Плюс ко всему svn имеет свой API, через который, видимо, можно будет сделать то, что не получится просто через командную строку.
Это к тому, что у меня не только слова, но и возможность решения конкретной проблемы. Щас уточню некоторые моменты по svn и выложу свою идею.

P.S.
Силь не пинать.
Reply | Threaded
Open this post in threaded view
|

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

Anatoly Arzhnikov
Всем привет.

К сожалению мой опыт работы с системами типа Bugzilla или Trac слишком мал, чтобы что либо советовать. Но если удасться решить эти вопросы, буду рад возобновить работу, это все, что я хочу сказать :)

P.S. На bugs.gentoo.ru до сих пор лежат 1 или 2 моих перевода, которые никто не отредактировал и соотв. не опубликовал...
Reply | Threaded
Open this post in threaded view
|

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

Дмитрий Лапин
Доброе время суток!

Есть мысль по поводу оформления переводов:

При чтении переведенных документов часто возникает проблема следующего характера - переводы терминов часто далеки от того, каким этот перевод представляет человек, читающий документ. Т.е. не всем и не всегда легко понять что, например сценарий загрузки и init script это одно и то же, при чем init script, если читатель хоть немного понимает английский (=хоть иногда читает документация на английском), он встречал скорее всего чаще. Половину проблемы решает использование "словарика" т.е. документа, в котором указано как нужно правильно переводить термины. Но только половину - нельзя же заставить человека, читающего документация держать открытым рядом "словарик". Может быть стоит ввести какой-нибудь специальный тэг, который бы позволял получить информация о термине - например <translation for="init script">сценарий загрузки</translation>. Отрабатывать этот тэг может по-разному - нужно подумать как лучше, например он может вставлять ссылку на описание термина, в котором будет присутствовать английский вариант термина, либо выделять перевод термина каким-либо образом (спец. подчеркивание и т.д.), а оригинальный термин (англоязычный) вставлять атрибутом title, т.е. в сгенерированном html-е это может быть как <span title="init script" class="translation">сценарий загрузки</span>. Вариантов реализации можно придумать довольно много...