white_bars

Источник: Top Ten Internet Languages - World Internet Statistics

Интересно тут вот что: год назад последовательность была почти такой же, с одним исключением: арабский был на десятом месте.
А если проводить сравнение с 2000-м годом, то число арабоязычных пользователей вырасло в 21 раз, в то время как остальные языки "удлинились” в диапазоне от 99% (японский) до 755% (китайский).

Если кого-нибудь волнует Россия, то она - аккуратно на одиннадцатом месте. Число пользователей – 32.7 миллиона, рост числа пользователей по сравнению с 2000-м годом – 954%.

С месяц назад мне на глаза попалась презентация Controlled English / Simplified English Бэрри Брастера (Berry Braster), которая впечатления не произвела, но запомнилась. Бэрри – директор американского отделения фирмы Tedopres, которая, собственно, и пытается продавать свои услуги в области Controlled Language (www.controlledenglish.com). Из презентации не очень понятно, как они продают себя клиентам, но в январском выпуске Multilingual выйдет его статья (под катом), которая кое-что объясняет. Основные пункты “продажи” выглядят примерно так: контролируемый язык дает

- улучшение “читабельности”
- уменьшение объема исходного текста на 15%
- увеличение процента утилизации при использовании Translation Memory на 10%
- как следствие – общее снижение стоимости локализации на 27%

Достигается это все типа за три простых шага: создание “словаря”, обучение персонала и использование спецсофта. Статья тоже оставляет много вопросов, на что, видимо, и расчет: если, например, кто-нибудь захочет узнать, а какой софт-то нужно использовать, то придется обращаться к Tedopres, а уж они своего шанса не упустят.

Ясно, что 27% экономии – это невсосуемо огромная цифра; клиенты убивают вендоров за 5%, а тут – просто клад, а народ мимо ходит. Что-то тут не то. Я, разумеется, полез все это проверять, кое-что накопал и сделал для себя выводы. Выводы разные. Главный: если вы не понимаете, что, зачем и как нужно делать, то лучше туда и не лезть. Люди, пишушие документацию, ненавидят, когда им указывают, как нужно писать. Люди, читающие документацию, ненавидят, когда им пишут в приказном тоне. Составление словаря для документации менее 100-150 тысяч слов “сожрет” всю экономию от снижения стоимости локализации. Те, у кого есть специализированный софт (Lionbridge, например), его не продают, а разработка и сопровождение такого рода софта – это еще те деньги. Внедрение системы может закончиться неудачей (как у Hewlett Packard). А экономия в конце может оказаться копеечной. И так далее.

Но что-то в этом есть: что-то меня мучает... Пока что не пойму, что :) 
В общем – читайте статью: может, чего навеет полезного :)

Это случилось: акции крупнейшей локализационной фирмы Lionbridge (торгуются как LIOX) второй день болтаются ниже доллара: текущая цена $0.75 за акцию. Если вчера еще можно было сваливать на то, что рынок падает, то сегодня уже сомнений не остается: за день Nasdaq поднялся на 5%, а LIOX опустился на 24%. Стоимость фирмы (market cap) составил $42 миллиона; по моим прикидкам это меньше суммы, которую Lionbridge должен банкам и VC по кредитам на покупку Bowne Global Solutions. По памяти расклад был примерно такой: около 130 миллионов у них было в банке, 10 миллионов отдали акциями, 52 миллиона заняли. Сколько они отдали за три года? – Думаю, что как раз миллионов 10. Но есть же еще проценты.

Я еще три года назад говорил, что мы столько не стОим :) Нет, угораздило же Рори пообещать акционерам, что он сделает из Lionbridge полумиллиардную фирму…
Не допрыгнул, надорвался.

В аналогичной ситуации в 2001 году они выкарабкались, снизив расценки чуть ли не до себестоимости. Было хорошо известно, что Lionbridge выигрывает все тендеры, и всегда было ясно, что это делается себе в убыток: там, где BGS, SDL и Mendez брали 19 центов за слово, Lionbridge просил 14-16, а то и ниже. Разница была в том, что тогда фирма не была должна банкам, и выкарабкаться было возможно хотя бы технически.

