white_bars

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

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

Фирма А официально объявивла о снижении зарплат. Зарплаты в фирме А начинаются с вполне приличных цифр: базовая зарплата PM - от 85 до 100 тысяч, Engineering Manager - 100 тысяч, девелоперы начинаются в районе 80-85 тысяч, но, похоже, реально большинство получают 93-100 тысяч (интересно было бы узнать, кто там у них получает 154 тысячи). Повышение зарплат в прошлом было понятием регулярным и реальным: они увеличивались, а в 2004 году уровень зарплат повысился скачкообразно. Премии были.
Теперь обороты упали и зарплаты снижаются по простым и понятным правилам:

• Зарплата CEO ($1.45 миллиона в 2008) снижается на 20%.
• Базовая зарплата вице-президентов снижается на 15%.
• Базовая зарплата менеждмента верхнего уровня снижается на 10%. 
• Зарплаты сотрудников снижаются на 2,5-5 процентов. 

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

Другой вариант: фирма Б. Официально ничего не было объявлено (хотя кое-какие слухи на поверхность всплыли), сотрудников американских офисов заставили в индивидуальном порядке подписать документ, по которому они согласились на десятипроцентное уменьшение зарплаты. Та же бумага напоминает о том, что размер своей зарплаты и ее изменение запрещено обсуждать с кем бы то ни было, кроме начальника офиса и представителя отдела кадров.

Премий в фирме Б не видели с 31 декабря 1999-го года, да и повышение зарплат - явление скорее исключительное: если и случается, то раз в 3-4 года, а размер увеличения никогда не превышает 1000 долларов (в год). Зарплаты начинаются с 38-40 тысяч долларов (координаторы), PM получает от 54 до 60 тысяч, инженеры получают примерно столько же. Верхний предел (Senior PM/Engineer) - около 66-68 тысяч, подбираться к этому пределу нужно очень осторожно, поскольку есть шанс вылететь при первом же сокращении.

В связи с десятипроцентным сокращением, сотрудники, получавшие 66 тысяч, будут получать 60, что в финансовом плане отбрасывает людей назад на многие годы. Совет "Бегите! Бегите в фирмы А, М, Г и любую другую, и быстрее" не работает: к сожалению, большинству сотрудников просто некуда бежать, рабочая виза L1 - это разновидность кабалы.

Зарплаты руководства фирмы в  ранге от директоров и выше не изменяются (известно, что один "свой" человек был повышен до директора, чтобы его зарплата не пострадала). Зарплата CEO, доведшего фирму Б до финансовой ямы, так же сохраняется в размере 550 тысяч плюс бонусы в размере двух с половиной миллионов.

Есть две программы, которые мне нельзя запускать: Adobe Photoshop и Microsoft Visual Studio. Если я их запускаю в свободное от работы время, то застреваю в них надолго. Видимо, в детстве не нарисовался и в конструктор не наигрался… В общем, VS мне попала под хвост вот по какому поводу: есть вещи, которые в локализации считаются само собой разумеющимися, которые принимаются на веру и все такое… Например, что немецкий - “длинный” язык, то есть, что при переводе с английского на немецкий текст существенно удлиняется – по сравнению с остальными. Я, собственно, тоже принимал-принимал, а тут выходные… Дай, думаю, покручу переводы, статистику пособираю.

Взял базу переводов, около 100 тысяч фраз и компьютерных терминов, написал програмку, которая выцепляет и анализирует пары “английский оригинал – перевод” для шести языков: французский, итальянский, немецкий, испанский, русский, португальский (бразильский). Азиатские языки мучать не стал: они в общем случае короче (в смысле количества символов).

О некоторых результатах напишу завтра, когда дообрабатываю: меня интересуют 12 параметров для каждого языка, я с ними еще вожусь. Если хотите, можете попробовать угадать три из них:

• У какого из вышеперечисленных языков встретился перевод с максимальным удлинением? Пример: “ Cannot Find Help File” на итальянский переводится как “Impossibile trovare il file della Guida”, удлинение 81%. А “User” на русский переводится как “Пользователь”, удлинение – 200%. И так далее. У какого языка встретится самый большой процент?
• У какого из вышеперечисленных языков самое большое “среднее” удлинение текста по всей выборке? Все языки действительно “в среднем” длинее английского, какой “самый удлиняющийся”?
• У какого из языков получилось наибольшее количество переводов, где длина оригинала больше длины перевода? Ну, типа “Connection Attributes” на одну букву длинее чем “Атрибуты соединения”… В каком языке чаще всего встречаются такие “короткие” переводы?

