Вчера Google запустил новый сервис - Translator Toolkit. На аглицких знаках описание можно почитать на Google Blogoscoped. Суть в следующем: любой может использовать Google Translator Kit для перевода при помощи гугловской версии Translation Memory. После загрузки документа на сайт сервиса в одном из поддерживаемых форматов (HTML, Microsoft Word, Rich Text, OpenDocument и Plain Text), он автоматически анализируется ядром GTT. Все фразы, для которых в Translation Memory находятся полные или приблизительные соответствия, переводятся как типа в TRADOS-е или SDLX-е. На остальные фразы, как я понимаю, можно натравить машинный перевод (все тот же статистический движок). Есть поддержка своих глоссариев (можно загружать в csv) и своих баз (в tmx). С документом можно работать самостоятельно или сделать его общедоступным. Дальше можно редактировать руками, и все переводы тут же попадают в ту же базу Translation Memory. Crowdsourcing в действии.

Ну и типа аналогичным образом можно переводить онлайновые материалы с Wikipedia или Knol.

Я пока что очень немного потыкался по продукту и могу сказать только то, что в качестве языка исходного материала, похоже, поддерживается только английский. Перевод на русский поддерживается. Вроде – да, работает. Если кому нужно…

Консалтинговая фирма Common Sense Advisory опубликовала ежегодный рейтинг тридцати крупнейших локализационных компаний. Что бросилось в глаза:

• L-3, обеспечивающая переводы в Ираке, переместилась с первого на третье место, теперь у них всего 434 миллиона в год… Нищеброды! :)
• На первое место с оборотом в 691 миллион долларов взгромоздилась некая фирма "Global Linguist Solutions", на сайте которой написано "GLS exists solely to provide interpretation, translation and linguist services in support of U.S. Forces." То есть, за год образовалась еще одна контора, успешно осваивающая военную часть госбюджета США.
• Совокупный бюджет L-3 и GLS составляет свыше одного миллиарда долларов. Это та сумма, которую одно правительство США тратит на услуги переводчиков. В прошлом году эта сумма была в полтора раза меньше.
• Если исключить L-3 и GLS, совокупный оборот всех остальных фирм в списке - около 2 миллиардов долларов.
• На втором месте остался Lionbridge. За год его обороты практически не изменились: Рори не удалось допрыгнуть до отметки “полмиллиарда”.
• Чешская Moravia, мечтавшая о 75 миллионах долларов в 2008 году, остались на уровне 42 миллиона. У Майкрософта не нашлось для них достаточно крупных проектов :)
• Есть ощущение, что частные фирмы показывают "дутые" цифры. Доказать не могу, но есть суммы, вызывающие сомнения :-]
• Авторами исследования указаны Ренато и Натали Келли. Обычно это были Ренато и Дон ДиПалма. При случае спрошу Ренато, куда он девал Дона :)

Мне тут знакомый прислал: европейская локализационная фирма ищет заведующего офисом (который Operations Manger) для их отделения в Нью-Йорке.  Зарплата - $85k + 20k бонус, требуется пять лет опыта в такого рода деятельности. 
Может, кого заинтересует… :)

