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

[Peter Volkov]

В Пнд, 04/02/2008 в 18:56 +0300, Anton пишет: 

> On 2/4/08, Peter Volkov <volkov.peter@×××××.com> wrote:
> >
> > В Пнд, 04/02/2008 в 15:30 +0300, Anton пишет:
> > > Здравствуйте.
> > >
> > > On 2/4/08, Chaplygin Anton <ustas@××××××.ru> 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.