Сделано в России

Нужен ли перевод технической литературы на русский язык?!
Часть 2

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

• *Алексей Резниченко, один из первых главных редакторов журналов “Мир Oracle”/Oracle Magazine-RE
• *Петр Полтавский, разработчик ПО, компания «СиДжи Прожектс»
• *Леонид Рейнгольд, главный специалист Управления земельными ресурсами, г.Владимир
• *Игорь Мельников, Oracle 8i/9i Certified Professional DBA, группа компаний TopS Business Integrator

Предваряя обсуждение, я хочу сказать несколько слов о том, что наши сегодняшние авторы несколько сузили проблему, сведя ее только к документации по Oracle. С документацией почти все ясно – ее приобретают (кстати, за большие деньги!) те организации, которые уже прочно и осознанно встали на платформу Oracle, которые планово учат или заставляют заниматься самостоятельно своих сотрудников.

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

Вопрос был поставлен шире – о переводах технической литературы, в частности, конечно, книг по Oracle, но не являющимися документацией. Это относится к учебным заведениям, к этапам выбора платформы, к просто ознакомительным мероприятиям и работе людей, которым документация не доступна, избыточна или уже не достаточна по уровню квалификации. Хороший пример – книга Тома Кайта “Oracle для профессионалов”. Положа руку на сердце, спросим себя, кто из нас попытался получить эту замечательную с Запада, заплатив валютой раза в 3-4 больше, чем в через пару лет рублях и в очень приличном переводе?!

Далее, первая глава упомянутой книги Кайта написана в форме (почти) философского эссе. Я уверен, что у Вас, мой конкретный оппонент, хватит языковой квалификации, чтобы понять, что говорит Кайт, но у всех ли такая подготовка? И второй попутный вопрос. А хватит ли у Вас времени и терпения, желания и удовольствия прочесть эту главу на английском языке? Не в обиду будь сказано, на языке, который не является повседневным, и используемым исключительно в профессиональных целях, собственно процесс чтения, мне так кажется, замедляется в несколько раз, а времени у всех нас так мало.

А.Бачин,
главный редактор "Oracle Magazine/русское Издание"

 Алексей Резниченко,
аналитик и технический писатель компании Кворум,
один из первых главных редакторов
журналов “Мир Oracle”/Oracle Magazine-RE

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

1. Полнота русской терминологии. В идеале не должно быть ситуации разрыва, когда есть английский термин, а русского нет. Такой ситуации практически не избежать, но надо стремиться ее минимизировать настолько, насколько это возможно.
2. С проблемой полноты русской терминологии тесно связана проблема оперативности переводов. Может быть, имеет смысл эти проблемы несколько развязать. Например, несколько лет тому назад РДТЕХ выпустил пресс-релиз о том, что он перевел основные книги по Oracle 9i, а уже или только что был выпущен Oracle 10g, или было объявлено, что он вскоре выйдет. На лицо – отставание, причем существенное – разрыв на целую версию. Мне кажется, что в подобной ситуации надо было быстро составлять и опубликовать в Интернете словарик новых терминов выходящей версии, в том числе и с расчетом на реакцию специалистов (!), так как переводы книг документации не могут быть очень оперативными, даже если этот процесс ускорить в 2-3 раза.
3. Качество и оперативность переводов и их доступность. Сейчас программные продукты быстро и легко доступны, а русская документация появляется со значительным опозданием, иногда через один-два года, когда описанные версии продуктов уже отчасти устаревают, сама же документация нередко не лучшего качества и дороговата ... Ничего удивительного, что очень многие специалисты на русскую документацию и не смотрят.

В целом я не вижу сейчас особой специфики с переводами документации по Oracle. Вспомним времена ЕС ЭВМ лет 20 тому назад. Плохо составленная (или вернее плохо переведенная) документация по ПО машин этой серии, отсюда желание иметь комплект оригинальной документации IBM. Но при всех прочих равных, даже если переводы уступают (но не много!) оригиналу, люди и тогда, и сейчас предпочитают свой язык.

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

 Петр Полтавский,
разработчик ПО
компания: www.cgprojects.ru,
www.ppol.newmail.ru

