Блеск и нищета переводной литературы
— Лучше вообще не читать, чем такое.
Часто ли вы читаете техническую литературу? Именно литературу, а не мануалы на хабре или багрепорты на гитхабе? А когда читаете, на каком языке предпочитаете это делать (если есть возможность выбирать, конечно)? Какую версию предпочтёте, русскоязычную или англоязычный оригинал?
В некоторых кругах бытует отдающее снобизмом и элитаризмом мнение, что читать (смотреть кино, играть в игры) стоит только на языке Шекспира и никак иначе. Многим же другим довольно сложно проверить первых на тему того, просто ли они зазнаются или с переводной тех.литературой есть какие-то серьёзные проблемы. Банально по причине плохого владения языком оригинала.
Ещё сложности добавляет область знаний, вокруг которой это всё происходит. Частенько нелегко распознать границу, где непонимание сложных структур данных или новых методологий разработки самих по себе переходит в непонимание того текста, который сочинил переводчик. Вот, например, цитата из одной довольно свежей книги:
В старших классах он начал создавать динамические веб-сайты, когда интернет был еще относительно молод. Затем он перешел к разработке программного обеспечения для отрасли здравоохранения и телекоммуникаций в местной компании, изучая информатику в университете Любляны, Словения. В конце концов, он перешел на работу в Red Hat, первоначально разрабатывая реализацию с открытым исходным кодом API Google App Engine, в которой использовались продукты Red Hat среднего уровня JBoss. Он также работал или участвовал в таких проектах, как CDI/Weld, Infinispan/Jboss DataGrid и др.
С конца 2014 года он является частью команды Red Hat Cloud Enablement, где его обязанности включают в себя обновление новых разработок в Kubernetes и связанных с ними технологий и обеспечение максимального задействования возможностей Kubernetes и OpenShift в программном обеспечении компании среднего уровня.
Если у вас ничего не заболело от пассажа «первоначально разрабатывая реализацию с открытым исходным кодом 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.
Оказывается, на самом деле, это не компания среднего уровня. А речь идёт о связующем ПО компании. И никто не заставлял его «обновлять новые разработки» — на самом деле, ему нужно постоянно находиться в курсе всех новых разработок.
Или вот другой пример, из другой книги:
В 2007 году я связалась с руководством Yahoo по поводу позиции, которая относилась «немного к разработке» и «немного к эксплуатации». Речь шла о вакансии старшего сервисного инженера, ответственного за создание и обслуживание мультиарендованного, размещенного на хосте, распределенного и географически реплицированного хранилища данных типа «ключ/значение» под названием Sherpa.
«Мультиарендованного, размещенного на хосте, распределенного и географически реплицированного хранилища данных» — вы можете сходу понять, что именно значит это месиво, или придётся сначала переводить обратно на английский, чтобы осознать, какие именно привычные термины были так залихватски локализованы на великий и могучий?
Помогает ли это простому усвоению знаний? Честно говоря, не очень. Хочется ли тратить немалые, в общем-то, деньги на густые лингвистические джунгли, в глубине которых скрыта хибара с заветными глиняными табличками? Не хочется. Хочется другого: иметь доступ к набору простых и понятных текстов, самой сложной частью которых были бы излагаемые автором идеи, а не выстроенные переводчиком странные языковые конструкции.
Пытаемся разобраться, почему так вышло
Как так получилось? Всегда ли так было? Можем ли мы как-то избежать подобных казусов в будущем? Вопросы низкого уровня языковой компетенции я бы предложил оставить за рамками данного обсуждения, т.к. на него непосредственно мы практически никак не можем повлиять. Просто бывают хорошие переводчики, а бывают не очень. Как и программисты. И стоматологи. И вообще кто угодно.
Но какие дополнительные сложности встречают даже серьёзно подкованных в обоих языках билингвов, когда они решаются заняться переводом ИТ-литературы? Информационные технологии за последние 10–15 лет очень сильно выросли, как горизонтально, так и вертикально. Новых профессий огромное количество, у каждой своя отдельная специализация. Благодаря языковой инерции человеческого восприятия во многих смежных профессиях используются одни и те же термины, которые, однако же, несут разный смысл. И для того чтобы понять, как правильно использовать и переводить тот или иной термин, нужно не просто хорошо владеть языком, но и неплохо разбираться в конкретной сфере и подразделах информационной отрасли.
Грубо говоря, вместе с тем, как перестал существовать универсальный вид «программиста» (который и сервак поднять, и скрипт написать, и кондёр в материнке перепаять), перестал существовать и универсальный «технический переводчик». Поэтому теперь уже недостаточно быть «просто переводчиком». Очень неплохо бы быть, в первую очередь, техническим специалистом, который в качестве дополнения хорошо владеет языками. А это, как вы понимаете, уже совсем другая история. Не все хорошие технические специалисты в достаточном объёме обладают языковыми навыками. А если и обладают, им далеко не всегда интересно заниматься подобного рода работой — их больше привлекают технические достижения, чем гуманитарные.
«А раньше, раньше-то как хорошо было!» ©
Сейчас распространена методология «переводов» новых слов путём простой подстановки уже имеющегося англицизма. Например, коммит (более-менее нормальный перевод «фиксация» уже практически повсеместно вытеснен), билд, деплой — список можно вести бесконечно. Скорее всего, такая ситуация сложилась из-за ускорения темпа появления новых технологий. Перевод же, как и любая другая реактивная система, просто не может поспевать за заданным темпом. И к тому времени, когда какой-либо текст дошёл до перевода профессионалами, технарями уже сформирован глубоко пустивший корни жаргонизм — и перевод термина «commit» словом «фиксация» будет резать глаз читателю.
Но это совершенно не значит, что с подобной ситуацией надо мириться! Есть отличные примеры качественного, глубоко продуманного перевода. Из примеров можно взять «thread» — «поток». Дословный перевод — «нить» — позволяет предположить, что, скорее всего, на заре формирования англоязычной терминологии это была ассоциация с ткацким станком с кучей параллельно натянутых нитей. В русском же языке «выполнение в несколько нитей» звучит очень непонятно, а вот «выполнение в несколько потоков» — уже совсем другое дело. Тут и семантика сохранена, ведь поток — это постоянное движение (вычисление), чего нет у нити. И звучит вполне привычно («по автостраде автомобили движутся в несколько потоков»).
Еще один пример удачно локализованного термина — «pipeline» = «конвейер». «Pipeline» — это трубопровод, суть термина (rendering pipeline, CI/CD pipeline) заключается в процессе обработки, где на каждом узле происходит какое-то действие: в зависимости от условий могут закрываться-открываться «вентили» и обработка идет через другую «трубу». На протяжении всего «трубопровода» могут быть расставлены какие-то «датчики», контролирующие процесс. Слово подобрано очень удачно, но прямой перевод, «трубопровод отрисовки» звучит недостаточно лаконично. «Конвейер» в этом случае — идеально подобранное слово, разве что с другим оттенком (convey — передавать, а по трубам «само течет»), но без потери основного смысла.
Как дальше жить?
Что предлагаем мы со своей стороны? Мы предлагаем тот самый уникальный сплав технических компетенций с качественными языковыми навыками. Мы готовы выделять время наших технических специалистов на доведение смыслового содержимого переводимых текстов до идеального состояния.
В процессе работы над переводами нам приходится достаточно много времени проводить в дискуссиях на тему того, как локализовать те или иные термины. В связи с этим было бы неплохо начать собирать общий глоссарий новой терминологии, для последующего применения и в собственных переводах, и в переводах коллег по цеху. Глоссарий этот должен быть не просто набором слов; он, прежде всего, призван объяснять, почему выбран именно такой термин, чем он лучше аналогичных, как он вписывается в языковой контекст — ну, и нашу техническую традицию. Без слепого и бездумного калькирования зарубежной терминологии.
Именно таким глоссарием мы и планируем заняться. Для начала, видимо, это будет серия статей с обзором подборок терминов, истории их появления и развития, а также объектов, за ними стоящих. Впоследствии все выпускаемые нашим издательством книги будут сопровождаться отдельным разделом, содержащим описание того, как мы работали над используемой в каждой конкретной книге или статье терминологией. По мере набора материала, вероятно, будет выпущено отдельное издание на тему проблем русского языка в современном информационно-техническом переводе. Ну, а пока вы можете оформить предзаказ на нашу первую книгу «Проектирование событийно-ориентированных систем» Бена Стопфорда.
А какие у вас есть мысли насчёт ситуации в переводной технической литературе? Есть ли какие-то особенно дорогие сердцу термины, которые, на ваш взгляд, были отлично переложены на русский язык? Или, может быть, есть особенно ненавистные? :)