Что будет сейчас? – Сложно сказать. Их не купил Xerox, когда акции LIOX стОили $3. Их не купили индусы (Vipro), когда акции стоили $2,5. 
С другой стороны, поглощать их ровно сейчас по дешевке – это на самом деле неплохой вариант: ты платишь, скажем, $50M за фирму + вешаешь на себя миллионов 60 долгов. Учитывая обороты (400-450 миллионов) прибыльность (3-4%), получается прямо по учебнику: при самом плохом раскладе сделка за 7 лет окупается.

Единственно, что делать это нужно буквально в понедельник-вторник:

• пока не разбежались клиенты
• пока остался хоть кто-то из толковых сотрудников
• пока фирма не начала какие-нибудь манипуляции (если акции поднимутся чуть выше доллара, сделка перестает иметь смысл)

Покупать и быстро менять руководство :)
А то будет как с Yahoo: долго, мучительно и зря…

PS. Если кому интересно… Легенда гласит, что название LioNBRIDGE возникло как симбиоз аббревиатуры L10N (обозначающей локализацию) и “львиного” имени владельца (имя “Рори” похоже на “roar” – типа львиный рык). Любит он себя…

На одном из последних конференций 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. Гибридная схема не устраняет врожденных проблем модели, но позволяет лучше планировать сроки локализации и переводить гораздо большие объемы.

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

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

Хочу продолжить тему, почему одни фирмы на рынке выигрывают, а другие – проигрывают. Мысль о том, что пираты являются разносчиками прогресса и залогом успеха той или иной софтины, а маркетинговые усилия, функционал софта и правильные решения тут как бы и не при чем – это остроумно и способно увлечь впечатлительные массы. Другими популярными идеями являются связи в правительствах, расположение звезд, подкуп конкурентов, страшный и ужасный Media Player, встроенный в винду и прочая: you name it.

У меня на этот счет гораздо более прозаичные мысли. Ну, чтобы опять же далеко не ходить, взять хотя бы российский рынок интернет-браузеров и попробовать разобраться, почему в конце 90-х Internet Explorer стал популярным браузером, а Opera и Netscape пролетели. В картинках.

Картинка первая. Сюреш

Человека, отвечающего за политику Netscape в России звали Сюреш Патэл. Имя соответствовало общему сюру: Сюреш был индусом, родившимся в Англии, жившим в Австрии, работавшем в Германии. И – самое страшное - отвечавшим за Россию. Мысль о том, что для российского рынка нужна локализованная версия Netscape Communicator и техподдержка продуктов, была ему не чужда, но потребовалось почти полгода, чтобы получить от него согласие и контракт на перевод. Все эти долгие месяцы он проводил где угодно, только не в России. Выцепить его для переговоров удалось на Комтеке, куда он прилетел на пару дней.

Сказать, что на этом все закончилось – это ничего не сказать. Ни обещанных исходников, ни изменения кода для поддержки национальных стандартов – ничего не было прислано/сделано ни Нетскейпом ни Сюрешем. На письма они отвечали раз в месяц. От безнадеги я начал разбираться в том, как эта софтина устроена: выяснилось, что все незамысловато. Софт можно разобрать на ресурсы, а справку – на HTML-и. Я пару вечеров посидел за компом, сделал черновой перевод софта. Запустил - работает! “Вот оно, счастье!”

Дальнейший ужас я подробно описывать не буду, скажу только, что Сюреша уволили, дело утрясал глава Европейского Нетскейпа, за локализацию нам никто и никогда не заплатил, зато разрешили убрать из продукта упоминание Netscape и выпустить его со своим логотипом.

Вот скажите, это что – политика, ведущая к успеху и доминированию на рынке?

Картинка вторая. Опера

Мужик на фотографии с мегафоном – один из директоров фирмы Opera Software, занимающейся протестами и засуживанием конкурентов… Ой, то есть, конечно, разработкой браузеров.

В общем, человека зовут Хокон Ли, он – технический директор фирмы. Он протестует против OOXML.

Вовзращаясь к теме… Примерно во время эпопеи с Нетскейпом, я связывался и с Opera Software. Моим контактом был один из директоров фирмы, отвечающий за продвижение браузера на международном рынке. Обычно он не отвечал на письма и звонки, но, когда ему было совсем нечего делать, он звонил мне сам и правой рукой по телефону мечтал о том, чтобы Opera была переведена на все языки мира, включая русский. Когда я спрашивал о том, что планируется делать для завоевания российского рынка, он мне честно отвечал, что ЮАР на международном рынке для него важнее России (я могу ошибаться, но он сам был, кажется, ровно из Южной Африки), да и переводить туда ничего не надо. А в настоящее время он вообще находится в Андорре, где ведет переговоры с важным клиентом.

