Трудности перевода или как не стоит делать локализацию ПО

    Идея этой небольшой статьи родилась, когда я рассказал хабраюзеру 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: Спасибо! Уже хватает, добавил в хаб «Переводы».
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 50
    • +17
      ПОТРАЧЕНО. Извините.
      • 0
        Ну всё правильно: переводим «заклирить» на армянский и получаем залихватскую метафору, чем не вариант?
        А если по теме, то примеры ошибок по качеству напоминают гуглоперевод.
        • +1
          Проблема в том, что метафора получается неверной — она бы больше подошла уровню Critical, чем Clear.
          • 0
            Гуглоперевод или перевод безграмотными переводчиками — российский IBM не сознается. Но факт остается фактом (проверил на нашей текущей версии софта), что они в итоге исправили где-то в 95% случаев на предложенный мной вариант.
          • +2
            Спасибо от жены — переводчика!
            • +1
              >Лингвистически Alert считать «аварией», быть может, не совсем верно, однако более корректный вариант «извещение» может запутать русскоязычного пользователя еще сильнее.

              Устоявшийся перевод — уведомление.

              PS С удовольствием бы почитал о том, какие есть типичные ошибки при переводе на английский.
              • +5
                А у меня, почему-то, устоялось — тревога… ) Видимо, со времен Red Alert — Красная Тревога))
                • 0
                  Да, я бы тоже перевел как тревога, и Red Alert тут не при чем.
                  Если Alert относится к «аварийной» группе, но слово «авария» уже занято словом Alarm, то «тревога» попросту подходит больше остальных вариантов.

                  А вариант «уведомление» не сильно отличается от «события», что только запутает всех.
                  • +2
                    «Alarm» — как раз «тревога». «Авария» больше подходит к «fault», «failure», «accident», и то — последнее не совсем из тематики, а для первых двух ближе к теме не «авария», а «неисправность». «Alert» — это «уведомление», «предупреждение».
                    • 0
                      Я исходил из того факта, что Alarm уже перевели как «авария».
                      Разумеется, если Alarm перевести правильно, то на долю Alert остается только «предупреждение», поскольку «уведомление» и прочие «извещения» в данном контексте не подходят.
                      • 0
                        Если учесть, что перевод «alarm» как «авария» сам по себе неправильный, то страдает вся цепь.
                        • +1
                          Зависит от контекста. Речь про систему Fault Management, суть которой в сборе от оборудования сообщений. Практически все сообщения (кроме «отбой» и сугубо информационных) — это некоторые аварии на оборудовании.
                          • +2
                            Это зависит от того, чем на самом деле являются те самые Alarm и Alert.
                            В подобных случаях переводить следует исходя из традиции перевода, если же традиции еще нет и ее надо создать, то переводить можно в широких пределах.

                            Здесь важен тот факт, что слова «Event — Alert — Alarm» идут в одной градации, и переводить всю тройку надо таким образом, чтобы они по-прежнему образовывали градацию, все остальное не так важно. Переводить в таких случаях лучше в соответствии с эмоциональной окраской слов, а не в соответствии со словарем. (Напомню, я рассматриваю вариант, когда традиции перевода еще нет)

                            Если Alarm означает состояние «сеть лежит», а Alert — «сеть щас упадет», то перевод «Событие — Тревога — Авария» является верным.
                            Если же Alarm означает состояние «сеть лежит или щас упадет», а Alert — «сеть немного лагает», то верным переводом будет «Событие — Предупреждение — Тревога».

                            Поскольку автор, как специалист, в статье назвал оба типа событий (и Alert, и Alarm) «аварийными», я склонился к первому варианту.
                            • 0
                              В системе нет деления между Alarm и Alert. Я даже, если честно, не уверен, что сейчас там слово Alarm где-либо используется. Но его используют люди эксплуатирующие оборудование, которое мне в систему шлёт события, потому что в контексте их оборудования есть слово Alarm.

                              Там даже забавнее всё. Любое событие — это Event, а хранятся эти events в таблице с названием alerts.status. Контекстное меню называется Alerts Menu, например. То есть даже Event и Alert становятся синонимичными в данном софте.

                              Я с вами согласен, если бы градация реально была, но ее нет. Вернее она есть, но посредством параметра Severity (который от Clear до Critical).
                              • 0
                                Не зная особенностей этого софта, я бы подумал, что Clear — это не степень серьезности события, а отмена ранее установленного приоритета.
                                • 0
                                  Зная софт, скажу, что это по сути отмена пришедшей ранее аварии. Типа приходит с Critical событие «интерфейс упал», а затем приходит с Indeterminate событие «интерфейс поднялся», оно коррелируется с первым по различным параметрам, и система обоим событиям ставит Severity = Clear.
                                  Это если совсем глубоко копнуть.

                                  Если будет интерес, могу как-нибудь рассказать про софт Netcool/Omnibus.
                                • 0
                                  Хм, значит, я вас неправильно понял.
                                  В таком случае эти три синонима можно переводить любыми другими синонимами в любом количестве.
                                  Возможно, лучше вообще обозвать их всех «событиями», если только это слово не слишком затаскано в других контекстах.
                                  • 0
                                    Я, быть может, и сам в комментариях уже где-то не совсем корректно высказался.

                                    Тут огромную роль еще играет то, как пользователи системы называют сущности, которыми она оперирует. Поэтому и выходит, что в системе все зовется событиями, а юзера называют, как кому взбредет в голову.
                    • 0
                      Извещение и уведомление — по сути синонимы.

                      Из забавного, есть такой технический термин AIS — Alarm Indication Signal, который в телекоммуникационном словаре Лингво переведен как «сигнал тревожной индикации». Я по использованию такого перевода отлавливал людей, которые не понимают, что такое на самом деле AIS.
                    • +3
                      Еще заметил интересный момент при переводе сообщений об ошибках. Может не нужно ошибки совсем переводить?
                      Например, локализованная версия .Net ругается на русском языке. И по русскому описанию ошибки очень мало информации в Интернет, чтобы устранить эту ошибку. При этом если перевести ошибку с русского обратно на английский, то появляется очень много ресурсов с упоминанием этой ошибки и решением проблемы. Но во многих случаях ошибку не удается перевести самому точно на английский, чтобы прийти к дословному оригиналу.
                      • 0
                        Я всегда ищу решение по коду ошибок. Иногда толковое решение может найтись на немецком или французском.
                        • 0
                          Не у всех ошибок есть коды. Более того, коды ошибок давно уже считаются плохой практикой. К сожалению, к отказу от кодов ошибок обычно должны прилагаться информативные сообщения, но они не у всех программистов получаются.
                          • 0
                            почему же?
                            • 0
                              Потому что ООП-шные исключения с их способностью у наследованию и возможностью обладания произвольными свойствами, дают куда большую гибкость, чем безликие коды ошибок. Ну, в теории.

                              На практике часта ситуация, когда исключение дает еще меньше информации, чем код ошибки.
                              Поубивал бы тех, кто пишет throw new Exception() в крупных проектах…
                      • +2
                        А меня сильно заминусуют, если я намекну на наличие ачипяток и несогласования падежей в статье? Кстати, зачастую огорчает в переводчиках неграмотность даже на родном языке. «Да я знаю английский, я всё переведу» — и получается на «русском» какой-то ад. Ничего личного, просто накипело.
                        • 0
                          Как баги есть в любой программе, так и опечатки есть в любой статье. И если их не столько на квадратный сантиметр экрана, что они начинают резать глаз — то в норме. (В норме != хорошо, но тем не менее).
                          • 0
                            Дописывал в три ночи, проверял, но, как водится, с первого раза не все углядел. Исправляю.
                          • +5
                            Имхо, все же некоторые языки не очень хорошо подходят для технической документации. Например, на украинском языке хорошо признаваться в любви, но вот техническая документация… это что-то с чем-то. Для знающих язык, как вам фраза «Двічі клацнути по пацючку, щоб з’явився шмигунчик»?

                            А вообще, после фраз «яйца на гусеничном ходу» и «щелчок по почкам», везде и всегда, если есть английские документация, интерфейс либо версия программы — пользуюсь только ими.
                            • +1
                              А что такое «яйца на гусеничном ходу»? Какие нибудь Tracked EGGs?
                              По поводу украинского. Я сейчас и говорить-то по-украински могу плохо, напарник говорит по-украински, я по-русски, пишем в багтрекер на каком попало языке и все всё понимаем. Так вот, когда я писал в университете лабораторную и препод потребовал по-украински, я «Отмену» перевёл как «Відмова». Потому что кажется, что «скасувати» можно только крепостное право.
                              • 0
                                А что такое «яйца на гусеничном ходу»? Какие нибудь Tracked EGGs?


                                Не, не угадали. В оригинале это trackball.
                                • +2
                                  На самом деле в оригинале «гениталии на гусеничном ходу»: www.finalfantasi.narod.ru/smeh/mouse.htm
                              • +2
                                Правда, исходя из того, что оказалось в финальном продукте, создавалось впечатление, будто российское подразделение IBM воспользовалось услугами самого дешевого в Москве бюро переводов, а те в свою очередь наняли самых безграмотных переводчиков.

                                а те, в свою очередь, воспользовались Промтом
                                • 0
                                  Очень может быть :)

                                  Интересно будет услышать мнение представителей IBM на эту тему. Жаль, я общаюсь только с инженерами и продавцами там, которые сами даже не знают, кто там у них в российском офисе локализациями занимается.
                                • 0
                                  «Активный список событий» еще может подразумевать, что есть множество списков событий, из которых один активный в данным момент веремени.
                                  • 0
                                    В данном программном продукте — нет. Может быть множество инстансов Active Event List, но это по сути вопрос отображения. Глобально в системе таблица с событиями одна, поэтому и список один.
                                  • 0
                                    Очень знакомая ситуация.

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

                                    Вот и получается иногда позорище, о котором всю жизнь вспоминать стыдно.
                                    • 0
                                      Как тут не вспомнить перевод «Clear cookies — ясные печенья».
                                      • 0
                                        Вспомнилось еще, как в русской локализации игры «Император Дюны» внизу одного из меню настроек была кнопка «Близко».
                                        • 0
                                          А что там в оригинале было-то?
                                          • +1
                                            Хм, очевидно, «закрыть»? Ну, в смысле — «close».
                                            • 0
                                              Я не очень представляю себе эту игру, поэтому как-то даже и не подумал о таком варианте :)
                                        • 0
                                          В этом изначально дурацком списке вместо Prioritize должно быть Priority, а вместо Clear лучше было б недвусмысленное Not set (и кружочек слева).

                                          image
                                          • +1
                                            Prioritize там именно потому, что суть это меню — это действие, изменение приоритета (степени критичности) события.
                                            С Clear нельзя ничего делать, увы, потому что названия (и их цветовое отображение тоже) степеней критичности, если память мне не изменяет, стандартизированы в рекомендации ITU-T X.733.
                                            Not Set тоже не вариант, ибо для других полей в базе такое значение используется, когда значение не задано, но незаданная степень критичности с лингвистической точки зрения и с точки зрения данной системы мониторинга — это значение Indeterminate.

                                            Ход ваших мыслей логичен. Просто в данном софте уже сложились концепции аж с 1998 года. Не думаю, что IBM решится из менять. Поэтому тут только локализации можно адаптировать, если есть необходимость ими пользоваться.
                                          • +1
                                            Я долго думал, что такое «гнездо» в документации на IBM Tivoli…
                                            И после этого, пошел читать английскую документацию
                                            • 0
                                              Я и не знал, что они и документацию переводят. Выглядит, будто им промт помогал.

                                              Кстати прекрасный пример, как не надо переводить документацию, когда в тексте дан перевод разделов меню, параметров и тд, а на скриншоте все в оригинале. Я в свое время долго и упорно боролся с бюро переводов, когда они заставляли переводить схожий текст в документации, хотя сам софт/железо не было локализовано, и соответственно в нем-то все оставалось на английском.
                                              • 0
                                                В данной ситуации скриншот непереведенного окна — просто спас.
                                                Я действительно не мог понять, что за гнездо имеется ввиду…
                                                • 0
                                                  Кстати забавно, что они сокет перевели, а TCP не перевели на русский :)
                                                  • 0
                                                    я даже затруднился представить варианты перевода!
                                                    • +2
                                                      ПУП (Протокол Управления Передачей)
                                                      TCP Socket = гнездо пупа

                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.