Кидайте предположения в приват, завтра сверитесь :)

Джо ДиДамо (Joe DiDamo), некогда легендарной фигуре локализации (работал балшым началником Berlitz в Санта-Монике), не удалось ужится на одной планете с Томасом Кратохвилом. В сентябре Джо ушел из Moravia, чтобы стать балшым началником в Jonkers. Я с Джо разговаривал где-то полгода назад, он жаловался, что его достал совок в чешском исполнении… Вообще, за последние полгода из Moravia в Jonkers ушло трое моих знакомых. Джо – четвертый. Переманивают лучших – более приемлемыми условиями работы и большей зарплатой.
Правильно делают.
А в Moravia остаются те, которым некуда идти.

На место Джо Moravia взяла Диану МакЭвини: никому не известную тетку, которая, вроде как, работала в Bowne Global Solutions (не помню), а потом ушла в собственно Bowne в подразделение, занимающееся переводом финансовых документов (Bowne Translation Services). Судя по должности, там она была совсем никем: ее должность называлась International Director of Sales and Marketing. Люди, работавшие в “Big Bowne” знают, что там процветает “инфляция должностей”: у обычных сейлзов там должности стандартно называются “Senior Director of Sales”, чтобы клиенты уважали звучало внушительно. Я не представляю себе, кого там директорами называют.
Уборщиц, наверное…

А вот новость, которую пока что держат в секрете, и в прессу она не попала: Ник МакМэхон (Nic McMahon), генеральный директор и вице-президент Jonkers уходит в Lionbridge. Подробностей я пока не знаю, но есть шанс, что Lionbridge хотят перестать дуть щеки с целью выкарабкаться из однодолларового капкана, в который они попали. Не знаю, уволят ли Трейси из вице-президентов, но… Поживем – увидим.
А для Jonkers (и LCJ) это серьезный удар. Я так понимаю, что потому и держат в секрете – в себя приходят.

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

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

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

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

(окончание эпопеи BGS)

В 1999 году место ушедшего Клаудио Пинкуса занял назначенец от "Большого Bowne" Карл Глейзер: человек, имевший к локализации такое же отношение, как Джордж Буш к исламу. Этим не преминули воспользоваться директора из LBU. Дело в том, что 180 человек из CBU жили куда лучше, чем 600 человек из LBU: у сотрудников работавшего на Майкрософт CBU были выше зарплаты, больше премии, меньше начальства, а LBU в стороне сосало лапу. У сосания была простая причина: несмотря на то, что Майкрософта делались огромные скидки, прибыль, приносимая CBU, в разы превышала прибыль LBU. Майкрософт действительно был доволен качеством работы и проекты шли широким потоком. Но гонцы из LBU представили это Карлу так: мы тут кровь из носа, пашем, как слоны, а они там жируют, гады! Надо немедленно отнять и поделить! Знакомо? - Совок в действии.

Карл объявил о том, что CBU сливается в экстазе с LBU, а деньги - всем поровну. Тут уже возмутился Майкрософт: CBU - это наше совместное творение, заточенное под нас, процессы - специфические для Microsoft, и мы - против этого слияния, оно нарушает договоренности, полиси, безопасность и пр. Карл гордо ответил в том смысле, что "моя фирма, что хочу, то и ворочу". Майкрософт в лице Анила Сингх-Молареса почесал в затылке и отозвал один из своих проектов (Microsoft Encarta). BGS за один день потеряла 11 миллионов долларов; это было что-то около сорока процентов всего бизнеса BGS.

Карл задницей сердцем почувствовал, что под ним зашаталось кресло. Как-то нужно было отыграть и вашим и нашим. Объявленное слияние CBU с LBU было решено прекратить, да еще и с противоположным знаком: CBU становился независимой фирмой "Immersant" и отходил каким-то друзям Карла. Говорят, что на этот раз его наконец-то отымели, чтобы он пришел в сознение. Перестройка была отменена, возобновились переговоры с Майкрософт о возвращении бизнеса, но Карл чувствовал, что наверху, в Большом Bowne, им по прежнему недовольны, и сделал роковой шаг: в конце 2001 года было объявлено о приобретении BGS-ом небольшой фирмы Mendez за 47 миллионов долларов. Эти 47 миллионов были оборотом BGS за два года; это как если бы Microsoft предложил за Yahoo 100 миллиардов...

