Корпоративный блог «Велиора» о бюро переводов и переводческой отрасли

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

Пример с хорошим концом

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

Что происходит в результате пренебрежения корректурой

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

Названия разделов на английском «Home» и «Shop» остались без перевода. Возможно, в немецком, сильно подверженном влиянию английского, оставлять эти слова без перевода допустимо, однако в русской версии сайта они выглядят весьма странно. Видимо, перевод был вставлен и/или проверен носителем немецкого языка, который посчитал, что раз «Home» и «Shop» допустимы в немецком, значит это справедливо для любого другого языка.

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

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

Несколько абзацев были составлены из предложений, которые мы изначально переводили как обособленные и не имеющие точек. В результате их объединения получились абзацы, выглядящие как одно очень длинное предложение, в середине которого периодически проскакивают слова с заглавной буквы.

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

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

1. Загрузите OmegaT с сайта SourceForge. Вам нужна последняя бета-версия в разделе Files > Latest. Загружать устаревшую стабильную версию едва ли имеет смысл, тем более бета-версии обычно полностью работоспособны. Выберите версию, соответствующую вашей операционной системе, обычно без Java (кроме случаев, когда Java у вас не установлена). В Windows установка и запуск OmegaT выполняются стандартным образом. В Linux достаточно распаковать загруженный архив и запустить скрипт OmegaT.
2. Далее необходимо включить проверку орфографии. Для этого выберите «Параметры» > «Проверка орфографии». Установите флажок «Автоматически проверять орфографию». Создайте папку словарей и укажите путь к ней в этом окне. Затем установите словари для ваших языков перевода. В отличие от некоторых других переводческих сред OmegaT проверяет орфографию непосредственно при наборе текста, что позволяет сразу же вводить слова правильно, вместо того чтобы возвращаться к замеченным впоследствии ошибкам.
3. Теперь установите Language Tool — средство проверки стиля и грамматики. Откройте страницу подключаемых модулей OmegaT на сайте SourceForge. Выберите Language Tool и загрузите последнюю версию. Language Tool является кроссплатформенной программой, следовательно, одни и те же файлы подходят как для Windows, так и для Linux. Создайте подпапку «plugins» в папке установки OmegaT и распакуйте в нее загруженный архив. Перезапустите OmegaT, выберите «Параметры» и установите флажок «Проверка языка». Замечания от Language Tool будут подчеркиваться синим по ходу перевода. Подробная инструкция содержится в идущем в комплекте файле Readme.
4. Далее аналогичную процедуру нужно проделать для подключаемого модуля Tokenizer (морфологии). Она улучшает функцию поиска нечетких совпадений и терминов в глоссарии, находя разные формы слова (множественное число и т. д). Загрузить ее можно с той же страницы подключаемых модулей OmegaT на сайте SourceForge. После распаковки все файлы опять же помещают в подпапку «plugins» в папке установки OmegaT. Если какие-то файлы там уже существуют, то их можно перезаписать. Запуск OmegaT с функцией морфологии требует создания и редактирования скрипта, что, впрочем, не представляет сложности. Необходимо создать отдельный скрипт для каждого языка оригинала. Например, если вы специализируетесь на переводе с английского на русский и переводе с немецкого на русский, то создадите скрипты для английского и немецкого. Для выполнения нижеуказанной инструкции понадобится прочитать эту страницу, содержащую все необходимые подробности.

java -jar OmegaT.jar %* –Itokenizer=org.omegat.plugins.tokenizer.SnowballEnglishTokenizer.

… OmegaT.jar” $* –Itokenizer=org.omegat.plugins.tokenizer.SnowballEnglishTokenizer

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

Меня периодически спрашивают о том, за счет чего «Велиору» удается поддерживать свои ставки за перевод на уровне выше среднего по отрасли, несмотря на высокую конкуренцию в сегменте переводов с английского на русский. Думаю, основная причина заключается в качестве. Вы можете сказать: «Постойте, только что речь шла о высокой конкуренции, разве она не предполагает автоматически высокое качество в этой паре?». Действительно, по логике вещей качество должно расти. Однако, судя по тем переводам, которые мне приходится проверять и просто использовать в качестве потребителя, этого не происходит. Таким образом, переводчик, заботящийся о качестве, существенно повышает свои шансы на успех. Какие конкретные шаги можно сделать в этом направлении? Исходя из своего редакторского опыта (несколько миллионов слов за последние пять лет) я могу предложить как минимум три основных точки приложения усилий.