В России он не был и не собирался.

Теперь эта фирма, для которой Андорра важнее России, а технические директора вместо руководства разработкой софта стоят в пикетах, непрерывно жалуется, что Microsoft мешает честной конкуренции.

Задам тот же вопрос: вот это что – политика, ведущая к успеху и доминированию на рынке?

Картина третья. MS IE

А что в это время делал злобный Microsoft?

Да ничего особенного. Локализовал себе, помнится, Internet Explorer на русский язык и подло осуществлял его раскрутку через московское представительство и партнерскую сеть.

Чтобы машинный перевод заработал, технологий мало, нужна вера. Именно она после долгих проб и ошибок в клюве принесла процесс: нескладный, нестандартный, но работающий и удешевляющий перевод. За годы обсасыванья счетов и рассматриванья каждой цифты под микроскопом, клиенты поняли: самое дорогое в локализации – перевод документации (перевод софта обычно составляет меньше общей 10% стоимости проекта), а в переводе документации – собственно перевод. Из трех основных операций (перевод, редактирование, вычитка) перевод – самый дорогой и собственно острие MT направлено именно туда.
Полный процесс снижения стоимости перевода условно укладывается в шесть шагов.

1. Написание документации
На этапе планирования для авторов документации и справочной системы устанавливаются правила, определяющие среди прочего:

• Единообразное использование терминологии и повторяющихся элементов. Это позволяет снизить стоимость на пару процентов за счет использования Translation Memory: повторяющиеся строки переходят из категории “New words” (новые слова для перевода) в категорию “Repetitions” (полностью повторяющиеся сегменты), которая обходится клиентам процентов на 70 дешевле. В качестве примера приведу фирму Adobe: когда-то они выяснили, что в документации к разным их продуктам встречается несколько десятков различных вариантов написания строки копирайта. Соответственно, они столько раз заплатили за ее перевод. Если бы строка была одна, перевести ее можно было один раз. (Теперь это исправлено :) ).
• Построение фраз: фразы должны быть короткими, однозначными, по возможности соответствующими набору рекомендуемых шаблонов. Такие фразы хорошо отрабатываются системой машинного перевода. Без этого шага все остальные пляски с машинным переводом напрасны. Ничего не выйдет.

2. Утилизация существующих переводов
На документацию натравливается система Translation Memory (возьмем TRADOS для постоты): все, фразы, которые когда-либо переводились, будут переведены как обычно (Full matches или XTranslate), будет произведен поиск похожих фраз и повторений (Fuzzy matches). Для сегментов, принадлежащих к этим категориям, дальнейший процесс перевода происходит как обычно: редактирование, вычитка. Тут ничего не меняется.
Всё остальное (не найденное в Translation Memory) остается помеченным как “New words” и уходит на следующую стадию.

3. Машинный перевод
На этом этапе должны использоваться только системы машинного перевода, обеспечивающие некий минимально достаточный уровень качества (в основном – статистические). Единых критериев тут, кажется, нет. Когда-то я предложил удовлетворительной считать систему МТ, которая может перевести популярную песню на другой язык и назад так, чтобы по переводу можно было догадаться, над какой песней мы тут издеваемся. Шутка в целом прижилась :)
Машинный перевод выполняется для всех сегментов, помеченных как “New words”. Теоретически система машинного перевода в состоянии даже оценить степень достоверности результата исходя из используемых вероятностей, но на практике эта оценка является крайне недостоверной. По окончании этого этапа не остается непереведенных сегментов: либо для них нашли перевод в Translation Memory, либо прогнали через MT.

4. Автоматическое исправление перевода
На сегменты, прошедшие стадию машинного перевода, натравливаются фильтры, исправляющие известные регулярные ошибки: они подправляют склонения и спряжения, переставляют местами слова и фрагменты, правят пунктуацию и пр. Может быть проверена орфография и исправлены встретившиеся очевидные ошибки.
Важный момент: “известные регулярные ошибки” неизвестны до тех пор, пока первый вариант машинного перевода не попадет в руки лингвистам и они не начнут жаловаться. Поэтому первый проект почти гарантировано обречен на провал; к этому нужно быть готовым, нужно собирать информацию о том, какие ошибки встречаются, что нужно подкрутить, чтобы их стало меньше и пр. В общем, надо верить в то, что будет следующий проект. Без веры – никуда :)
Результат отправляется локализационным вендорам, с которыми договариваются о дальнейших операциях и ценах для двух групп.