Эта сделка не принесла счастья никому. BGS приобрела большой мыльный пузырь: за вывеской "Mendez" ничего не скрывалось, ни клиентов, ни сервисов. Флорите Мендез, на халяву получившей 47 миллионов, деньги тоже не пошли впрок: через месяц после получения денег, у Флориты обнаружился рак по всему телу и она по полной программе загрохотала в клинику. Тоже завидовать нечему.

Кстати, с Mendez-ом BGS-у всучили систему машинного перевода, которую теперь пытается использовать LioNBRIDGE. Разрабатывать ее начал еще L'n'H, но быстро понял, что это - пустая трата сил и денег, привинтил это все к Mendez-у и сплавил в BGS.

В любом случае, это был звонкий провал Карла: огромные деньги потрачены совершенно впустую. Вдобавок, в IT был кризис, денег не было ни у кого (если кто помнит, Lionbridge был близок к банкротству: если бы BGS купил бы его, индустрия сегодня была бы совсем другой). Именно в моменты отсутствия финансов люди и фирмы начинают делать глупости; Карл обратился к заклятым друзьям из руководства Berlitz Global Network, которые находились в финансовом завале, с предложением спасти друг друга. Типа BGS покупает Berlitz, последний соглашается, обороты увеличиваются, все довольны. Berlitz согласился, но выставил свое условие: никого из руководства Berlitz не увольняют. Карл это, разумеется, пообещал. Сделка состоялась, и Карл начал увольнять своих. Это было как отрубать самому себе голову, если разобраться...

Карла уволили в 2002-м году, за день до Рождества, прямо посреди переговоров с тем же директором Майкрософта Анилом Сингх-Моларесом. В 2:30 пополудни зазвонил телефон, Карл извинился, вышел и уже никогда не вернулся. Вместо него через 15 минут пришел изящный Джим Фейган и вице-президент Лэрри Вейд. Джим сказал, что переговоры закончит он.

После себя Карл оставил фирму, голова которой была практическт отрублена, у руля стояли люди, которые довели до финансовой ручки Berlitz, а BGS для них был совсем уже чужим, поэтому сокращения и закрытия офисов стали буднями. За все время своего президентства Карл так и не научился с первого раза без запинки выговаривать слово "локализация" (с легкой руки Скотта Телфорда появился язвительный термин "лоКарлизация").

Мягкий Джим Фейган, в прошлом - пастор, стал новым CEO фирмы. Одним из первых его шагов стал прием на работу в качестве CFO Сары Боден - брюнетки с Уолл Стрит. Она получила карт-бланш, и воспользовалась им по полной программе: полгода бесцельно ездила по всему миру. Вернувшись в Парсиппани, Сара высочайше повелела увеличить обороты фирмы на 20 процентов, а прибильность - в два с половиной раза. Второй кардинальной переменой стала передача всей власти в фирме девелоперам. Теперь не локализация ставила девелоперам задачи, а 70 девелоперов диктовали двухтысячной фирме, как им делать локализацию. Многочисленные расплодившиеся директора (около 100!) наполнили фирму кучей "инициатив" и комитетов, которые мешали работать и оттягивали на себя финансы. Вообще, директора, конкурирующие в области генерации идиотских идей, чтобы доказать свою нужность - это страшная разрушительная сила, заслуживающая отдельной реплики. Может быть, когда-нибудь...

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

Большой Bowne тоже штормило: президент Боб Джонсон попался на скачивании на рабочий ноутбук детской порнографии откуда-то из Молдавии. Будучи пойман ФБРовцами, он попытался уничтожить улики. Забавно, что в бытность свою CEO, он рассылал по всей фирме строгие письма, запрещающие сотрудникам пользоваться рабочими компьютерами не по назначению... Ничего не напоминает?

Руководство Bowne, озабоченное падением акций, пришло к выводу, что что-то надо делать, и начало избавляться от подразделений (ничему люди не учатся). В 2005 году Джим Фейган продал непрофильный BGS за 198 миллионов долларов LioNBRIDGE - гораздо меньшей конкурирующей фирме. Нужно понимать, что это была не покупка, а продажа: от BGS просто хотели избавиться и, даже не уведомив, выставили на продажу и назначили цену. Продать готовы были хоть кому - хоть фирме по разведению чебурашек. Говорят, что было еще два покупателя, но больше 120 миллионов никто давать не хотел. А Рори (CEO Lionbridge) ради уничтожения главного конкурента залез в долги, но заплатил, сколько просили.

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