> Полностью согласен - правила нужно сформулировать. Я лично считаю, что > нужно обязательно внедрить нечто вроде службы QA - то есть перед выходом > очередного релиза компонента GNOME его перевод должны просмотреть хотя > бы несколько человек из нас (подписчиков) и изложить замечания > переводчику и сюда. Не знаю как остальные, а я получаю информацию о планирующихся релизах разными путями в том числе на IRC и письмами на личный адрес. Брать на себя ответственность за передачу этой информации в список рассылки я не готов. В лучшем случае о релизе известно за неделю, но обычно -- не больше чем за день. В зависимости от наличия свободного времени либо обновляю перевод и отправляю его в CVS, либо игнорирую надвигающийся релиз. Приоритет (для меня) имеют те программы, релизы которых относительно редки (по очевидным причинам). Тем кто делает дистрибутивы, по большому счёту должно быть всё равно, будет ли перевод к версии X пакета Y закоммичен перед датой релиза или сразу после -- вынули перевод из CVS и в вашем дистрибутиве всё будет в шоколаде (можно даже указывать на это как на дополнительные преимущества дистрибутива по сравнению со "сборкой на коленке из подручных материалов"). А тем кто собирает из CVS и вовсе разницы нет. "просмотреть и изложить замечания" -- это обязанность "проверяющих". Что при этом должны делать "переводчик" и "коммитчик"? "Переводчик" отбрехиваться, а "коммитчик" коммитить то одно, то другое? Некие предложения по поводу "правил". (Далее под явно указанным или предполагаемым "мы" понимаются те настоящие и будущие подписчики этого списка рассылки, которые принимают или намерены принимать участие в переводе GNMOME). 1. Делаем translation memory (например в формате po-файла), в которую загоняем все стандартные сообщения типа тех, которые есть в меню верхних уровней. Пункты меню верхних уровней и их подсказки переводятся в соответствии с этим файлом. В случае если исходный текст подсказки или пункта меню не соответствует правилам (например: для пунктов меню выбор которых приводит к открытию диалога полагается ставить в конце многоточие, его отсутствие -- нарушение правил), соответствующее сообщение отправляется разработчикам программы. Тоже самое в случае обнаружения опечаток или орфографических ошибок в исходном тексте. 2. В случае обнаружения не вызывающих сомнений опечаток, ошибок, несоответствий нашему "стандарту" обнаруживший отправляет патч (или перечень ошибок с достаточным для обнаружения описанием их места) последнему автору перевода и/или в список. В случае наличия доступа и этого перевода в CVS -- коммитит в CVS и извещает в списке. Задача "коммитчиков" -- коммитить исправления и сообщать в список о том, что это сделано. 3. Понятно, что в ряде случаев патч может содержать не только исправления, но и добавления. В случае (заявляемой автором) непротиворечивости добавлений "правилам", такие добавления разрешаются. При этом следует стремиться к единообразию перевода "нестандартных" терминов в пределах программы. (В конце концов изменить одинаково переведённое на другое одинаковое в случае принятия такого решения в соотв. с п.4, будет проще, а в случае сохранения старого термина не придётся приводить к нему сделанный перевод). Собственно эти два пункта описывают обычную практику. 4. Cпоры по поводу перевода того или иного термина. Если кто-либо считает тот или иной перевод неудачным, то сообщает об этом в список (по возможности с мотивацией). Что делать дальше я не знаю. Нам нужна какая-либо процедура позволяющая получить приемлимое решение за короткое время. Знатоки процедурных вопросов -- добро пожаловать. Валек
Attachment:
pgpFbfJapvuMj.pgp
Description: PGP signature