Нужен ли перевод технической литературы на русский язык?! Безусловно, нужен. Поскольку спрос на такого рода услуги существует, то очевидно, что работы по выполнению переводов на русский язык удовлетворяют потребности определенной группы российских IT-специалистов. Другое дело, каковы перспективы и тенденции развития такого рода проектов. На мой взгляд, доля специалистов, использующих техническую литературу на языке оригинала (как правило, на английском) возрастает по отношению к общему количеству читателей. Сам я также предпочитаю работать с оригинальным вариантом документации (в этом смысле я разделяю мнение участника дискуссии С. Д. Кузнецова). Но одно не исключает другое. Профессионально выполненный (и что не мало важно, своевременный) перевод того или иного материала всегда найдёт своего читателя.

  Леонид Рейнгольд,
главный специалист
Управления земельными ресурсами,
г.Владимир

Вопрос о необходимости перевода технической литературы представляется актуальным. Однако на эту проблему можно посмотреть и шире. Ведь язык для специалиста – не просто средство выражения мысли – это основа построения модели объекта.

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

Кроме того, нужно учитывать различия в менталитете специалистов. По моему субъективному и несколько утрированному впечатлению (судя по содержанию известной мне литературы), у нас специалист ожидает получить компактный и внятный текст, ориентированный на понимание. Зарубежная литература очень часто – это фолианты с указаниями о последовательности нажимания кнопок. Хотя, конечно, бывают исключения – одно из наиболее ярких – книга Тома Кайта по Oracle, как раз ориентированная на формирование понимания поведения читателем описываемого объекта.

Конкретный пример не из сферы баз данных. Когда мой сын учился в школе, ему потребовалось освоить Autocad в степени, достаточной для подготовки чертежей (не самых простых) для авиамодельного кружка. В магазине я обнаружил несколько переводных книг, размером по два кирпича каждая и ценой от 500 до 1000 рублей. Однако, на первый случай я решился ограничиться учебником для МИФИ на эту тему за 50 рублей и на примерно 200 листах бумаги, похожей на газетную. Сказал, что пусть определится с потребностями и если понадобиться, – куплю любую другую, которую он мне покажет. Оказалось, что другой книжки и моих консультаций практически не понадобилось. Наличия интереса и студенческого учебника оказалось достаточно для восприятия программного продукта, как системы. А детали оказалось вполне возможным получить из контекстной помощи, в том числе и англоязычной, и доступных примеров.

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

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

 Игорь Мельников,
Oracle 8i/9i Certified Professional DBA,
группа компаний TopS Business Integrator (www.topsbi.ru).

При ответе на вопрос: "нужно ли переводить документацию Oracle", каждый профессионал воскликнет: "Специалист должен знать английский и должен уметь читать техническую документацию вендора".

Конечно, сейчас по прошествии многих лет работы с Oracle, мы легко ориентируемся в документации и быстро находим нужную информацию.

Я вспоминаю, как начиналась мое изучение Oracle: СУБД версии 6 в одном из государственных учреждений, практически никакой оригинальной документации, после предыдущего опыта работы с Clipper - первое ошеломляющее ощущение сложности этого продукта ...

Но, на мое счастье, в организации оказались перепечатки перевода руководства разработчика по языку SQL, по препроцессору Pro*C, загрузчику SQL*Loader и по среде разработки SQL*Forms3.0. Вот и вся документация, которая имелась в моем распоряжении, но она была на русском языке!

Перевод был сделан сотрудниками неведомого мне НИИ и, оглядываясь сейчас назад, понимаю, что перевод был сделан качественно. Высокое качество перевода было свидетельством того, что делали его не переводчики, а люди, непосредственно работавшие с СУБД.

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

Дальнейшее изучение Oracle происходило уже гораздо проще…

Если бы в моем распоряжении не было бы русскоязычной документации, то, я думаю, период знакомства с Oracle растянулся бы на более длительный период.

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

• руководства администратора;
• концепции сервера;
• руководство разработчика;
• руководства по языкам SQL и PL/SQL.

и при условии что он будет сделан профессионалами хорошо знающими Oracle.

Это позволит новичкам быстро освоить основы продукта и далее, по мере своей специализации, переходить к использованию документации на языке оригинала, например: руководство по JDBC, руководство по работе с RAC и т.д.