[oo-translation] OOo Translation guidelines

Alexej Kryukov akrioukov на newmail.ru
Чт Апр 15 18:58:00 MSD 2004


По совету дока рискую перенести сюда разговор,
начатый мною в oo-dicuss и высказать еще раз свои
соображения, навеянные просмотром статистики.

Итак, работа над переводом идет 4 месяца. За это время
всеми переводчиками в совокупности было переведено или
исправлено около 2,5 тыс. строк из общего количества
в 26 тыс. Фактически количество много меньше, т. к. 
учитываются и повторные обращения к той же строке, а
их при серьезной работе будет более половины. Согласно
той же статистике количество reviewed strings составляет
около 3%. Соответственно, простой подсчет показывает,
что при сохранении этих темпов работа завершится не
ранее 2014 года, и это при том немыслимом условии,
что OOo за это время не претерпит изменений.

Мне могут возразить, что задача заключалась в исправлении
ошибок перевода, и большинство из них действительно исправлено.
Это так, но есть еще и общая корявость старого перевода с
точки зрения русского языка. И как только мы начинаем ее
править (а не делать этого невозможно), то перевод в целом
утрачивает то единство стиля, которое ему до этого было хоть
в какой-то степени свойственно. Конечно, если мы меняем перевод
какого-то определенного термина, то элементарное правило
заключается в том, чтобы добиваться его стандартизации по
всей базе. Но это не всегда возможно. Скажем, переводилось 
всюду Default как "Стандарт" -- плохое, но единообразие.
Теперь мы меняем этот перевод на подходящий по контексту.
Поиском по базе это сделать невозможно: мало ли чего найдется
на "Default", и далеко не всегда надо это передавать как
"По умолчанию". Вывод простой: пока редакторы не просмотрят
*весь* интерфейс OOo, о стабильности полученного перевода
говорить нельзя.

Следовательно, необходима резкая интенсификация работы
над переводом. Вопрос, как этого добиться? Вот мои предложения:

1. Необходимо разделение усилий. Нужно уходить от сегодняшней
ситуации, когда каждый переводит то, что хочет, и ни перед
кем не отчитывается. Для этого следует разделить весь объем
оставшейся работы на блоки: в основном, конечно, исходя
из категории group, но не беда, если будут и отступления,
т. к. удобнее всё-таки идти от интерфейса OOo, а не от базы.
Скажем, все диалоги Writer, все диалоги автопилотов и т. д.

Каждый блок должен быть персонально закреплен за одним из
редакторов, чтобы исключить дублирование усилий. Естественно,
следует приложить усилия к тому, чтобы все они были закрыты.
Скажем, есть ли в команде хоть один человек, активно 
работающий с Impress? Если нет, то там даже элементарные
глюки могут остаться незамеченными, не говоря уж о том, чтобы
всё это как-то еще и отредактировать.

2. В рамках каждого блока имеет смысл определить список
приоритетов. Например, если какой-то диалог используется
чаще других, то и править его следует в первую очередь.

3. Следует активнее использовать связку переводчик - редактор.
Скажем, один человек проходит по диалогу и только расставляет
акселераторы, ничего не меняя в самом переводе, после чего
рапортует в рассылку: мол, такой-то диалог закончен, редактора
просим приступать. А поскольку эта работа, так сказать,
"неквалифицированная", то на нее наверняка было бы сравнительно 
несложно найти людей. Ибо сдается мне, что половина переводчиков у 
нас фактически бездействует не от недостатка времени, а от того, что 
не знает, с чего начать (как и я некоторое время назад). Ну а 
после того, как акселераторы расставлены, редактор может делать 
свое дело вполовину быстрее.

4. Нужно как-то решать вопрос с теми строками, которые всё еще
не переведены. Сейчас их свыше 4000 или 16%, т. е. согласно той 
же статистике перевести их полностью можно будет к концу этого
года, если заниматься только этим (но именно этим сейчас 
целенаправленно не занимается никто, судя по тому, что количество
не уменьшается).

Из этих строк, конечно, 90% приходится на компонент officecfg,
т. е. простому пользователю они не видны. Но вот человек, занимающийся
разработкой, именно из-за этих строк русскую версию предпочтет не
ставить, т. к. с файлами *.properties крайне неприятно работать,
когда они содержат жуткую англо-русскую кашу (а русский перевод
в большинстве случаев никуда не годится). Кстати, русские строки
в UTF-8 в данном случае неудобны, т. к. не всегда есть под рукой
юникодовый редактор. Вопрос: может быть, откажемся от перевода
данного компонента, а существующий всюду забьем исходным английским?
Количество непереведенных строк резко упадет.

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

6. И, наконец, самая сложная задача -- выработка общего глоссария.
В идеале это должно было бы выглядеть как еще один web-интерфейс,
куда каждый мог бы заносить три поля: английский термин, русский
перевод и комментарий. Плюс опять же зеленая галочка, которую
можно было бы поставить, чтобы отличить предложения отдельных
переводчиков от того, что уже одобрено общим решением. Скажем,
обсудили некий термин в рассылке -- занесли в глоссарий.

Вот такие предложения. Прошу прощения, если немного сгустил краски,
но, мне кажется, при такой серьезной работе всегда надо исходить
из наихудших предположений ;-)




Подробная информация о списке рассылки Translation