На сайте Windows Live Labs нашел очередное торжество человеческого разума - Microsoft Live Labs Thumbtack (http://thumbtack.livelabs.com/)

Животное чуть-чуть забавное, но это показывать надо, словами будет скучно. Такое онлайновое хранилово того, что надо бы запомнить или куда-нибудь заныкать, чтобы не потерялось. Позволяет расставлять тэги, добавлять комментарии и, как это теперь принято, делиться друг с другом своими подробками. Ну, наверное, есть люди, которым это понравится и наверняка есть такие, которым это надо. Фишечка состоит вот в чем: придуман довольно остроумный способ как обойтись без установки клиентского софта. В список Links (или Bookmarks в ФФ) добавляется закладка с именем "Get with Thumbtack", которая представляет собой не просто Url, а Жабаскрипт. По нажатию на закладку он вытаскивает с сервера окно, вставляет туда текущую страницу или выделенный текст и дальше можно результат закидывать на Thumbtack. Идея ничего так - мне понравилась.

Реализация подкачала: ровно этот великий и ужасный Жабаскрипт с серверной поддержкой обламывается на символах расширенного набора, в том числе и русских.

Поубивал бы...
Впрочем, если зайти на сервис и вводить туда данные руками (или копировать текст через буфер обмена), то все работает чисто. Даже интерфейс - вполне такой себе милый.

А вот основы курса Coding for International Market авторам надо подучить. Да и сам сервис потестировать бы на нескольких языках, знаете ли... Или на псевдо-локализации. И, в общем, как-то бы уже правильно бы выставлять кодировку бы...
Юзабилити тоже бы подучить бы, кстати. Если кто-нибудь утомится искать, как удалить какую-нибудь запись, даю намек: кнопки "Удалить" там нет вообще. Все делается драг-энд-дропом в незаметную урну с неочевидным названием в левом нижнем углу.

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

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

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

Арабского и иврита девелоперы боятся как огня, жуткие сказки о BiDi рассказывают друг другу на ночь приглушенными голосами, а баги они переадресуют друг другу веками. Я чего-то тут решил тряхнуть стариной и помочь населению: попросил все баги переправить мне, пообнюхивал, пофиксил через вставку U+200E и U+200F и задумался. Должен же существовать способ автоматического определения глюков с BiDi при переводе текста из LTR в RTL (типа в  “الوصول إلى ملف data port (.dpt)‎ ، يجب ” разлетаются скобки “الوصول إلى ملف data port (.dpt) ، يجب ” ). Или всё, что не укладывается в стандарт, всегда фиксится руками? А? Френды?

Уж очень не хочется самому писать анализатор…

С месяц назад мне на глаза попалась презентация 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 я оборвал буквально на середине и убежал по делам. А сегодня уже и дописывать лень, но я все-таки спою…

Lionbridge – вполне себе диверсифицированная фирма: у них есть около тысячи девелоперов в Мумбаях, отрабатывающих софтовые аутсорсинговые проекты (в том числе и от Майкрософт), у них есть большой штат технических писателей (проекты в диапазоне от написания руководств к оборудованию Hewlett Packard до технической документации для военно-воздушных сил), есть некоторое количество толмачей, работающих для госструктур США, есть машинный перевод и много еще чего. Да и собственно локализационные проекты – штука инерционная, длящаяся месяцы, и даже при самом плохом раскладе поток денег не иссякнет довольно долго.

В общем, мы могли бы пойти в разведку, мы могли бы играть в кино, но уже совсем не с кем и – главное - поздно. Кредит доверия исчерпан: акционеры уже давно не реагируют на новости PR-отдела о заключении очередного суперстратегического соглашения с малоизвестными фирмами. Ждут мяса денег. А ближайший квартальный отчет – в конце января; при нынешнем раскладе это – вечность, до января можно просто физически не дотянуть. И даже если результаты квартала получатся удачными, то годовой баланс будет близок к нулю: начало года было традиционно убыточным. Реагировать будет не на что.

Какие еще есть варианты? Взять кредит? - Ясно, что кредитов не дадут: во-первых, таких ясноглазых соколов в очередях на кредиты как до Китая раком уже тысячи, а во-вторых, под что кредит давать?
Пойти кланяться к местным властям на тему “шеф, все пропало, гипс снимают, клиент уезжает”? – Ну, фирма-то крупная только как сумма отдельных подразделений, а каждый отдельный офис – это очень мелкий аквариум: одна-две пираньи и десяток гупёшек. Штаб-квартира фирмы – далеко не градообразующее предприятие, а налоги они платят и вовсе где попало. Таких не спасают, на таких отыгрываются.
Фокусы типа reverse split или buyback? – Имея ярко выраженный звездец в зените, борожом пить поздно.

Но есть же еще темная сторона Силы: их VP of Operations за свою жизнь уволила больше народу, чем слов в этом посте. Думаю, что этот деревянный вариант и отыграют: закрыть пару офисов, повыгонять часть рабочих рук, выйти из долларового диапазона, дотянуть до Нового года.
В общем, такое лучше наблюдать заочно и с почтительного расстояния…

Это случилось: акции крупнейшей локализационной фирмы 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” – типа львиный рык). Любит он себя…