5. Проверка и исправление перевода
Для сегментов, прошедших через TRADOS (шаг 2) делаются следующие операции:

• Для Full Matches производится вычитка (стоимость – около 30% от стоимости перевода новых слов)
• Для Fuzzy Matches производится редактирование (стоимость – около 60% от стоимости перевода новых слов)
• За Xtranslate (полное совпадение в контексте) никто не платит. Стоимость – 0.
• За Repetitions платят где-то 30% от полной стоимости… Хотя, это от вендора зависит.

6. Пост-редактирование MT
Стандартных цен для пост-редактирования машинного перевода (шаги 3 и 4) нет совсем никаких, тут как договоришься: некоторые вендоры совсем не берутся за такое, некоторые берутся за 90% от полной стоимости перевода, некоторые – за 80%. Ниже, кажется, не бывает. Но даже 10% скидки – это неплохая прибавка к пенсии…
Важно тут вот что: на малых объемах это не работает. К машинному переводу нужно привыкнуть и нужен особый склад ума (см. “вера” :) ), чтобы с ним работать вообще. Первые две недели производительность переводчиков может быть ниже стандартной раза в два – это почти норма. Если выбраны правильные лингвисты и качество машинного перевода действительно неплохое, то середине третьей недели наступает просветление и производительность резко возрастает. Приведу пример: для перевода на французский нормой считается примерно 2000 слов в день на человека. Первые две недели проверки машинного перевода французы матом крыли всех и писали, что производительность – где-то в районе тысячи слов в день. По окончании третьей недели им было предложено прекратить проект, но они внезапно начали бурно протестовать: оказалось, что они в это дело “воткнулись” и производительность выросла до 5000 слов в день на человека.
Но в принципе нужно быть готовым и к худшему варианту: если время идет, а производительность не растет, нужно останавливать проект.

 Я этот пост переписывал раза четыре: хотелось на примерах показать во что это выливается в цифрах, но получалось крайне неуклюже. В общем, чтобы не утомлять выкладками, приведу три группы цифр. Возьмем гипотетический проект в 300 тысяч слов перевода при цене 30 центов за перевод одного слова.

• Стоимость обычного перевода “с нуля” без использования TRADOS-а и машинного перевода, соответственно, будет 90 тысяч долларов.
• При использовании машинного перевода и TRADOS-a стоимость снижается примерно до 76 тысяч долларов; снижение в основном за счет машинного перевода
• Локализация документации следующей версии продукта (я взял условно-усредненный сценарий с тем же количеством слов) обойдется в 40 тысяч долларов: снижение в основном за счет TRADOS-а

В общем, вот так вот оно как-то…
Попозже еще напишу :)

Статистический машинный перевод (SMT) основывается на модели, в которой вычисляется вероятность появления в переводе каждого слова из имеющегося набора переведенных предложений, и выбирается вариант с наибольшими вероятностями. Для того, чтобы метод заработал, требуется наличие большой базы существующих правильных переводов, выполненных людьми: моя оценка минимального объема существующих переводов для получения условно-приемлемого качества SMT – три миллиона слов. Я встречал обоснование достаточности меньших объемов (700 тысяч слов), но я ему не очень верю… На текущий момент SMT является наиболее успешной реализацией идеи машинного перевода: она действительно работает. Ее не всякий может себе позволить (крупные базы переводов есть очень не у всех), но…

Приведу пример того, как это работает. Предположим, что нужно перевести “Bush is an idiot” на русский язык. Для начала алгоритмом оптимизации поиска отсекаются переводы, в которых не встречаются слова из исходной фразы, чтобы не перебирать слишком большой объем данных. Дальше определяется набор статистических вероятностей; например, выясняется, что для слова “Bush” есть два всплеска: на слове “куст” и на слове “Буш” (оба этих русских слова встречаются в переводах английских фраз, содержащих слово Bush). Аналогично для “idiot” найдется “идиот” и пара нецензурных вариаций. Для “is” и “an” тоже что-нибудь определится, но, с большой степенью вероятности, результат не будет иметь явно выраженных пиков и будет “прибит” шумодавами SMT (может, и зря). Но на втором проходе выясняется, что вероятность встретить сочетание слов “куст” и “идиот” в одном предложении практически равна нулю, а “Буш” и “идиот” – наоборот, встречается повсеместно. Аналогичные действия производятся для последовательности слов в переводе и синтаксиса. Конечный перевод будет выглядеть как “Буш идиот” (что, безусловно, правильно).

