Новости Энциклопедия переводчика Блоги Авторский дневник Форум Работа

Декларация О нас пишут Награды Читальня Конкурсы Опросы
Автор
Страницы
Управление

Сказания о локализации — и не только

Еще один блог ГП

Подписаться на RSS  |   На главную

Выбор момента

Иногда пишут или посещают «в реале» замечательные, милые люди — разработчики ПО. Обычно ситуацию они обрисовывают очень быстро и четко: «У нас есть хорошая разработка (программа, портал, сервис), хотим ее продавать для зарубежной аудитории, нужна локализация». Начинаю тактично выяснять: «А что было сделано при проектировании для дальнейшей локализации — глоссарии, ресурсы, база терминологии, стандартный порядок составления документации». В 70-80% случаев выясняется, что это все было отложено на «светлое будущее», но «наши программисты прекрасно владеют языком, они перевели все пункты меню в интерфейсе». Тогда приходится честно сообщить: «Мне очень симпатичны вы и все, что вы делаете, но с локализацией вы дико запоздали. Теперь, кто бы ни занялся этим делом, сначала придется наверстывать упущенное, а упущена масса совершенно необходимых в качественной локализации этапов и очень много времени. Готовы к этому? Тогда давайте работать».

Иные удивляются: «А нам в компании N сказали — платите М денег, давайте исходники, и все будет без проблем в лучшем виде». Ну что тут остается делать? Вспомнить сотни бестселлеров, наших и зарубежных, угробленных на корню «русефекацией» и «локализацией»? Объяснить, что локализация без активного участия разработчиков — миф, видимость, мыльный пузырь, который лопается от первого же прикосновения  и любых проблем? На миг чувствую себя злодеем, рассказывающим первокласснику, что Деда Мороза не существует. Подавляю первый порыв откровенности, желаю удачи с N, приглашаю обращаться, если что-то не заладится. С некоторыми встречаемся снова через полгода, год, максимум два, начинаем работать — делать то, что следовало бы сделать еще года три-четыре тому назад. Да, в разработке ПО все происходит быстрее, чем в традиционной индустрии — люди быстрее наступают на грабли, быстрее начинают понимать, что им действительно нужно. На наше общее счастье, там обычно есть шанс наверстать то, что однажды было упущено.

Глубокое заблуждение — думать, будто локализация сводится к переводу слов одного языка на другой. Это можно делать, и некоторые так и поступают, но результат не будет продуктом, его нельзя продавать, а по большому счету не стоит и вообще людям показывать, чтобы не портить о себе впечатление. Локализация ПО — это прежде всего концепция, модель адаптации программы под другую ментальность. Перевод на другой язык в этом процессе — лишь одна из граней. Это не высшая математика, а совершенно естественный вывод, который сделает любой здравомыслящий человек, лишь немного задумавшись. И вот вопрос — почему эти элементарные вещи не объясняют там, где готовят разработчиков и управленцев для отрасли?


28 августа 2009 Andrew | 3 комментария


Люди и кошки

Computer-assisted/aided tools, CAT, в просторечии — «кошки». Они с нами уже давно, делают массу рутинной работы и, чего скрывать, изрядно облегчают жизнь. Почти любой переводчик хотя бы слышал о системах вроде Trados, DejaVu, SDLX, Transit, OmegaT..  Почему тогда столь полезные в хозяйстве «животные» до сих пор вызывают неоднозначную реакцию? Все дело в людях, в неоправданных ожиданиях одних и необоснованных опасениях других.

Не секрет, что в индустрии перевода кошки появились на свет и прижились как суррогат, заменитель интеллектуальных систем перевода, которые пока особых успехов не продемонстрировали. Даже лучшим представителям последних (aka Promt) требуется долгая тренировка и тщательный подбор материала, иначе интеллектуальная и недешевая программа уверенно выдает заказчику «гуртовщиков мыши» — и плевать хотела на то, что вообще-то речь в тексте идет о драйвере. Если затраты на подготовку и проверку перевешивают выигрыш от автоматизма и скорости, то и польза от такого ПО становится весьма сомнительной.

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

Проблемы начинаются тогда, когда кошек начинают использовать не по назначению. Бизнес воспринял этих забавных зверюшек как очередное средство оптимизировать затраты — большая ошибка. На первый взгляд, все вроде бы логично — если фраза или слово переведены однажды верно, то в дальнейшем можно просто подставлять перевод из кошкиных запасов всякий раз, как только нам встретится это слово или фраза. Экономится время, усилия и, главное, деньги. Так? Не совсем.