“- Вы Йобана мать?
- Я Йобана мать!
- Плачь, женщина! Убили Йобана!”
(Филологическая разговорная шутка из жизни югославских партизан)

Один из самых экзотических способов запороть проект – это с легкостью подписаться на локализацию голосовых информационых команд в софте (о играх и мультимедии я не говорю, там другой мир). Типа "Планета... Шелесяка... Растителности... нет... Населена... роботами... Нажми кнопку ..."Х"... чтобы узнать свое будущее."
Допустим, у вас есть все необходимое: звуковая студия в мансарде, цифровые микрофоны из Австралии, компьютеры, софт, техники, звукоооператоры, база данных дикторов и клиент, которому в голову взбрело добавить к почтовому серверу функцию чтения писем по телефону. Клиент ничего не понимает в локализации и voice prompt-ах, но горит желанием и предлагает делать локализацию в параллель с разработкой сервера. Проект начинается в ноябре. Рассмотрим два возможных варианта:

Сценарий номер 1. Вы соглашаетесь. 
Проблема номер один: дикторы. Дикторы – существа капризные и дорогостоящие. Предлагать им приходить каждый день и записывать по пару фраз – разоришься. Клиент столько платить не станет никогда. Посоветовавшись со знатоками, заключаешь с диктором договор на два месяца, а там как масть пойдет. В течение двух месяцев диктор обязан участвовать в четырех сессиях: две для записи, две – для исправления ошибок после прослушивания и интеграции в софт. На практике это выливается в 8-10 оплачиваемых сессий (тон и темп диктора зависят от настроения и расположения звезд, и склеить “двадцать” и “пять” так, чтобы это звучало натурально, не всегда получается, хотя обработка софтом может помочь. Но при большом количестве команд и привередливом клиенте это не вариант) с практически полным переписыванием материала в каждой сессии. После новогодних праздников диктор простужается и у него пропадает голос.
Клиент решает, что вы не в состоянии справиться с проектом. Проект теряется.

Сценарий номер 2. Вы не соглашаетесь.
Вы пытаетесь предусмотреть все возможные варианты, объяснить все детали клиенту и предлагаете произвести запись в конце цикла разработки.
Клиент решает, что вы ему пудрите мозги. Проект теряется.

Предположим, что все обошлось, клиент попался не буйный покладистый: с пятого раза понял разницу между мандаринским и кантонским диалектами, платит как скажешь, соглашается на измененный график и запись материала в конце. Ждем конца, пишем. Оказывается, софт не в состоянии работать с русским и итальянским. Первый же voice prompt накодирован примерно так:

SingularForm = “Hello! You have one message in your mailbox!”
PluralForm = “Hello! You have %1 messages in your mailbox!”

Без вариантов. Либо одно сообщение, либо много. Софт не понимает, что в других (не-английских) языках может быть “три сообщения”, но “пять сообщений”. При локализации собственно софта о такие строки спотыкаешься часто, но и решение известно: громко выматериться и использовать сокращения (“В Вашем почтовом ящике %1 сообщ.”) или изменить структуру (“Число сообщений: %1").
С voice prompts такое не пройдет: работа с числительными, днями недели, названиями месяцев – это медленная смерть.
В этом случае теряется и проект и клиент: пойти на поводу у вендора и так подставиться – такое не прощается. 

Хорошего решения в рамках локализации проблема не имеет. Правильный подход: работать с клиентом на этапе написания спецификаций. Для достижения такого уровня координации требуются годы успешной работы и полное доверие. Если они есть – молитесь! :)

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

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

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