На уровне перевода отдельных фраз это работает более-менее сносно. Следующий шаг в развитии SMT – перенести этот прием на уровень текста: должен анализироваться весь текст, потом система спустится на уровень абзацев, а потом – на уровень предложений. Посик и анализ при этом существенно усложняются, но зато MT может начать “улавливать” контекст и выдавать правильный набор слов. Что-то такое в природе есть, но реально работающие системы ограничиваются статистическим анализом уровня предложений, что снижает качество.

Интересно тут следующее: для системы совершенно неважно, как устроен язык, какие у него правила и исключения, как переводится то или иное слово, с какого на какой переводим... На предпоследнем Localization World на семинаре по SMT раздел “вопросы и ответы” с ведущим Kirti Vashee проходил в однообразном режиме “Да какая разница?”:

Вопрос из зала: “А как система статистического машинного перевода обрабатывает ситуацию с переводом концептуальных структур типа (пример из японского)?”
Kirti: “Да это, в общем-то неважно. Какая вероятность выпадет, так и отработает…”
Другой вопрос из зала: “А вот есть еще такой лингвистический парадокс (описывается парадокс). Что с ним делать?”
Kirti: “А нам, в общем, пофиг ваши парадоксы: что нам формула Байеса выдаст, то и будет.”
итп.

Я млел. Просто млел :)

Понятно, что и тут есть куча деталей, которые нужно учитывать.

1. Наличие необходимого объема исходных переводов (что мало у кого есть). В мире IT каждый выкручивается сам: у Майкрософта есть миллиарды переведенных слов документации, Гугл импортировал 200 миллиардов переведенных слов из базы данных ООН, остальные экспериментируют с меньшими объемами.
2. Структура. SMT умирает на длинных фразах: если предложение состоит более чем из 10-12 слов, вероятность выдачи полной пурги становится стопроцентной. Для борьбы с этим явлением необходимо, чтобы авторы документации сочиняли свои тексты короткими лаконичными блоками с минимальным количеством экивоков (знакомо? ;) ). Это называется Controlled English – такой эрзац интерлингвы…
3. Скорость. Перебор – штука крайне медленная даже на уровне слов в предложении. Алгоритмы оптимизации запросов позволяют получать приемлемые выборки, а предварительная обработка “сырых” данных в разы увеличивает скорость их обработки (Google для этого использует MapReduce на своих кластерах нечеловеческого размера). Но как-то мне кажется, что полноценный статистический анализ на уровне текста целиком или хотя бы абзацев до сих пор не реализован: количество “измерений” (и время работы системы) должны увеличиваться на несколько порядков. Поправьте меня, если я ошибаюсь.
4. Правила. Лингвисты, проверяющие машинный перевод, довольно быстро просекают, что машины допускает одни и те же регулярные ошибки, и создают макры, которые исправляют их по всему тексту – глобально. По научному это называется “Automated post-editing” и на эту тему можно почитать статью Hugh Lowson-Tancred в последнем выпуске Multilingual. Ничего особенного, впрочем… В свою очередь разработчики систем машинного перевода для улучшения качества SMT вводят правила, избавляющие перевод от этих ошибок: никуда от этого не деться. На каждый язык приходится где-то по 12-16 правил. На русский – больше :)
5. Словари и Translation Memory. Ясно, что, если можно не переводить, а использовать готовое, то это нужно делать: прежде чем использовать SMT, на текст натравливается Translaton Memory в поисках полных совпадений, а словари встраивают в SMT engine.
6. Качество все равно будет погановатое: теория – теорией, а обольщаться не надо…

В следующий раз напишу на кой все это нужно :)

