Для того, чтобы программным продуктом могли пользоваться люди в разных странах, нужно адаптировать его для них, то есть локализовать. И одним из важнейших этапов локализации всегда был и остается перевод. Я работаю в Plesk переводчиком с английского на русский язык и в этой статье хочу рассказать об особенностях работы IT-переводчика, а именно, о том, какие типы текстов мы переводим и с какими «подводными камнями» порой сталкиваемся в каждом из них. Надеюсь, мой опыт окажется полезным тем, кто переводит или собирается переводить IT-контент с английского на русский язык.

Содержание:

• Трудности IT-перевода в целом

• Коротко о процессе перевода в Plesk

• Перевод UI: "попробуйте еще раз позже"

• Перевод документации для пользователей: "флажок" или "чекбокс"?

• Перевод документации для разработчиков: "обработчик" или "хук"?

• Перевод маркетинговых текстов: "we’ll give you peace of mind"

• Выводы

Трудности IT-перевода в целом

В IT я работаю уже 15 лет, но большую часть этого времени я была техническим писателем, то есть писала документацию к ПО на английском языке. Четыре года назад, когда у нас в компании появилась вакансия переводчика на русский язык, мне стало интересно сменить направление и попробовать себя в другой области — так я начала заниматься переводами. Вообще, технический писатель и IT-переводчик — профессии, на мой взгляд, родственные, потому что в обоих случаях нужно быть частично технарём, частично гуманитарием, и это как раз мой случай.

Сначала мне казалось, что переводить IT-тексты будет легко, ведь я владела темой и терминологией на английском, а русский — мой родной язык. Что тут может быть сложного? Но довольно скоро я столкнулась с рядом «подводных камней»:

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

• Поскольку IT-сфера развивается стремительно, в ней постоянно появляются новые термины и понятия, для которых ещё нет устоявшихся русских названий. И их приходится придумывать.

• Границы между терминами и сленгом в русскоязычном IT довольно размыты. Если на профессиональных форумах вполне уместно использовать сленг, то в официальной документации для пользователей это чаще всего неприемлемо. Поэтому постоянно приходится искать баланс и подбирать нужные термины: не канцелярские, но и не сленговые, а более «человеческие» и при этом верно передающие смысл.

Ну и, помимо этого, свои особенности обнаружились у каждого из типов контента, которые мне приходилось переводить. Именно о них я расскажу ниже.

Коротко о процессе перевода в Plesk

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

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

Наше основное программное обеспечение — это онлайн-платформа Crowdin, которая хорошо подходит для совместной работы переводчиков в условиях, когда проектов и продуктов много. В ней есть, в частности, такие полезные функции, как использование памяти переводов и глоссария, подсказки машинного перевода, удобная система комментариев и автоматическая проверка переводов.

Итак, что же именно мы переводим? И, главное, как?

Перевод UI: "попробуйте еще раз позже"

Основная и наиболее приоритетная часть нашей работы — перевод сообщений пользовательского интерфейса Plesk и других продуктов. Что такое UI-сообщения? Как правило, это короткие фразы для взаимодействия с пользователем — инструкции, предупреждения, вопросы и названия элементов управления, которые, на первый взгляд, не составляет труда перевести. Но чтобы после перевода они смотрелись естественно для носителя другого языка, нужно учитывать несколько моментов.

Контекст — это важно

Русский язык отличается от английского большим количеством различных форм слова: необходимо учитывать падеж, род, часть речи и так далее. И если, к примеру, сообщение состоит из одного слова “Open”, мы можем перевести его в зависимости от контекста разными способами: «Открыть», «Откройте», «Открыто», «Открыт», «Открыта», «Открыты». Поэтому необходимо понимать, в каком месте интерфейса и в какой момент оно отображается. Если же переводить «в лоб», возможны подобные ситуации:

Как узнать контекст? В идеале — получить доступ ко всему интерфейсу продукта или набор всех его скриншотов. Теоретически это, конечно, возможно, но на практике не всегда получается сделать это быстро, так как, например, часть расширений Plesk — платные, а для работы других расширений может потребоваться учетная запись в сторонней системе, например, в облачном хранилище. Более того, даже если переводчику удалось получить доступ к всему интерфейсу, есть ещё сообщения об ошибках, которые не всегда просто воспроизвести. Поэтому неизбежная часть работы переводчиков — задавать вопросы другим участникам команды (ПМ-ам, разработчикам, тестировщикам, техническим писателям). В программе Crowdin для этого есть удобная функция: оставить к сообщению комментарий с вопросом и там же получить на него ответ. Более того, нам видны вопросы других переводчиков и ответы на них, а значит, дублировать вопрос не нужно.

Глоссарий нам поможет

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

Иногда мы получаем глоссарии от менеджеров продукта: в этом случае у терминов есть пояснения на английском языке, а переводы на свой язык мы добавляем сами. А иногда составляем глоссарий самостоятельно. В любом случае, переводы в глоссарии мы согласовываем с менеджером продукта или другим участником команды. Бывает, например, что для одного продукта термин “snapshot” просят переводить как «снимок», а для другого — как «снапшот». Или название отдельных функций продукта просят оставить без перевода. Все это необходимо учитывать. 

Как быть с числительными?

В русском языке больше форм существительных, зависящих от числительных, чем в английском: «1 элемент», «2 элемента», «5 элементов».  Если не учитывать форму слова, то, например, сообщение “%%total%% items total” (где %%total%% — переменная, означающая число) может после перевода выглядеть так:

Как сделать так, чтобы в зависимости от числительного существительное правильно меняло свою форму? Обычно переводчики решают эту проблему совместно с разработчиками (например, мне понравился вариант использования «матрицы падежных форм», описанный в блоге компании Badoo). 

А у нас в программе Crowdin есть возможность использовать синтаксис ICU, с помощью которого разработчики могут формировать сообщения с числительными, а переводчики — понимать их и корректно переводить. С помощью этого инструмента переводчик видит, какую часть фразы нужно переводить, а также может протестировать свой перевод, подставляя разные числа и проверяя, как изменяется форма слова.

Однако если в вашем арсенале пока нет никаких специальных инструментов для работы с числительными (а так было и у нас, пока мы не начали использовать синтаксис 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-контента. Если у вас есть желание узнать о каком-то из них поподробнее, пишите в комментариях!