Если кому интересны события в мире локализационных монстров и зубров: акции крупнейшей локализационной фирмы LioNBRIDGE упали почти до двух долларов за акцию, подешевев за день почти на 17 процентов. Еще год назад акционеры, помнится, мечтали о десяти долларах за акцию…

Рыночная стоимость фирмы (Market Cap) опустилась до 120 миллионов долларов. Чтобы дать масштаб: это на 10 процентов меньше, фирма имела на счете в банке в 2003 году. Это почти в два раза меньше, чем LioNBRIDGE заплатил за покупку Bowne Global Solutions. Это почти в 4 раза меньше, чем обороты фирмы в прошлом году.

Фирма полумиллиардного масштаба за 120 миллионов – это подарок любому, кто надеется выгодно вложить капитал (но еще не знает, какой за этим скрывается геморрой :) ). Тем не менее, ходят слухи о двух потенциальных покупателях: индийская Wipro и Xerox. Есть еще третий вариант – не продаваться совсем. В этом случае Рори Кован (CEO) второй раз в жизни будет близок к тому, чтобы потерять фирму. Хотя, собственно, нынешняя финансовая яма вырыта в том числе и его молитвами.

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

Хочу продолжить тему, почему одни фирмы на рынке выигрывают, а другие – проигрывают. Мысль о том, что пираты являются разносчиками прогресса и залогом успеха той или иной софтины, а маркетинговые усилия, функционал софта и правильные решения тут как бы и не при чем – это остроумно и способно увлечь впечатлительные массы. Другими популярными идеями являются связи в правительствах, расположение звезд, подкуп конкурентов, страшный и ужасный 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 на русский язык и подло осуществлял его раскрутку через московское представительство и партнерскую сеть.

Читая некоторые статьи, оправдывающие пиратство, выдавая его за двигатель прогресса, не оставляет ощущение, что тебя держат за идиота, элементарно подтасовывая факты. По цепочке через dantilly прочел об изысках некоего Ariel Katz:

“В частности, автор ссылается как раз на пример продукта Microsoft Word и таких альтернатив, как Corel Word Perfect и так далее. То есть он сделал предположение, что не без помощи пиратов продукт Microsoft стал одним из основных, фактически единственным, на рынке сегодня текстовым редактором. Это достаточно хорошо перекликается с упоминанием о ситуации в России. То есть до какого-то времени в отношении пиратства не предпринималось никаких мер, или они больше заключались в словесном порицании пиратов, какие они «нехорошие», пока продукт не захватил рынок полностью. После этого уже стали применять меры по борьбе с пиратством по-настоящему».”

Даже не задаваясь вопросом “а с чего бы это пираты так благоволили ненавистным продуктам Майкрософт?”, бросается в глаза явное незнание предмета.

Если взять тот же рынок офисных наборов, что было в наличие 15 лет назад? - Word Perfect Office, Lotus Smart Suite и Microsoft Office.
Word Perfect был самым популярным текстовым процессором в мире, а Word Perfect Office был в принципе самым полнофункциональным и продвинутым набором – с поддержкой SGML, разметки, продвинутым встроенным языком программирования и всем таким.
Lotus 1-2-3 был самым популярным в мире табличным процессором – фактически стандартом в этой области. Хотя, был еще Quattro Pro, популярные еще с Борланда, поскольку именно там впервые появился настоящий WYSIWYG. В Lotus-овский набор входил популярный AmiPro. Но – главное – он интегрировался с Lotus Notes, поэтому все фирмы, автоматизирующие документооборот, рассматривали Lotus Smart Suite как основной продукт.
Что касается Microsoft Office, он был средним неуклюжим продуктом, на который пользовали других пакетов смотрели более чем снисходительно.