К концу 80-х на проблему машинного перевода забили почти все, кто пытался финансировать коммерческие разработки. Понятно, что оставались еще всякие IBM-ы, которым было все равно, сколько и куда вкладывать, SYSTRAN, который с середины 70-х жил на военных заказах, энтузиасты и мелкие академические группы. На слайдах по прежнему все было разноцветно: вот французская фраза, вот она превращается... Фраза превращается... Превращается фраза... Вообще, интересно, что такого есть между английским и французским, что большинство презентаций по MT эксплуатируют именно эту языковую пару?..
Презентациями можно было поразить воображение один-два раза. Иногда три. Впрочем, если инвестор совсем тупой, то можно и больше. Но рано или поздно заинтересованные стороны начинали осторожно спрашивать "А где же долгожданный результат?"
Базовая стоимость разработки заказной коммерческой системы машинного перевода колебалась в диапазоне 6-16 миллионов долларов, но результат мог порадовать только энтузиастов и впечатлительных журналистов; индустрию MT не впечатлил. Основные неработающие методики можно свести к трем категориям:

1. Word-by-word (подстрочный перевод). В качестве методологии перевода используется голый словарь для генерации квази-подстрочника: таких систем в интернете довольно много. На выходе они в лучшем случае выдают "Я стрелять мой нога", в худшем "Он(она) (с)делала это(т)". Предполагается, что по набору слов пользователь поймет хотя бы о чем речь.
   Слабым местом таких систем является практически все.
2. Rule-based (на основе правил). Собственно, наиболее частый метод. Перевод осуществляется на базе жестко заданных правил для преобразования одной группы слов в другую (на другом языке). Подразумевается, что система распознает структуру предложения и правильно переставит и согласует переведенные слова; в реальности это происходит только на эталонных фразах. SYSTRAN, от которого сейчас отказались и Google и Microsoft, и BabelFish  - наиболее яркие представители этого класса. На выходе в лучшем случае получаются "Однажды в течение ледяного холодного зимнего времени I от леса уезжают, было сильный мороз", в худшем - "В левом окне верхней рукы" (примеры реальных переводов). Предполагается, что такого качества будет достаточно, чтобы понять суть.
   Слабых мест много, но основное - такие системы не улавливают контекста и применимы только к очень ограниченному количеству языковых пар. Чтобы как-то адресовать проблему контекста, некоторые системы MT позволяют выбрать из списка домен (то, о чем речь): IT, деловая переписка, политика и пр. Приемлемое качество перевода при этом подходе - явление почти случайное. Пустые хлопоты - на протяжении нескольких десятков лет прорыва в качестве добиться не удалось.
3. Interlingua/Transfer-based (с промежуточным языком). Мой личный безнадежный фаворит. Идея состоит в том, чтобы перевести исходный текст на некий логичный промежуточный язык, а потом с него - на  нужный. В качестве промежуточного языка используют либо что-то совсем синтетическое, либо интерлингву или эсператно. Иногда используются два промежуточных языка: сначала производится описание исходного предложения, потом описание переводится в описание для целевого языка, а потом - на целевой язык. Метод заманчив многим, в частности, теоретической возможностью переводить с любого на любой. Про это все читать безумно интересно (а уж с разработчиками беседовать - это редкостное удовольствие), но такие системы относятся, скорее, к мифическим созданиям и в природе не встречаются. Цепочка "морфологический анализ" - "лексический анализ" - "семантический анализ" - "перевод в интерлингву" склонна рваться в любом месте.
   Интересно тут вот что. Ходили назойливые слухи, что интерлингве пытались приделать альтернативное применение: идея состояла в том, что, если писать документацию сразу на синтетическом языке, то потом можно будет сгенерить ее на всех нужных языках и сэкономить на локализации. Я даже не могу себе представить, куда и в какой форме авторы технической документации посылали энтузиастов машинной генерации текста...

И даже не то, чтобы все было совсем уж безнадежно: на самом деле многие системы всерьез использовались, под них затачивались производственные процессы и документооборот, клиентам делались звонкие обещания, из лабораторий в поисках смысла жизни выползали десятки коммерческих големов и просили госфинансирования. Но, по моему опыту, машинный перевод был и остается кошмаром всех профессиональных переводчиков, которых вынуждали им пользоваться: года три назад менеджеры крупнейшей немецкой локализационной фирмы отказались от долгожданного проекта, в котором использование машинного перевода рассматривалась теоретически. Уговорить их взяться за проект удалось только клятвенно (и неоднократно) пообещав, что никакого MT там не будет.

Но неожиданно что-то заработало. И заработало не совсем в технологическом смысле.

Про статистический машинный перевод - позже.

