Для того, чтобы программным продуктом могли пользоваться люди в разных странах, нужно адаптировать его для них, то есть локализовать. И одним из важнейших этапов локализации всегда был и остается перевод. Я работаю в Plesk переводчиком с английского на русский язык и в этой статье хочу рассказать об особенностях работы IT-переводчика, а именно, о том, какие типы текстов мы переводим и с какими подводными камнями порой сталкиваемся в каждом из них. Надеюсь, мой опыт окажется полезным тем, кто переводит или собирается переводить IT-контент с английского на русский язык.
Содержание:
-
Перевод документации для пользователей: "флажок" или "чекбокс"?
-
Перевод документации для разработчиков: "обработчик" или "хук"?
-
Перевод маркетинговых текстов: "well 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, мы можем перевести его в зависимости от контекста разными способами: Открыть, Откройте, Открыто, Открыт, Открыта, Открыты. Поэтому необходимо понимать, в каком месте интерфейса и в какой момент оно отображается. Если же переводить в лоб, возможны подобные ситуации:
В момент перевода было неизвестно, что
"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, и я советовалась в специальной группе Фейсбука и с разработчиками, и с переводчиками. Советы мне давали разные: были варианты перехватчик и обработчик, но всё же большинство разработчиков написали, что самым понятным переводом будет просто хук. На этом варианте я и остановилась.
Перевод маркетинговых текстов: "well give you peace of mind"
Маркетинговые тексты в чистом виде мы переводим нечасто. Но время от времени они встречаются нам прямо в интерфейсе: это описания наших платных функций и расширений (например, в Каталоге расширений Plesk можно выбрать и купить то или иное расширение). И этот тип контента стоит отметить отдельно, поскольку он заметно отличается по стилю от технического. Ведь его цель не столько объяснять, сколько продавать.
Эмоциональность это хорошо!
Если технический текст обычно не отличается художественным разнообразием, то в маркетинговом тексте используются метафоры, восклицательные и вопросительные знаки и прочие эмоциональные проявления и в переводе в этом случае они тоже будут уместны.
Маркетинговые тексты эмоциональны.
Не переводим дословно
Дословный перевод маркетингового текста может выглядеть неестественно. Нужно настроиться на маркетинговый лад, поймать нужную идею и интонацию и передать её на своем языке своими словами, искренне и убедительно. Некоторые метафоры типа peace of mind вообще почти нереально перевести напрямую, и нужно тщательно выбирать наиболее уместные выражения. Скажу прямо, это достигается не сразу, и тут нужна практика. Могу порекомендовать искать похожие тексты на русском языке и ознакомиться с основами копирайтинга.
Проговариваем текст
Когда человек читает рекламу или другой маркетинговый текст, задействованы все каналы восприятия. Текст должен легко проговариваться, быть певучим, не содержать много шипящих и т.д. Поэтому после перевода проговариваем его вслух если он звучит приятно и легко, а язык ни обо что не запинается, значит мы на верном пути.
Выводы
Подводя итог, могу сформулировать такие общие рекомендации, основанные на моем опыте перевода:
-
Всегда нужно помнить о том, для кого написан текст. Отсюда выбираем необходимый стиль и подход. Например, для пользователей и разработчиков пишем по-разному.
-
Задаем вопросы специалистам и обращаемся к признанным руководствам по стилю. Например, к Microsoft Russian Style Guide.
-
Просматриваем переведенные тексты и интерфейс после публикации, чтобы убедиться, что в них нет ошибок. Например, неподходящих форм слова или расхождений в терминах.
-
Читаем как можно больше русскоязычных IT-текстов и набираем словарный и терминологический запас.
И еще я перечислила лишь основные, на мой взгляд, моменты по переводу каждого типа IT-контента. Если у вас есть желание узнать о каком-то из них поподробнее, пишите в комментариях!