Переводятся не отдельные слова и фразы, переводится смысл целого. И чтобы перевод был корректным, не резал глаз и не раздражал читающих, он должен соответствовать окружению — контексту. Контекст многослоен, он состоит из ближайших фраз, абзацев, разделов, глав. Контекст изменчив — даже пара новых строк может потребовать пересмотра главы, где они добавлены, а то и глав, которые на нее ссылаются. Чтобы корректно донести смысл уже знакомой фразы в новом контексте, может потребоваться совершенно другая формулировка — новый перевод. Но вот загвоздка, только человек может определить, когда это необходимо делать — кошке такая мыслительная деятельность пока не под силу.

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

Людям же остается извечная человеческая обязанность, которую никто с них не снимал — анализировать материал и думать. Бездумная подстановка совпадений из баз — верный способ получить шлак в переводе на выходе, с кошкой или без нее.

Классический диалог между переводчиком (П) и менеджером проекта (МП):

МП: У нас новый материал, возьметесь?

П: Давайте посмотрим.

МП: Там 100к слов, из них 80к уже есть в нашей базе переводов. Мы сами ее собрали автоматическим совмещением из предыдущих версий. Нужно только доперевести недостающее. Базу мы предоставим, 100% подстановки проверять не нужно.

П: Знаете, я посмотрел(а) материал, с этой базой перевод может получиться очень неоднородным — единая терминология выдержана не во всех сегментах, есть и совсем случайные строки.

МП: Ну хотя бы насколько возможно. У нас сроки поджимают, и бюджет ограничен.

П: Хорошо, давайте попробуем, но, пожалуйста, имейте в виду, что качество будет хромать очень заметно. И обязательно запланируйте полную редактуру материала и аудит базы хотя бы на будущее.

МП: Да-да, спасибо, мы обязательно подумаем над этим.

Стоит ли говорить, что в 2/3 случаев ничего потом не происходит, документы сдаются, проекты успешно завершаются, а однажды попавшие в базу глупости и переводы, просто утратившие актуальность, так и кочуют из проекта в проект как переходящее знамя? Кошка ли в этом виновата? Нет, человеческий фактор и авральное планирование.

Еще раз, кошка — не средство сэкономить. Это, прежде всего, средство сделать более качественный продукт. Сделать его быстрее, точнее, логичнее и удобнее. За счет высокотехнологичного процесса превзойти конкурентов, затыкающих по старинке недоделки и бреши временными заплатами «до лучших времен». Вот затем, заложив надежную основу для качественного перевода/локализации, не грех воспользоваться и ее материальной отдачей в виде экономии, пускай в рамках проделанной работы это и окажется побочным результатом.


26 августа 2009 Andrew | 4 комментария


Награда ищет героя

Если когда-нибудь сообщество разработчиков ПО решит учредить и вручать награды за самую медвежью услугу отрасли, какую-нибудь золотую кастрюлю или фигу с «кристаллами Сваровски», у меня есть первый кандидат. Уже много лет испытываю страстное желание ласково поглядеть в глаза тому, кто первый придумал, что «документацию никто не читает».

Самое забавное — эта чушь и ересь, похоже, распространяется воздушно-капельным путем среди менеджеров, руководящих проектами разработки. В нашем отечестве зараза, кажется, не миновала никого. Документацию в результате большинство отечественных фирм-разработчиков составляет по остаточному принципу, подверстывая материалы к релизу в стиле _ну-ка-поглядим-что-у-нас-вышло_. Логика понятна — в процессе разработки вроде бы не до усилий, которые не дадут немедленного результата. Да и потом, чего стараться, если все равно «документацию никто не читает»?

Попробую вообразить на миг, что автор вышеупомянутого гениального изречения однажды увидит эти строки. Так вот, дорогой друг, у меня есть для тебя потрясающая новость! Документацию читают! Еще как читают, представь себе. Самое интересное — кто это делает. Таких, в основном, можно разделить на две категории:

1) Те, кто хочет разобраться, как же программа должна работать по задумке ее авторов.

2) Те, у кого с программой возникли проблемы.

Иными словами, это большинство думающих пользователей. А теперь угадайте с трех раз, кто из них останется пользователем программы, в которой «мануал» и «хелп» запутывают больше, чем помогают, или вообще слабо соответствуют тому, что человек видит на экране. У скольких из них появится желание заплатить за следующую версию?

Некоторые компании, переболев и наступив на все мыслимые грабли, все же начинают закладывать подготовку документации и системы помощи в этап проектирования, составлять словари/глоссарии базовых понятий,  учат разработчиков и технописов использовать именно ту терминологию, что введена в словарях, в общем, вкладываются в читаемость и понятность документации. Большинство, увы, так и продолжает энергично убивать сотни и тысячи рабочих часов на латание и перелатывание с каждой новой сборкой там, где проще отформатировать все и сделать заново по уму. Стоит ли удивляться только, когда наши передовые безо всяких кавычек продукты обходят на поворотах «непродвинутые» заграничные конкуренты с дружелюбным интерфейсом и понятной системой помощи?


25 августа 2009 Andrew | 6 комментариев



Page 3 of 3123