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

Немного предыстории

В студенческие годы я подрабатывал внештатным переводчиком в одном из бюро переводов Москвы. Занимался я в основном переводами по тематике своего образования, то есть переводил всё, что было связано с отраслью связи и телекоммуникациями. Платили по рыночным меркам мало, но как студента меня это тогда вполне устраивало.
Вся работа бюро переводов сводилась к тому, чтобы набрать заказов как можно больше, а затем распределить это между несколькими переводчиками. По сути некий вид краудсорсинга получался. Основным объектом лингвистических издевательств становилась документация на программное обеспечение или оборудование. Самыми яркими примерами в моей памяти остались перевод документации на SDH/PDH оборудование Huawei и перевод документации на платформу Comverse. Сотрудников компаний-заказчиков мне искренне жалко, и сейчас я расскажу, почему.

Получало бюро переводов, скажем, заказ на перевод 1000 страниц с английского на русский документации к какому-либо софту или железу. Далее этот объем работ распределялся в зависимости от нагрузки конкретных переводчиков (и в зависимости от их средней скорости выполнения перевода) где-то среди 10-20 человек. Затем проводилась встреча, на которой переводчикам раздавался некий словарь терминов, чтобы исключить случаи разных переводов устоявшихся терминов и/или выражений.
У данной стратегии был несомненный плюс — работа корректора заметно облегчается, когда 20 человек не переводят одно и то же слово по-разному. Однако, чтобы всё это работало, как надо, необходимо было выполнение двух простейших условий:

• словарь терминов должен содержать корректные переводы этих самых терминов;
• переводчики должны им пользоваться.

А что получалось на практике? На практике сразу же нарушалось первое условие. В качестве словаря терминов товарищи использовали глоссарий из русскоязычной версии книги Cisco Press про основы построения сетей. Замечательная книга для начинающих. Только у нее был один недостаток. Думаю, вы уже догадываетесь, какой. Правильно — у нее был ужасный перевод на русский. Глоссарий по количеству ошибочного перевода на одну страницу превосходил все остальные книги этот издательства, выпущенные на тот момент. Сейчас, когда я пишу строки, у меня закрадывается мысль, что саму эту книгу переводили тем же краудсорсинговым методом, который я описываю. Такая своего рода рекурсия с глубоко отрицательной обратной связью в контексте качества перевода.
Второе условие тоже нарушалось, но уже ввиду человеческого фактора. Переводчики делились на тех, кто просто игнорировал словарь терминов (никак не аргументируя свои действия), и тех, кто понимал весь ужас ошибок в этом словаре и предпочитал все-таки делать качественный перевод. Я ни раз указывал коллегам по цеху на ошибки в их словаре, но сорокалетние лбы были не склонны верить двадцатилетнему студенту.
Как только перевод частей документации был готов, корректор-редактор собирал всё это вместе. Платили ему ещё меньше (ибо не за количество символов, а за время, и всё время подгоняли), поэтому качество финального текста было в большинстве случаев ужасное. Одни раз я сам поработал корректором и зарекся этим больше заниматься после суток работы, потому что в половине случаев приходилось брать оригинал и переводить текст полностью заново.

Единственным блёклым лучом света в темном царстве ужасной переводческой машины был главный редактор этого бюро. Сам он ничего по тематике телекоммуникаций не переводил (и это к лучшему), однако всегда повторял, что им нужны специалисты в той или иной отрасли со знанием языка, а не простые люди, закончившие переводческий факультет. Увы, не все специалисты одинаково хорошо знали не то, чтобы английский, но и русский язык. Как показывало дальнейшее общение с ними, далеко не все специалисты оказывались специалистами.

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

IBM — великий и ужасный

В далеком 2004 году я отошел от технической поддержки оборудования Cisco и построенных на нём решений и переключился на задачи мониторинга сетей. Так я впервые познакомился с программными продуктами Micromuse Netcool, которые в 2006 году стали частью линейки ПО IBM Tivoli. Мой текущий работодатель является активным пользователем, если так можно выразиться, систем Fault и Perfomance Management от компании IBM, поэтому вот уже практически четыре года я принимаю активное участие в закрытых бета-тестированиях того ПО, которое у нас стоит.

В определенный момент, выпустив новую версию веб-портала системы мониторинга Netcool/Omnibus WebGUI, в IBM решили, что портал должен быть локализован. Про то, что языковое предпочтение пользователя они определяют исключительно посредством USER_AGENT броузера, я рассказывать особо не буду. Эта тема достойна отдельной песни с матерными словами.

То, как компания IBM выполнила перевод, является очень хорошим примером, как не надо делать локализации. В процессе бета-тестирования выяснилось, что за перевод на русский язык отвечали сотрудники российского подразделения IBM. У них там даже был менеджер проекта по переводу ПО с кандидатской степенью. Правда, исходя из того, что оказалось в финальном продукте, создавалось впечатление, будто российское подразделение IBM воспользовалось услугами самого дешевого в Москве бюро переводов, а те в свою очередь наняли самых безграмотных переводчиков.

Все косяки перевода приводить, думаю, смысла нет. Вряд ли читать десяток страниц кому-либо будет интересно. Приведу в качестве примеров лишь самые яркие моменты.

Виды и членства

