Хабрахабр

Блеск и нищета переводной литературы

— Лучше вообще не читать, чем такое.

Именно литературу, а не мануалы на хабре или багрепорты на гитхабе? Часто ли вы читаете техническую литературу? Какую версию предпочтёте, русскоязычную или англоязычный оригинал? А когда читаете, на каком языке предпочитаете это делать (если есть возможность выбирать, конечно)?

Многим же другим довольно сложно проверить первых на тему того, просто ли они зазнаются или с переводной тех.литературой есть какие-то серьёзные проблемы. В некоторых кругах бытует отдающее снобизмом и элитаризмом мнение, что читать (смотреть кино, играть в игры) стоит только на языке Шекспира и никак иначе. Банально по причине плохого владения языком оригинала.

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

Затем он перешел к разработке программного обеспечения для отрасли здравоохранения и телекоммуникаций в местной компании, изучая информатику в университете Любляны, Словения. В старших классах он начал создавать динамические веб-сайты, когда интернет был еще относительно молод. Он также работал или участвовал в таких проектах, как CDI/Weld, Infinispan/Jboss DataGrid и др.
С конца 2014 года он является частью команды Red Hat Cloud Enablement, где его обязанности включают в себя обновление новых разработок в Kubernetes и связанных с ними технологий и обеспечение максимального задействования возможностей Kubernetes и OpenShift в программном обеспечении компании среднего уровня. В конце концов, он перешел на работу в Red Hat, первоначально разрабатывая реализацию с открытым исходным кодом API Google App Engine, в которой использовались продукты Red Hat среднего уровня JBoss.

Если у вас ничего не заболело от пассажа «первоначально разрабатывая реализацию с открытым исходным кодом API Google App Engine», то уж наверняка возникли вопросы на тему того, о какой именно «компании среднего уровня» вдруг пошла речь. Или что, например, значит «обновление новых разработок». Обратимся к тексту оригинала:

Since late 2014, he has been part of Red Hat’s Cloud Enablement team, where his responsibilities include staying up-to-date on new developments in Kubernetes and related technologies and ensuring the company’s middleware software utilizes the features of Kubernetes and OpenShift to their full potential.

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

Или вот другой пример, из другой книги:

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

«Мультиарендованного, размещенного на хосте, распределенного и географически реплицированного хранилища данных» — вы можете сходу понять, что именно значит это месиво, или придётся сначала переводить обратно на английский, чтобы осознать, какие именно привычные термины были так залихватски локализованы на великий и могучий?

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

Пытаемся разобраться, почему так вышло

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

Информационные технологии за последние 10-15 лет очень сильно выросли, как горизонтально, так и вертикально. Но какие дополнительные сложности встречают даже серьёзно подкованных в обоих языках билингвов, когда они решаются заняться переводом ИТ-литературы? Благодаря языковой инерции человеческого восприятия во многих смежных профессиях используются одни и те же термины, которые, однако же, несут разный смысл. Новых профессий огромное количество, у каждой своя отдельная специализация. И для того чтобы понять, как правильно использовать и переводить тот или иной термин, нужно не просто хорошо владеть языком, но и неплохо разбираться в конкретной сфере и подразделах информационной отрасли.

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

«А раньше, раньше-то как хорошо было!» (с)

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

Есть отличные примеры качественного, глубоко продуманного перевода. Но это совершенно не значит, что с подобной ситуацией надо мириться! Дословный перевод — «нить» — позволяет предположить, что, скорее всего, на заре формирования англоязычной терминологии это была ассоциация с ткацким станком с кучей параллельно натянутых нитей. Из примеров можно взять «thread» — «поток». Тут и семантика сохранена, ведь поток — это постоянное движение (вычисление), чего нет у нити. В русском же языке «выполнение в несколько нитей» звучит очень непонятно, а вот «выполнение в несколько потоков» — уже совсем другое дело. И звучит вполне привычно («по автостраде автомобили движутся в несколько потоков»).

«Pipeline» — это трубопровод, суть термина (rendering pipeline, CI/CD pipeline) заключается в процессе обработки, где на каждом узле происходит какое-то действие: в зависимости от условий могут закрываться-открываться «вентили» и обработка идет через другую «трубу». Еще один пример удачно локализованного термина — «pipeline» = «конвейер». Слово подобрано очень удачно, но прямой перевод, «трубопровод отрисовки» звучит недостаточно лаконично. На протяжении всего «трубопровода» могут быть расставлены какие-то «датчики», контролирующие процесс. «Конвейер» в этом случае — идеально подобранное слово, разве что с другим оттенком (convey — передавать, а по трубам «само течет»), но без потери основного смысла.

Как дальше жить?

Что предлагаем мы со своей стороны? Мы предлагаем тот самый уникальный сплав технических компетенций с качественными языковыми навыками. Мы готовы выделять время наших технических специалистов на доведение смыслового содержимого переводимых текстов до идеального состояния.

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

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

Есть ли какие-то особенно дорогие сердцу термины, которые, на ваш взгляд, были отлично переложены на русский язык? А какие у вас есть мысли насчёт ситуации в переводной технической литературе? 🙂 Или, может быть, есть особенно ненавистные?

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»