Вендоры в локализации - это очень отдельный зоопарк, где каждая особь уникальна, неповторима, да и (в ряде случаев) незачем. Вендоров можно делить по размерам (как это делает Common Sense Advisory), можно - по схожести внешних половых признаков (ну, например, Moravia и LCJ - практически близнецы-братья, только разнояйцевые), можно по историческому источнику раскрутки (например, BGS, SDL, Moravia и Mendez раскрутились на контрактах с Microsoft. Кстати, Рори Кован умудрился с первых дней существования Lionbridge разругаться с Microsoft, отчего несколько лет LIOX был запрещенной в Майкрософт фирмой и сосал лапу в стороне. Впрочем, Рори не только с Майкрософтом разругивался...)

В недрах каждой локализационной фирмы обитает свой Наполеон и кипят мексиканские страсти. Чтобы не тревожить сон существующих титанов, заглянем в душу почившей фирмы BGS. История Bowne Global Solutions настолько же уникальна, насколько и типична в деталях: купание в деньгах в конце 90-х, финансовые провалы начала века, метания, безумие руководства. Но фирма-то была действительно великой: и размерами, и людьми и историей.

Все началось в далеком 1980 году, когда аргентинец Клаудио Пинкус основал фирму под названием Alba Translations, жившую случайными переводами. В 1981 году на него работало уже 40 переводчиков, а фирма называлась Alpha Language Group Inc. - исторически это была одна из первых в Штатах локализационных фирм (сам Клаудио в интервью 1999 года назвал Alpha Language Group первой американской локализационной фирмой). Клаудио из подручных средств разработал одну из первых систем управления переводами - прообраз Translation Memory. В 1986 году фирма была переименована в IDOC, обосновалась в Лос-Анджелесе на окраине Беверли-Хиллз, и неторопливо начала прирастать офисами - в Рио и Дублине. (Кстати, кто знает, почему в локализации так много бразильцев? :) ). IDOC уже можно считать предтечей BGS: офисы, состав и принципы функционирования фирмы от переименования не изменились.

К началу 90-х фирма мало отличалась от других таких же, повсеместно возникших и выпасавшихся вокруг IT. Все шло своим чередом до тех пор, пока в 1992 году уездная корпорация Майкрософт не осознала, что перевод - это не основная для нее деятельность. Переводить софт силами собственных сотрудников, как это делалось в конце 80-х, было геморройно, дорого и некачественно. В качестве эксперимента заявку на перевод отправили в IDOC и - ура, получилось! IDOC оказался в нужное время в нужном месте, и несколько лет выступал для Майкрософта подопытным локализационным кроликом, получая все более крупные проекты. К середине 90-х IDOC под руководством Microsoft переработал свою инфраструктуру следующим образом:

1. Было создано отдельное подразделение - CBU (Content Business Unit), фактически бывшее внешним "расширением" Майкрософта, выполнявшее локализационные проекты именно так, как было нужно клиенту. Подразделение было миниатюрным, невероятно эффективным, без лишнего "жира". Майкрософт это устраивало, и большинство локализационных проектов того времени шло через IDOC.
2. IDOC-ом были открыты новые офисы во всех основных европейских и азиатских странах, чтобы выполнять поддержку и сопровождение локализационных проектов Майкрософт на восьми ключевых рынках.
3. Была создана группа Central Services: люди отвечали за единообразность процессов во всех офисах. Хранители печати. На самом деле - изумительная идея, до сих пор являющаяся объектом зависти многих локализационных фирм, которые не в состоянии себе позволить иметь что-то подобное. 
4. Большинство сотрудников первого состава фирмы получили директорские должности :)

Кроме Microsoft-а IDOC сотрудничал с другими монстрами духа - от IBM до Novell. К 1997 году, когда фирма стала крупнейшей локализационной компанией в мире, обороты росли, а деньги на фирму падали буквально из воздуха, Клаудио продал IDOC корпорации Bowne, занимавшейся Financial Printing (термин, не имеющий смысловых аналогов в русском языке) и озаботившейся диверсификацией бизнеса. Пару лет Клаудио поработал в Bowne, продолжая возглавлять свою фирму, перекрещенную в Bowne Global Solutions, а в 1999 году ушел директором в Ask Jeeves.

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

Уход Клаудио стал своего рода изгнанием BGS из рая: счастливые времена, рост зарплат, премии на новый год - все осталось в прошлом.

Продолжение традиционно следует. Может, даже завтра :)