1. Дословный перевод. Английский и русский языки настолько разные, что редкий текст допускает дословный перевод. В большинстве случаев дословный перевод выходит сложным для восприятия, туманным или даже странным. Несмотря на это, наша языковая пара сильно грешит такими переводами. Чаще всего это объясняется двумя следующими причинами (обе в моем понимании удивительны). Во-первых, сплошь и рядом бывает так, что переводчик отлично видит недостатки своего перевода, но ничего не может поделать из-за отсутствия желания, времени или способностей его поправить. Во-вторых, многие переводчики привыкли считать, что большего и не требуется, поскольку всегда выдают такое качество и редко получают отзывы. Задайтесь целью не позволять себе дословного перевода, и вы легко выделитесь из толпы!
2. Непонимание оригинального текста. Я все больше убеждаюсь в том, что понимание оригинального текста имеет определяющее значение для качества, и все больше удивляюсь тому, что некоторые переводчики так не думают. Для некоторых совершенно нормальным является перевод при полнейшем непонимании предмета всего текста и его отдельных деталей. В этой связи полезно помнить о том, что машинный перевод развивается весьма приличными темпами и начинает постепенно теснить брата-переводчика. Ключевым преимуществом переводчика над машиной является способность улучшать перевод именно за счет понимания текста. Лишите его этого преимущества, и грань между переводом человека и машины начнет стираться. Чем дальше развивается МП, тем больше усилий должен прилагать к пониманию текста переводчик, иначе не выдержит конкурентной борьбы. Развивайте в себе привычку разбираться в тексте и искать все непонятные моменты в Интернете, вместо того чтобы выдавать один туманный перевод за другим. Старайтесь не писать в переводе того, чего совершенно не понимаете.
3. Неиспользование средств автоматического контроля качества. Хотя такие программы, включая бесплатные ApSIC Xbench и CheckMate, существуют давно, многие переводы сдаются непроверенными. Один из наших заказчиков — агентств настолько устал от ошибок, которые легко выявляются автоматически, что ввел специальную политику наказания за них. Подобное ПО давно является неотъемлемой частью нашего процесса перевода, поскольку способствует качеству и экономит время, которое раньше уходило на проверку вручную. Я настолько к нему привык, что с трудом понимаю тех, кто не пользуется переводческими средами вообще или периодически: как же тогда выполнять автоматический контроль качества, для которого нужен двуязычный текст? При этом данные программы являются очень простыми в использовании, так что их освоение не займет большого труда, а результаты будут заметны уже с первого раза.

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

Метод обсуждения в штатных условиях

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

Трудности обсуждения с фрилансером

В случае внештатных переводчиков применение этого процесса по очевидным причинам затруднено. По моему опыту переводчик-фрилансер, как правило, остается в неведении относительно правок, вносимых в его перевод редактором. Например, этот вопрос поднимался в блоге о медицинском переводе, который ведет переводческое агентство ForeignExchange Translations. В нашей профессии это, скорее, правило, чем исключение, что вполне объяснимо: ведь сообщение правок отнимает много времени, не принося при этом прямой выгоды бюро переводов.

Те агентства, которые все-таки доводят правки до сведения переводчика, обычно просят редактора составить список правок, желательно с пояснениями, и отправляют его на проверку переводчику. Недостатком этого процесса является его формальный характер, из-за чего переводчик часто предпочитает отклонить как можно больше правок, опасаясь за свою репутацию в глазах агентства («Доверят ли мне другие проекты, после того как увидят, что этот перевод был сильно отредактирован?»). В отличие от неформального общения в штатных условиях, при обсуждении правок посредством электронной почты переводчику-фрилансеру сложнее объяснить, почему он в конкретном случае предпочел один перевод другому. «Сухой» список ошибок не оставляет свойственной неформальному общению возможности сгладить критику и в результате нередко вызывает у получателя лишь негодование и защитную реакцию («Как же так?! Я положил столько сил на «вылизывание» перевода, а по нему прошлись катком!»). Сравните этот вид взаимодействия с личным общением: когда переводчик выслушает предложения непосредственно от редактора, который в свою очередь терпимо отнесется к несогласию, переводчик с большей долей вероятности воспримет критику положительно, что позволит совместными усилиями улучшить перевод и сделать выводы из ошибок.

Считаете ли вы нужным сообщать ошибки переводчику? Стоит ли это времени и сил? Как, по вашему мнению, следует обсуждать правки с внештатными переводчиками?