Что из этого тащили пираты? – Всё тащили. Никакой дескриминации не было.

Что из этого переводилось на другие языки? – Всё переводилось. Это на самом деле немаловажно.

Что произошло дальше?

1. Word Perfect Office. Рэя Ноорду сместили, на его место поставили Боба Франкенберга, который продал Word Perfect Office канадской фирме Corel. Программисты разбежались (переезжать из Юты в Канаду? – Вы шутите!), а Corel потратил 5 лет на то, чтобы научиться продавать новый для себя продукт: рынок был потерян. Локализация на бОльшую часть языков (включая русский) прекратилась: международные рынки были потеряны.
2. Lotus SmartSuite. Джим Мэнзи продал Lotus косолапой фирме IBM. Программисты частично разбежались (включая Рэя Оззи, который теперь вице-президент в Майкрософт), а IBM так никогда и не научилась продавать новый для себя продукт: рынок ушел навсегда. Локализация на бОльшую часть языков (включая русский) прекратилась: международный рынок фирмой IBM был честно прохлопан.
3. За то же время Microsoft никому ничего не продавал, фокусируясь на выпуске новых версий Microsoft Office, сделал несколько наборов для разных групп пользователей, локализовал его на 36 языков (включая русский. И – отдельной строкой – не свернул локализацию в 1998 году, как это сделали 99% западных фирм), пОтом и кровью научился его продавать, интегрировал его со средствами разработки приложений, накрутил вокруг офиса сервисов и сделал еще много чего правильного.

Что должен сказать честный автор, сравнивая эти три истории? – а. Продажа фирмы больно бьет по продажам софта. б. Продажа фирмы с переездом больно бьет по мозгам. в. Продажа в кривые руки – это смерть. г. Пираты тут не при чем. Все это время пираты тащили все эти пакеты и тащат по сей день: Corel Word Perfect Office и ломалки регулярно мелькают во всех злачных местах. А Lotus Symphony (в девичестве – тот самый SmartSuite, только без AmiPro) и вообще бесплатен: тяни – не хочу.

Вот, как-то так…