Мы все привыкли, что пункт меню View переводится как «Вид». В IBM решили иначе и перевели его как «Представления». Именно из-за этого раздел портала View Membership перевели как «Членство в представлениях». Тут надо сказать, что перевод последней фразы даже для знающих контекст достаточно сложен. С одной стороны, View в меню приложения — это «Вид», с другой — раздел портала относится к управлению сущностями под названием View и определяет, какие компоненты страницы будут являться элементами этой сущности. Поэтому наиболее логичным переводом было бы «Элементы представлений». Этот один из тех случаев в техническом переводе, когда литературный перевод лучше, чем дословный.
Я даже провел эксперимент, показав коллегам, работающим с этим ПО, раздел портала на русском. Ни один из них не понял, о чём речь, хотя с английской версией портала они прекрасно работают и по сей день.

Богатство языка

Можно долго спорить о том, какой язык более богат — русский или английский. Я не филолог и даже не лингвист, поэтому правильного ответа на этот вопрос я, увы, не знаю. Однако часто сталкиваюсь с ситуациями, когда простое сочетание английских слов каждый переводи на русский язык по-разному. Есть в Netcool/Omnibus апплет/приложение под названием Active Event List. Одно название вызывает проблемы с переводом, причем не только на русский, но и на немецкий, знание которое позволило мне сравнить с немецкой локализацией.

Не только я, но и немецкие пользователи во время бета-теста заметили, что трактовка может быть двоякой. «Список активных событий» или «активный список событий» — оба вариант, на самом деле, вводят в заблуждение.
«Список активных событий» подразумевает, что есть неактивные события. А где же они, и где их список? (Правильные ответ — в другом программном продукте компании IBM, посвященном исторической отчетности). Событие по своей сути перестает быть активным (текущим) только тогда, когда оно удаляется из системы, то есть тогда, когда проблема его вызвавшая устранена.
«Активный список событий» — тут сложно понять, что можно вложить в такой вариант перевода, кроме того факта, что события в списке могут динамически изменяться. Однако они делают это и в других представлениях, что делает подобную дифференциацию некорректной, а называть список событий интерактивным (что ближе к истине) опять же может лишь запутать пользователей.
Я предложил коллегам из IBM просто переименовать Active Event List в русской локализации в «Список событий». Увы, это одно из немногих изменений, которые они в итоге не внедрили, оставив вариант «Список активных событий».

Вообще в софте изначально была заложена небольшая лингвистическая бомба. Так как речь про систему пассивного мониторинга, которая получает от оборудования различные информационные сообщения о тех или иных состояниях и проблемах, то в системе исторически умудрились использовать аж три слова для обозначения таких сообщений — Event, Alert и Alarm. Если Event можно смело переводить как «событие», то Alert/Alarm — это уже «авария». Лингвистически Alert считать «аварией», быть может, не совсем верно, однако более корректный вариант «извещение» может запутать русскоязычного пользователя еще сильнее.

Степень критичности

Есть в Netcool/Omnibus понятие «степень критичности аварии» (Severity level) с возможными значениями Clear, Indeterminate, Warning, Minor, Major и Critical. Есть собственно раздел контекстного меню, где эту степень можно в ручном режиме изменить. Чтобы не быть голословным, приведу скриншот того, как это выглядит в английской версии ПО:

Слова все очевидные, но надо ж им было всё перевести, поэтому перевели и их. В итоге эти шесть значений были переведены разными частями речи: где-то существительным, где-то прилагательным, слову Сlear вообще глагол достался. Его перевели как «очистить» (что в концепции софта неверно, ибо это как бы не действие, но правильный вариант с прилагательным или существительным я так и не придумал).
К сожалению, в русском языке слова имеют род, а прилагательные склоняются по родам. Уж не знаю, по какой причине в первой версии локализации этого ПО пункт меню назвали «Увеличить приоритет» (хотя меню это позволяет его и уменьшать), а вот значения этого приоритета в тех местах, где использовались прилагательные, оказались женского рода. Ни слово «приоритет», ни слово «событие» не принадлежат к женскому роду. К нему принадлежит только слово «авария», но вот незадача — нигде в интерфейсе системы слово «авария» не использовалось.

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

Кстати в первой версии локализации пункт Suppress/Escalate почему-то перевели как «Подавить/Расширить». Мы с коллегами долго смеялись, что именно они нам предлагают расширять, и почему слово Suppress не перевели как «Сузить». Так хотя бы стало симметрично неправильно.

Маленькая такая мораль

Вернее, даже две.

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

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

Курьезы использования английских слов

Опыт показывает, что людям куда проще один раз запомнить английские термины и ввести их, скажем, обрусевшие варианты в обиход, чем понять, что там переводчики наделали. В контексте уже не раз упомянутого выше ПО все понимают что-то типа «клир-аварии», «заклирить», «поклирить» и т.д. Недавно я читал для коллег из СНГ тренинг в Армении. Только в конце пятого дня тренинга мне рассказали, что по-армянски «клир» — это, простите, самый неприличный вариант обозначения мужского полового органа.

PS: С удовольствием добавил бы топик в хаб «Переводы», но увы не хватает того, о чём тут нельзя говорить.
UPD: Спасибо! Уже хватает, добавил в хаб «Переводы».

Автор: Beerlander

Источник