Разные типы IT-текстов: о чем стоит помнить переводчику
Для того, чтобы программным продуктом могли пользоваться люди в разных странах, нужно адаптировать его для них, то есть локализовать. И одним из важнейших этапов локализации всегда был и остается перевод. Я работаю в Plesk переводчиком с английского на русский язык и в этой статье хочу рассказать об особенностях работы IT-переводчика, а именно, о том, какие типы текстов мы переводим и с какими «подводными камнями» порой сталкиваемся в каждом из них. Надеюсь, мой опыт окажется полезным тем, кто переводит или собирается переводить IT-контент с английского на русский язык.
Содержание:
Трудности IT-перевода в целом
В IT я работаю уже 15 лет, но большую часть этого времени я была техническим писателем, то есть писала документацию к ПО на английском языке. Четыре года назад, когда у нас в компании появилась вакансия переводчика на русский язык, мне стало интересно сменить направление и попробовать себя в другой области — так я начала заниматься переводами. Вообще, технический писатель и IT-переводчик — профессии, на мой взгляд, родственные, потому что в обоих случаях нужно быть частично технарём, частично гуманитарием, и это как раз мой случай.
Сначала мне казалось, что переводить IT-тексты будет легко, ведь я владела темой и терминологией на английском, а русский — мой родной язык. Что тут может быть сложного? Но довольно скоро я столкнулась с рядом «подводных камней»:
Оказалось, что в профессиональной области я привыкла мыслить по-английски. То есть бывает, что я хорошо понимаю, как выразить ту или иную мысль по-английски, но сходу сказать это же по-русски уже не могу.
Поскольку IT-сфера развивается стремительно, в ней постоянно появляются новые термины и понятия, для которых ещё нет устоявшихся русских названий. И их приходится придумывать.
Границы между терминами и сленгом в русскоязычном IT довольно размыты. Если на профессиональных форумах вполне уместно использовать сленг, то в официальной документации для пользователей это чаще всего неприемлемо. Поэтому постоянно приходится искать баланс и подбирать нужные термины: не канцелярские, но и не сленговые, а более «человеческие» и при этом верно передающие смысл.
Ну и, помимо этого, свои особенности обнаружились у каждого из типов контента, которые мне приходилось переводить. Именно о них я расскажу ниже.
Коротко о процессе перевода в Plesk
В компании Plesk уже давно существует отдел локализации, который занимается переводом с английского на другие языки (сейчас на 31 язык). Количество продуктов, которые локализуются в нашей компании, периодически меняется. В течение нескольких лет это был единственный продукт — платформа веб-хостинга Plesk и несколько её расширений. В последние годы к списку продуктов, которые мы локализуем, добавилось много новых расширений Plesk, новый продукт SolusIO, а также cPanel — ещё одна популярная платформа веб-хостинга, широко используемая во многих странах.
У нас есть менеджеры по локализации (к их функциям относится организация процесса переводов, в частности, прием материалов на перевод и распределение их между переводчиками, контроль работы переводчиков и отправка готовых переводов в продукт) и штатные переводчики на русский, испанский и каталонский языки. Перевод на остальные языки выполняют outsource переводчики и агентства.
Наше основное программное обеспечение — это онлайн-платформа Crowdin, которая хорошо подходит для совместной работы переводчиков в условиях, когда проектов и продуктов много. В ней есть, в частности, такие полезные функции, как использование памяти переводов и глоссария, подсказки машинного перевода, удобная система комментариев и автоматическая проверка переводов.
Итак, что же именно мы переводим? И, главное, как?
Перевод UI: «попробуйте еще раз позже»
Основная и наиболее приоритетная часть нашей работы — перевод сообщений пользовательского интерфейса Plesk и других продуктов. Что такое UI-сообщения? Как правило, это короткие фразы для взаимодействия с пользователем — инструкции, предупреждения, вопросы и названия элементов управления, которые, на первый взгляд, не составляет труда перевести. Но чтобы после перевода они смотрелись естественно для носителя другого языка, нужно учитывать несколько моментов.
Контекст — это важно
Русский язык отличается от английского большим количеством различных форм слова: необходимо учитывать падеж, род, часть речи и так далее. И если, к примеру, сообщение состоит из одного слова «Open», мы можем перевести его в зависимости от контекста разными способами: «Открыть», «Откройте», «Открыто», «Открыт», «Открыта», «Открыты». Поэтому необходимо понимать, в каком месте интерфейса и в какой момент оно отображается. Если же переводить «в лоб», возможны подобные ситуации:
В момент перевода было неизвестно, что «Open» относится к числу открытых задач. Как узнать контекст? В идеале — получить доступ ко всему интерфейсу продукта или набор всех его скриншотов. Теоретически это, конечно, возможно, но на практике не всегда получается сделать это быстро, так как, например, часть расширений Plesk — платные, а для работы других расширений может потребоваться учетная запись в сторонней системе, например, в облачном хранилище. Более того, даже если переводчику удалось получить доступ к всему интерфейсу, есть ещё сообщения об ошибках, которые не всегда просто воспроизвести. Поэтому неизбежная часть работы переводчиков — задавать вопросы другим участникам команды (ПМ-ам, разработчикам, тестировщикам, техническим писателям). В программе Crowdin для этого есть удобная функция: оставить к сообщению комментарий с вопросом и там же получить на него ответ. Более того, нам видны вопросы других переводчиков и ответы на них, а значит, дублировать вопрос не нужно.
Глоссарий нам поможет
В каждом продукте есть своя терминология. И переводить её нужно единообразно, чтобы не называть одни и те же сущности по-разному. Соответственно, для каждого продукта нужен свой глоссарий. Большинство программ перевода поддерживают импорт глоссариев и при переводе показывают термины и их перевод, что очень удобно.
Иногда мы получаем глоссарии от менеджеров продукта: в этом случае у терминов есть пояснения на английском языке, а переводы на свой язык мы добавляем сами. А иногда составляем глоссарий самостоятельно. В любом случае, переводы в глоссарии мы согласовываем с менеджером продукта или другим участником команды. Бывает, например, что для одного продукта термин «snapshot» просят переводить как «снимок», а для другого — как «снапшот». Или название отдельных функций продукта просят оставить без перевода. Все это необходимо учитывать.
Как быть с числительными?
В русском языке больше форм существительных, зависящих от числительных, чем в английском:»1 элемент»,»2 элемента»,»5 элементов». Если не учитывать форму слова, то, например, сообщение »%%total%% items total» (где %%total%% — переменная, означающая число) может после перевода выглядеть так:
Слово «элементов» используется с любым числом.Как сделать так, чтобы в зависимости от числительного существительное правильно меняло свою форму? Обычно переводчики решают эту проблему совместно с разработчиками (например, мне понравился вариант использования «матрицы падежных форм», описанный в блоге компании Badoo).
А у нас в программе Crowdin есть возможность использовать синтаксис ICU, с помощью которого разработчики могут формировать сообщения с числительными, а переводчики — понимать их и корректно переводить. С помощью этого инструмента переводчик видит, какую часть фразы нужно переводить, а также может протестировать свой перевод, подставляя разные числа и проверяя, как изменяется форма слова.
То, что не выделено цветом, переводится. В поле «Preview» можно подставить число и проверить.Однако если в вашем арсенале пока нет никаких специальных инструментов для работы с числительными (а так было и у нас, пока мы не начали использовать синтаксис ICU), могу порекомендовать воркэраунд: перенести аргумент числа в конец сообщения и использовать общую форму для всех существительных. То есть фразу »%%total%% items total» при переводе меняем следующим образом: «Всего элементов: %%total%%». На мой взгляд, такой вариант вполне работает в большинстве случаев.
О различиях языков
Бывает, что видишь интерфейс программы на русском языке, и вроде бы всё понятно, но сразу чувствуется, что он переведен. Это становится видно по стилистическим различиям языка и разным традициям написания. Об этих различиях нам также приходится помнить, чтобы переведенный текст читался легко и естественно.
Английский язык более эмоционален. В английском интерфейсе нередко можно встретить сообщения с восклицательным знаком. В русском же языке это будет выглядеть слишком эмоционально и ассоциироваться с криком. А ещё в английских сообщениях часто используется слово «Please (Пожалуйста)», которое в русском языке, как правило, неуместно. Например, фраза «Please try again later!» в английском интерфейсе выглядит вполне приемлемо и звучит по-дружески. Но переведенная дословно фраза «Пожалуйста, попробуйте ещё раз позже!» звучит как-то тревожно. Поэтому переводим спокойнее, без «пожалуйста» и восклицательного знака: «Попробуйте ещё раз позже.»
Названия разделов меню: капитализация и кавычки. В русском языке не используется капитализация названий разделов меню по первым буквам каждого слова, принятая в английском языке. У нас в названиях заглавная буква используется только в первом слове. То есть, например, название раздела «Change Password» переводится как «Изменить пароль». Кроме того, внутри предложения названия элементов интерфейса используются в английском языке без кавычек, а в русском — в кавычках. Например: «Go to Change Password» → «Перейдите в раздел «Изменить пароль».
Другой порядок слов. В английском языке порядок слов строго фиксирован: «подлежащее-сказуемое-второстепенные члены предложения». В русском же языке порядок слов может варьироваться в зависимости от того, на чём вы хотите сделать смысловой акцент. Поэтому, чтобы перевод выглядел естественно, не переводим дословно, а думаем, какая часть фразы самая важная, и помещаем её в конец предложения. Например: «The certificate cannot be issued» → «Выпустить сертификат не удалось» (при этом дословный перевод «Сертификат не может быть выпущен» звучит понятно, но не совсем по-русски.)
Больше о стилистических различиях английского и русского языков можно прочитать, например, в Microsoft Russian Style Guide.
Перевод документации для пользователей: «флажок» или «чекбокс»?
Документация для пользователей — другая большая и важная часть контента, который мы переводим. Здесь уже с контекстом дело обстоит гораздо лучше, так как на перевод к нам приходят целые осмысленные куски текста: предложения и абзацы. Кроме того, доступ к англоязычной документации у нас есть практически всегда, так что мы можем прочитать всю главу на английском языке и, если что-то непонятно, задать вопрос техническим писателям. Однако и тут есть свои особенности.
Стиль — надо быть проще
Техническая документация у многих ассоциируется с сухим канцелярским стилем и ГОСТами. Действительно, в русскоязычной документации долгое время был принят такой стиль (а в некоторых технических областях, например, в описании промышленного оборудования, он принят до сих пор). Что касается стиля документации в IT, в последние годы он, к счастью, становится всё более «человеческим». Крупные IT компании в своих руководствах по стилю призывают писать более естественно и менее формально. Например, вот основные принципы Microsoft’s brand voice:
Warm and relaxed (Дружелюбный и естественный)
Crisp and clear (Четкий и понятный)
Ready to lend a hand (Предлагающий помощь)
В Plesk мы пишем документацию в таком же дружелюбном и естественном стиле и сохраняем его при переводе. Избегаем канцелярских слов и оборотов, например:
Вместо «данный» лучше «этот»
Вместо «выполнить удаление» лучше «удалить»
Вместо «в данный момент» лучше «сейчас»
Такие слова как «операция», «процедура», «действие» в большинстве случаев можно опустить
Терминология — как в UI
Для перевода документации мы используем тот же глоссарий, что и для перевода UI. Это нужно для того, чтобы одни и те же элементы назывались в UI и в документации одинаково.
Например, у нас в продукте есть тип резервной копии «incremental». Раньше в русском UI он был переведён как «инкрементный», а в гайде администратора — как «добавочный». Это могло привести к недопониманию, и сейчас мы занесли этот термин в глоссарий, так что это расхождение исправлено.
В интерфейсе тип резервной копии называется «Инкреметный».
А в документации тот же тип был назван «Добавочным». Ну и, конечно, если мы просим в документации нажать на какую-то кнопку и ссылаемся на её имя, то имя это должно быть переведено точно так же, как в UI. Тут уже глоссарий не всегда помогает, так как все названия из интерфейса туда не поместить. Так что в этом случае мы пользуемся функцией поиска по памяти переводов, чтобы найти, как имя этой кнопки переведено в UI, и используем нужный перевод.
Как назвать главы
Во всех гайдах ко всем продуктам мы используем одни и те же названия типовых глав. Благодаря этому документация становится более узнаваемой, и пользователям легче в ней ориентироваться. Например:
Getting Started — Начало работы
About — О <название продукта>
Appendix — Приложение
Troubleshooting — Решение проблем
FAQ — Ответы на часто задаваемые вопросы
Лучше всего список типовых названий внести в руководство по стилю (Style guide) для соответствующего языка. Style guide для документации на исходном языке обычно пишут технические писатели, а вот составить аналогичные руководства для других языков — задача переводчиков.
Как назвать элементы и действия
Ещё один момент, который стоит отразить в руководстве по стилю — стандартный перевод названий самих элементов интерфейса и действий с ними. Вот несколько примеров переводов, которые мы используем:
check box — флажок (а не «чекбокс»)
icon — значок (а не «иконка»)
click — нажать (а не «кликнуть»)
select the check box — установите флажок (также возможен вариант «выберите опцию»)
go to — перейдите в раздел
Вы можете выбрать и другие варианты перевода тех же терминов, так как однозначно правильного перевода, как правило, нет. Главное, чтобы на протяжении всей документации использовался один и тот же перевод.
Ориентироваться можно, например, на терминологию Microsoft или просто гуглить тот или иной термин, чтобы понять, какой перевод встречается чаще.
Перевод документации для разработчиков: «обработчик» или «хук»?
Почти все особенности, которые я перечислила для пользовательской документации, можно применить и к документации для разработчиков (разве что стандартные названия глав будут другими). Но всё же я хочу написать об этом типе контента отдельно, поскольку разработчики — несколько другая аудитория, нежели пользователи. Это люди, которые привыкли думать техническими понятиями, хорошо разбираются в предмете и меньше нуждаются в объяснениях, но больше — в четких инструкциях.
Нужно ли переводить?
Многие считают, что документацию для разработчиков вообще не нужно переводить, ведь она состоит в основном из примеров кода и понятна и так. Отчасти это справедливо, но всё же зависит от документа. Например, это верно для справочников по API или CLI — у нас эти документы не переводятся. Но другой документ, Руководство по разработке расширений Plesk, мы всё же перевели на русский язык, и некоторые наши разработчики уже это оценили (хотя и удивились). Это руководство представляет собой по сути учебник по созданию расширений, и читают его как наши разработчики, так и сторонние (написать расширение для Plesk может любой желающий). В этом учебнике есть описания всех шагов работы с расширением, упражнения, примечания — в общем, не только код, но и много полезного текста, читать который удобнее на своем родном языке.
Переводить нужно, но не всё
В документах для разработчиков есть части, которые ни в коем случае переводить не нужно:
Примеры кода (в них можно перевести только комментарии)
Названия функций, методов, переменных и т.д. в тексте
Названия команд и их аргументов
О том, какие части переводить не нужно, мы узнаём по разметке и подсветке, которую нам показывает программа переводов:
Названия метода и аргумента не переводятся.Уточняем термины
Насколько мне известно, среди IT-переводчиков инженеры и разработчики встречаются довольно редко. И это нормально, так как для перевода обычно требуются другие умения и навыки. Но если вы IT-переводчик и переводите для разработчиков, нужно очень внимательно отнестись к терминам и переводить их так, как разработчики привыкли, даже если эти переводы кажутся сленговыми. Придумывая более «литературные» названия, мы порой только усложняем их понимание.
Поэтому я бы рекомендовала советоваться с разработчиками по поводу каждого термина, по которому есть сомнения. Можно спрашивать на специальных форумах или в группах соцсетей. Например, помню, что мне пришлось довольно долго искать адекватный перевод термина «hook», и я советовалась в специальной группе Фейсбука и с разработчиками, и с переводчиками. Советы мне давали разные: были варианты «перехватчик» и «обработчик», но всё же большинство разработчиков написали, что самым понятным переводом будет просто «хук». На этом варианте я и остановилась.
Перевод маркетинговых текстов: «we«ll give you peace of mind»
Маркетинговые тексты в чистом виде мы переводим нечасто. Но время от времени они встречаются нам прямо в интерфейсе: это описания наших платных функций и расширений (например, в Каталоге расширений Plesk можно выбрать и купить то или иное расширение). И этот тип контента стоит отметить отдельно, поскольку он заметно отличается по стилю от технического. Ведь его цель — не столько объяснять, сколько продавать.
Эмоциональность — это хорошо!
Если технический текст обычно не отличается художественным разнообразием, то в маркетинговом тексте используются метафоры, восклицательные и вопросительные знаки и прочие эмоциональные проявления — и в переводе в этом случае они тоже будут уместны.
Маркетинговые тексты эмоциональны.Не переводим дословно
Дословный перевод маркетингового текста может выглядеть неестественно. Нужно настроиться на маркетинговый лад, поймать нужную идею и интонацию и передать её на своем языке своими словами, искренне и убедительно. Некоторые метафоры типа «peace of mind» вообще почти нереально перевести напрямую, и нужно тщательно выбирать наиболее уместные выражения. Скажу прямо, это достигается не сразу, и тут нужна практика. Могу порекомендовать искать похожие тексты на русском языке и ознакомиться с основами копирайтинга.
Проговариваем текст
Когда человек читает рекламу или другой маркетинговый текст, задействованы все каналы восприятия. Текст должен легко проговариваться, быть певучим, не содержать много шипящих и т.д. Поэтому после перевода проговариваем его вслух — если он звучит приятно и легко, а язык ни обо что не запинается, значит мы на верном пути.
Выводы
Подводя итог, могу сформулировать такие общие рекомендации, основанные на моем опыте перевода:
Всегда нужно помнить о том, для кого написан текст. Отсюда выбираем необходимый стиль и подход. Например, для пользователей и разработчиков пишем по-разному.
Задаем вопросы специалистам и обращаемся к признанным руководствам по стилю. Например, к Microsoft Russian Style Guide.
Просматриваем переведенные тексты и интерфейс после публикации, чтобы убедиться, что в них нет ошибок. Например, неподходящих форм слова или расхождений в терминах.
Читаем как можно больше русскоязычных IT-текстов и набираем словарный и терминологический запас.
И еще — я перечислила лишь основные, на мой взгляд, моменты по переводу каждого типа IT-контента. Если у вас есть желание узнать о каком-то из них поподробнее, пишите в комментариях!
