В Пнд, 04/02/2008 в 18:56 +0300, Anton пишет:
> On 2/4/08, Peter Volkov <[EMAIL PROTECTED]> wrote:
> >
> > В Пнд, 04/02/2008 в 15:30 +0300, Anton пишет:
> > > Здравствуйте.
> > >
> > > On 2/4/08, Chaplygin Anton <[EMAIL PROTECTED]> 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
Description: Эта часть сообщения подписана цифровой подписью
