Локализация, часть 4: Толпой

На одном из последних конференций Localization World наклюнулась было панель по community localization, но тут же рассосалась: из 25 присутствовавших локализационных фирм никто на эту модную тему ничего внятного сказать не смог. Ведущая выборочно ткнула в Arturo Quintero (это одиозная фигура, такой Жириновский от локализации – то в аэропорту с конкурентом подерется, то выступит так, что его потом на всех углах цитируют), я даже видеокамеру включил. Но лихой мексиканский хлопец бормотал не в лад и невпопад.
Я этой темой немного интересовался, так что изложу… Коротенько.

Для явления есть красивое слово: crowdsourcing, означающая примерно “изготовление толпой”. Популярная в последние два-три года идея community translation (“перевод [силами] сообщества”): модели по образу и подобию опенсорса, где локализация осуществлялась бы безвозмездно (“то есть, даром” (с) ) отдельными переводчиками или группами энтузиастов. Явление в природе существует и в большинстве случаев выражается в отдельных небольших любительских переводах постов и новостей. Это было бы туда-сюда, но есть несколько проектов, будоражащих умы и не дающих остыть интересу к community localization:

• Google использовал модель для переводов софта на языки третьей группы (проекты в 12-15 тысяч слов).
• Sun Microsystems придерживается модели для бесплатного перевода документации. На самом деле им это и правда неплохо удается.
• Facebook community localization. Это, собственно, то, что не дает теме засохнуть: перевод Facebook на 20 языков, включая русский, выполнен энтузиастами. Facebook заявляет, что еще 43 языка – в процессе.

Такая модель в пределе при всей кажущейся финансовой притягательности на самом деле малопригодна для коммерческого применения по двум причинам:

1.       Общее настроение, выраженное одним из корейских переводчиков Wikipedia:

“Wikipedia – явление альтруистическое, добровольное, поддерживаемое пожертвованиями, приводящее к распространению информации, Facebook – его прямая противоположность. Поэтому люди не должны тратить свое время и энергию, поддерживая многомиллионную корпорацию, чтобы она на этом заработала еще больше миллионов. Во всяком случае, перевод не должен выполняться даром.”

Это – распространенное (и IMHO весьма справедливое) мнение, и оно тактически является существенным препятствием на пути коммерческих проектов.

2.       Крайне низкое качество перевода. Бесплатные переводы, выполненные для Google, были чудовищными: качество перевода на ~60% языков было ниже принятых стандартов, ~20% языков содержало оскорбительные или неполиткорректные переводы. Если хочется испортить себе репутацию, то crowdsourcing коммерческих продуктов очень быстро приведет к цели.

С другой стороны, community-based модель неплохо работают для open source software (OSS) в небольших/средних небюджетных проектах: там и ожидания занижены, и объемы небольшие (никаких миллионов слов перевода, как, скажем, у Adobe или Sybase). Как я писал, по статистике типичные опенсорсные проекты – небольшие, с одним-двумя разработчиками и незначительным воздествием на рынок. Большинство опенсорсных проектов никогда не локализаются на другие языки. По локализованным продуктам данные примерно такие:

1.       Число слов в большинстве опенсорсных локализационных проектов не превышает 15 тысяч слов. Пример типичного проекта: Mojiti (1117 фраз).
2.       Есть единичные крупные долгосрочные локализационные проекты (большая часть связана с Линуксом).
3.       Подавляющее большинство переводчиков (более 95%), участвующих в долгосрочных проектах, переводят менее 10 тысяч слов на человека. Единичные переводчики отрабатывают 20-30 тысяч слов. Встречаются данные о людях, на счету которых 50-150 тысяч слов (встретившийся рекордсмен в этом деле, кстати, русский: может быть, он не умеет считать, но по самым скромным расценкам он мог бы получить 12 тысяч долларов). Это, собственно, еще одно ограничение модели: низкая пропускная способность и слабая управляемость.
4.       Подробная документация часто переводится только выборочно из-за проблем с ресурсами (сложность отслеживания, что переведено, а что нет, тут тоже играет роль). В то же время важные для пользователей разделы обычно все же переводятся полностью.
5.       Качество перевода чаще всего крайне низкое, но подразумевается, что если кому чего не нравится, тот то сам и исправит и свяжется с авторами документации или софта. Читая переводы, есть ощущение, что этого не происходит.

Есть еще комбинированный вариант, используемый коммерческими фирмами: перевод осуществляется силами студентов не совсем даром, но дешевле, чем обычно. Студентам – практика, а фирмам – прибыль. Пример - перевод Visual Studio 2008 и .NET 2.5 на бразильский выполнен студентами и MVP. Гибридная схема не устраняет врожденных проблем модели, но позволяет лучше планировать сроки локализации и переводить гораздо большие объемы.

В качестве короткого вывода: если у вас коммерческий проект, то не царское это дело. Лучше заплатить две тысячи за перевод, чем десять тысяч за восстановление репутации.

ЗЫ. Если у кого есть дополнительные цифры и данные на эту тему – буду благодарен за информацию.