Трудности перевода (Часть 2)

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

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

Анонимные методы, исключения, метаклассы – отличный способ поломать себе голову на предмет: "как это вообще может звучать по-русски?". Однако долго рассуждать "вообще", наверное, не стоит. Перейдем к конкретике.

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

Далее лексика, связанная с этим термином: catch exception, raise (re-raise) exception, handle exception. Предлагаю разобраться с нею повнимательнее.

catch exception – обычно переводят как "перехватывать исключение". При этом чаще всего речь идет о том, что приложение обнаруживает некий сбой аппаратного или программного обеспечения (читай: исключительную ситуацию).

raise exception – наверное, самое противоречивое словосочетание. В предыдущих случаях наше приложение реагировало на внешние факторы, а здесь уже идет речь об обработке ошибок, возникающих при выполнении некоего кода внутри системы. Исключительная ситуация возникает в процессе выполнения кода, который контролирует программист. Причем и степень "ошибочности" определяет разработчик. То есть понятно, что ваше приложение не может разделить на ноль или прочитать несуществующий файл, но вы в вашем приложении можете создать исключение (класс), которое будет реагировать на более безобидные вещи. Хоть на неверную длину строки, хранящей имя пользователя или еще что-нибудь в том же духе. В этом случае, код, который вы разработали, будет создавать класс исключения и вводить его в работу. И этот процесс обзывается raising the exception.

Наверняка вы сталкивались с таким вариантом перевода этого словосочетания, как "возбуждать исключение". Он такой… довольно распространенный. Мне кажется, что даже человека, регулярно общающегося с женщинами, должно коробить от такого;-)) Как тогда переводить "re-raise the exception"? Перевозбуждать исключение? Мне кажется, это уже ни в какие ворота;-)

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

Такая же неоднозначность, как мне кажется, присутствует, когда читаешь "handle the exception". В одной ситуации приложение обрабатывает системную ошибку (исключительную ситуацию), в другой – работает с классом исключения.

Exception – неоднозначный термин. Был бы он один такой, было бы проще. Увы, это не совсем так. Например, когда читаешь документацию в разделе Classes and objects, постоянно сталкиваешься со словосочетанием "class member", то есть, если переводить дословно, то это "член класса". Опять же… мы тут, в России, точно знаем, что члены, в основном, могут быть в партии;-) В классе же могут быть ученики, ну или, на худой конец, представители. И я лично очень благодарен человеку, писавшему документацию по Delphi, который включил туда фразу:

The fields, methods, and properties of a class are called its components or members.

То есть "Поля, методы и свойства класса называют его компонентами или членами". В противном случае, была бы еще одна головная боль – подбирать эвфемизмы для переводов.

О чем еще хочется упомянуть в этом контексте? На самом деле, о многом;-) Когда в процессе перевода сталкиваешься с понятием "class reference"… В девяти из десяти случаев предложение, в котором упоминаются такие вещи, настолько мудреное, что переводить можно хоть как "ссылка на класс", хоть как "метакласс" – для восприятия легче не будет. Чаще всего в результате перевода не может получиться предложения, которое сможет воспринять человек без специальной подготовки. То есть без стакана не разберешься. Так эта подготовка называется.

Комментарии по-прежнему приветствуются. Следующую часть "Трудностей перевода" следует ожидать видимо по мере приближения к дженерикам. Та еще песня будет видимо. За сим откланиваюсь. До новых встреч в эфире.