Чтобы машинный перевод заработал, технологий мало, нужна вера. Именно она после долгих проб и ошибок в клюве принесла процесс: нескладный, нестандартный, но работающий и удешевляющий перевод. За годы обсасыванья счетов и рассматриванья каждой цифты под микроскопом, клиенты поняли: самое дорогое в локализации – перевод документации (перевод софта обычно составляет меньше общей 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-а

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

На кой этот машинный перевод (MT) вообще нужен и за что там берут деньги-то.
Отбросив разработки под заказ для всяких контор типа Минобороны, мы остаемся с очень лукавым набором. По причинам того, зачем MT возникает на горизонте, проекты условно можно поделить на пять категорий:

1. Приманка

Это, пожалуй, самый забавный способ использования MT. Делается это так: вендор приходит к потенциальному клиенту и предлагает очень низкие расценки на перевод: там, где, другие берут по 20 центов за слово, предлагается перевести по 14-16 центов. Запускается разноцветная презентация и в танце рассказывается о технологической продвинутости вендора: система машинного перевода позволяет сэкономить на собственно переводе, а о качестве не стоит и беспокоиться - в другом кармане у вендора (на слайде номер четыре) обитает проверенная веками система проверки качества, которая, знаете ли, гарантирует.
Если клиента удается раскрутить, перевод просто отправляют самым дешевым переводчикам, берущим по 6 центов за слово и под видом перевода обычно возвращающим полную пургу. Никаким машинным переводом при этом в процессе и не пахнет, но качество получается вполне сравнимое… Впрочем, на MT сваливаются все проблемы клиента…
Посылайте таких друзей открытым текстом. Дешево и качественно не бывает.

2. Эрзац локализации

То же самое, что и предыдущий вариант, только наоборот. Начало такое же: подкат, низкие цены, все такое… Про машинный перевод не упоминается, но в реальности перевод осуществляется какой-нибудь системой типа Google Linguistic Tools или SYSTRAN и присылается клиенту как окончательный вариант перевода. Будучи пойман за руку, вендор может с честными глазами утверждать, что они отработали свои деньги: сидели днями и ночами, копировали текст из одного окна в другое. Этот бред у нас песней зовется…
Интересно, что именно этот вариант всплывает все чаще и чаще: лет пять назад такое проворачивали канадцы, но там хотя бы была никому не известная контора. А с год назад я споткнулся о перевод известной российской локализационной конторы, которая, будучи прижатой к стенке, покололась, что прогнала текст через какую-то MT, но больше этого не повторится.
Рекомендация: любой перевод нужно отправлять на проверку лингвистам. Они такие вещи выщелкивают за пару минут: по общей несвязухе, навязчивому использованию внеконтекстных терминов, шаблонным структурам и прочему.

3. Дурная голова

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

• клиент уже заплатил за систему MT и копытом бьет – хочет отработать деньги
• клиентскому начальству уже пообещали, что локализация теперь будет стоить 15 тысяч долларов, а не 120 тысяч, как раньше
• очень сложно объяснить ничего не понимающим ни в лингвистике ни в MT клиентским начальникам, что переводом этот набор слов не является

Вляпавшимся в такую ситуацию вендорам один совет: уходите в несознанку, ни за что не соглашайтесь на эксперименты на условиях клиента. Вправляйте мозги. Если не получается – уходите огородами. Клиент вернется. :) Согласие обойдется дороже: во время переговоров с одной немецкой локализационной фирмой (на самом деле великая фирма – с сетью переводчиков и лингвистов высшего класса, студиями звукозаписи и постоянными заказчиками типа Deutsche Welle) я упомянул машинный перевод. Они аж с лица сошли. Я такого в жизни не видел: готовы были встать и уйти, отказаться от довольно легкого проекта на нескольких сотен тысяч долларов; пришлось им пообещать, что никакого машинного перевода не будет, и потом долго еще выспрашивать, кто же это над вами так надругался и выслушивать душераздирающие истории…

4. Время

В отличие от предыдущих двух вариантов этот действительно подразумевает использование MT по назначению, но с побочными эффектами.
Есть набор клиентов, которым действительно кроме машинного перевода ничего не подойдет: им нужен “мгновенный” перевод со сносным качеством. Ждать они не могут по тем или иным причинам: например, госавтоинспекции поселка городского типа Нью-Йорка важно, чтобы любые изменения в законодательстве сразу же становились доступны на их веб-сайте на испанском языке – одновременно с англоязычным оригиналом. Для этой цели используется машинный перевод, а через 2-4 дня он подменяется человечьим текстом (обычный перевод делается отдельно).
Для такого сценария разрабатываются специальные “словари”, скармливаемые системе; берутся существующие переведенные документы, делается частотный анализ, alignment, все это закидывается в базу правил и терминов, используемую MT. Условно говоря, система “затачивается” под перевод очень определенных документов, чтобы результат мог быть хотя бы понят; для этого существует термин intelligibility (“понятность, доступность”): если даже перевод – полная туфта, но его можно понять, то говорится, что у результата приемлемая intelligibility. 
За создание индивидуальных словарей берется 20-30 тысяч долларов за одну языковую пару. Ну, и за обычный перевод/подчистку берется отдельно, по стандартным расценкам.
В принципе-то ничего себе вариант… Дороговато только.

5. Деньги

Про это будет следующий тематический пост :) Он у меня уже в процессе, так что ждать недолго… :)

Статистический машинный перевод (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. Качество все равно будет погановатое: теория – теорией, а обольщаться не надо…

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