1 |
В Пнд, 04/02/2008 в 18:56 +0300, Anton пишет:
|
2 |
> On 2/4/08, Peter Volkov <volkov.peter@×××××.com> wrote: |
3 |
> > |
4 |
> > В Пнд, 04/02/2008 в 15:30 +0300, Anton пишет: |
5 |
> > > Здравствуйте. |
6 |
> > > |
7 |
> > > On 2/4/08, Chaplygin Anton <ustas@××××××.ru> wrote: |
8 |
> > > > 2. Договариваемся, что начиная работу над переводом переводчик просто |
9 |
> > > > изменяет статус тикета в системе Trac на "assigned". Для того, чтобы |
10 |
> > > > псмотреть, кто чем занимается, достаточно будет посмотреть на |
11 |
> > > > стандартный отчет {9} (вот пример: http://trac.edgewall.org/report/ |
12 |
> > > > 9). Соответственно координатору, конечно, придется создавать эти |
13 |
> > > > тикеты - это минус, но, с другой стороны, зато ему будет проще |
14 |
> > > > отслеживать по отчетам общую динамику работы команды переводчиков без |
15 |
> > > > необходимости пальцем считать файлы в каталогах - это большой плюс, |
16 |
> > > > который, imho, покрывает все минусы. |
17 |
> > > |
18 |
> > > Согласен с Антоном, использование trac в этом случае более естественно |
19 |
> > > и позволит избежать многих костылей. |
20 |
> > |
21 |
> > Наличие trac не избегает того, что сам по себе он может быть ещё одним |
22 |
> > костылём. |
23 |
> |
24 |
> Я пока не вижу более удобного способа организации работы. |
25 |
> Используя trac очень удобно брать текст на перевод, достаточно взять |
26 |
> на себя соответствующий тикет и кто угодно, в любой момент времени, |
27 |
> может посмотреть кто занимается данным переводом. Если в публикации |
28 |
> перевода было отказано, можно легко установить причину, просто |
29 |
> посмотрев комментарии к тикету. Уведомить проверяющего о окончании |
30 |
> перевода так же не составит труда переноправив тикет ему. Да, придется |
31 |
> запускать браузер, но я не вижу как иначе мы получим всю информацию в |
32 |
> одном месте. |
33 |
|
34 |
Всё-таки хотите трак? Возможно ли решить в нём наши задачи, о которых я
|
35 |
писал в других письмах, хотя бы внешний API, для автоматизации хотя бы
|
36 |
некоторых процессов? Я не против, но решение должно исходить не из
|
37 |
предпочтений, а из того, что лучше нам подойдёт.
|
38 |
|
39 |
> > > > --3-- |
40 |
> > > > В очередной (не помню уже какой по счету) раз озвучу схему работы с |
41 |
> > > > резпозиториями, которую я предлагаю. |
42 |
> > > > |
43 |
> > > > В данной схеме выделяется 3 основных цикла: |
44 |
> > > > 1. Цикл подготовки подстрочных переводов. Участвуют все желающие, |
45 |
> > > > имеющие доступ к репзиторию (Community Translators или CT). |
46 |
> > > > Повторяется пока кто-нибудь из переводчиков, стоящих на втором |
47 |
> > > > уровне, не возьмет подстрочник в работу. |
48 |
> > > |
49 |
> > > Мне кажется это правильный подход к орагнизации нашей деятельности. Я |
50 |
> > > думаю многие хотят просто попробовать свои силы в переводе, но не |
51 |
> > > готовы к ответственности. В этом случае деление на CT и Translator |
52 |
> > > выглядит разумно. |
53 |
> > |
54 |
> > Это можно оставить, но нужно ли? Не лучше ль сразу помочь человеку стать |
55 |
> > переводчиком указывая ему на его ошибки перевода? |
56 |
> |
57 |
> Возможно. Я не против это обсуждать. |
58 |
|
59 |
Я думаю нет смысла разделять переводчиков на "совсем плохих" и
|
60 |
"получше". Пусть уровень у всех разный, но это лишь должно влиять на
|
61 |
количество итераций между редактором и переводчиком и всё!
|
62 |
|
63 |
> > Антон говорил, что руководства не нужны. А порог, сейчас вообще нулевой |
64 |
> > и никто никогда не говорил о повышении порога. Было бы желание, а |
65 |
> > желание пропадает, если нет отдачи... |
66 |
> |
67 |
> Порог сейчас далеко не нулевой, так как нет инфраструктуры. |
68 |
> Желания так же прибавится когда человек увидит что о нем уже |
69 |
> позаботились. Сделали для него удобное starting guide. Показали как с |
70 |
> этим работать и как организовать свою работу. |
71 |
> |
72 |
> > > , о том как |
73 |
> > > помочь сообществу с переводами. Помимо перевода документации и GMN, |
74 |
> > > включим в работу перевод небольших заметок для новостей, чтоб новичкам |
75 |
> > > было на чем тренироваться. |
76 |
> > |
77 |
> > Эти новости публикуются на заглавной странице сайта. Очень плохое место |
78 |
> > для тренировок... |
79 |
> > |
80 |
> |
81 |
> Редактора никто не отменял, но из-за "срочности" перевода и маленького |
82 |
> объема текста человек может "просто попробывать". Это как игра. Он за |
83 |
> полчаса получает свою фамилию с благодарностью (как переводчика) на |
84 |
> первой странице gentoo.ru, это хорошо мотивирует и дает возможность |
85 |
> втянуться в работу, а потом и переводить документацию. |
86 |
|
87 |
Как раз наоборот. Срочность перевода не означает, что на нём нужно
|
88 |
тренироваться, а значит, что за него должны браться люди, которые
|
89 |
уверены в своих силах/времени - то есть, те, кто уже переводил и знают,
|
90 |
что это такое.
|
91 |
|
92 |
А чтобы втягивать, лучше может быть легко брать в команду переводчиков,
|
93 |
делать отчёты о том, кто-что сделал за месяц, давать клоаки в irc'е и
|
94 |
почту на gentoo.ru.
|
95 |
|
96 |
> > > Для меня неясным остается вопрос реализации взаимопомощи и |
97 |
> > > консультаций переводчиков. Наверно, использовать для этого комментарии |
98 |
> > > к тикетам trac'а не удобно, так лучшим выбором станет список рассылки. |
99 |
> > |
100 |
> > Самое удобное ИМО это комментарий в тексте: |
101 |
> > <!-- EDITOR: текст --> |
102 |
> > |
103 |
> > А переводчик читает исправляет убирает... |
104 |
> > |
105 |
> > И вот именно, trac и здесь не способствует. Когда мы до этого его |
106 |
> > обсуждали я думал, что там можно сделать вещи, упомянутые в ответе |
107 |
> > Антону. Сейчас я не вижу как это удобно сделать, поэтому ищу реализуемые |
108 |
> > альтернативы... |
109 |
> |
110 |
> Я писал о взаимопомощи и консультаций переводчиков подразумевая |
111 |
> вопросы типа: "Как лучше перевести ****?". Для этого ставить |
112 |
> комментарии в тексте не удобно и именно для этого я предлагал список |
113 |
> рассылки. |
114 |
|
115 |
Да, конечно. Я подразумевал, что редактор говорит то-то и то-то не
|
116 |
правильно, а переводчик, если сам не знает как переводить, спрашивает
|
117 |
список рассылки.
|
118 |
|
119 |
> Говоря об исправлении перевода или указании на ошибки перевода можно |
120 |
> использовать и тег <!-- EDITOR: текст -->, и просто заменив, например, |
121 |
> неверный оборот в тексте. Все исправления вытягиваются trac из SVN в |
122 |
> очень наглядной форме (см. например |
123 |
> http://trac.edgewall.org/changeset/6425/trunk/contrib/bugzilla2trac.py ). |
124 |
|
125 |
Да, отлично!
|
126 |
|
127 |
> > > Имеющийся список терминов (http://rugentoo.org/glossary/index.html) |
128 |
> > > логичней перевести в wiki (как и остальную документацию) на основе, |
129 |
> > > например, того же trac. |
130 |
> > |
131 |
> > ИМО, главная проблема словарика - он не должен быть частью нашего |
132 |
> > маленького проекта. Пока мне кажется логичней сделать его частью engcom |
133 |
> > и подцеплять в stardict. ebuild написать не сложно ... Проблема с engcom |
134 |
> > лишь в том, что сейчас не ясно как найти людей за него отвечающих, но я, |
135 |
> > пока, не сдался :) И об этом потом... Впрочем, как запасной вариант, |
136 |
> > можно сделать частью wiktionary... Но надо поисследовать этот вариант |
137 |
> > тоже... |
138 |
> |
139 |
> Мне всё-таки кажется что удобней хотя бы на первой стадии сформировать |
140 |
> и обкатать свой вариант. Возможно некоторые переводы не приживуться |
141 |
> или изменятся. Будут вносится правки. Я не знаю сколько времени |
142 |
> занимает внесение правки в engcom, но в wiki это быстрей и можно |
143 |
> видеть всю историю обсуждений. Я не против того чтобы отдать его "в |
144 |
> народ", напротив, я "за". Но и иметь свой рабочий словарик тоже не |
145 |
> помешает. |
146 |
> |
147 |
> -- |
148 |
> aluk |
149 |
|
150 |
Потом, когда слов будет штук 600, кто будет их копировать из нашей wiki
|
151 |
в другую? Уверен это будет ад, а поэтому лучше сразу делать эти вещи на
|
152 |
более широкую ногу. Потом опять же, wiki хранит хистори, как нам её не
|
153 |
потерять?
|
154 |
|
155 |
--
|
156 |
Peter. |