[Контент-маркетинг, Управление медиа] Разные типы IT-текстов: о чем стоит помнить переводчику
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Для того, чтобы программным продуктом могли пользоваться люди в разных странах, нужно адаптировать его для них, то есть локализовать. И одним из важнейших этапов локализации всегда был и остается перевод. Я работаю в 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”, мы можем перевести его в зависимости от контекста разными способами: «Открыть», «Откройте», «Открыто», «Открыт», «Открыта», «Открыты». Поэтому необходимо понимать, в каком месте интерфейса и в какой момент оно отображается. Если же переводить «в лоб», возможны подобные ситуации:
В момент перевода было неизвестно, что "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-контента. Если у вас есть желание узнать о каком-то из них поподробнее, пишите в комментариях!
===========
Источник:
habr.com
===========
Похожие новости:
- [Habr, Контент-маркетинг, Управление медиа, Социальные сети и сообщества] Как за 25 дней мы вывели блог на главную Хабра, но всё ли так, ребята?
- [Законодательство в IT, Управление медиа, Социальные сети и сообщества, IT-компании] Facebook восстановит доступ к новостям в Австралии после переговоров с правительством
- [Законодательство в IT, Управление медиа, Социальные сети и сообщества] Трафик сайтов в Австралии падает после запрета расшаривать ссылки в Facebook
- [Законодательство в IT, Управление медиа, Социальные сети и сообщества] Facebook запретила австралийцам делиться новостным контентом
- [Работа с 3D-графикой, Контент-маркетинг, Научно-популярное, AR и VR, Мозг] Как доставить сообщение “прямо в мозг” или немного о современном языке визуальной коммуникации
- [Поисковые технологии, Управление медиа, IT-компании] Microsoft предложила обязать Google и Facebook платить за новости в США
- [SaaS / S+S, Контент-маркетинг, IT-компании] Как IT-компании постят кейсы, которых не было, и как написать отличный кейс, даже если хвастаться особо нечем
- [Разработка игр, Контент-маркетинг, Читальный зал, Дизайн игр] Принципы нарративного дизайна (перевод)
- [Контент-маркетинг, Копирайт, Лайфхаки для гиков] Что делать, чтобы разработчик все-таки написал статью на Хабр?
- [Контент-маркетинг, Развитие стартапа] Damned if you do, damned if you don’t: how tech companies can cut through passive-aggressive media
Теги для поиска: #_kontentmarketing (Контент-маркетинг), #_upravlenie_media (Управление медиа), #_perevody (переводы), #_lokalizatsija_po (локализация по), #_blog_kompanii_plesk (
Блог компании Plesk
), #_kontentmarketing (
Контент-маркетинг
), #_upravlenie_media (
Управление медиа
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:52
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Для того, чтобы программным продуктом могли пользоваться люди в разных странах, нужно адаптировать его для них, то есть локализовать. И одним из важнейших этапов локализации всегда был и остается перевод. Я работаю в Plesk переводчиком с английского на русский язык и в этой статье хочу рассказать об особенностях работы IT-переводчика, а именно, о том, какие типы текстов мы переводим и с какими «подводными камнями» порой сталкиваемся в каждом из них. Надеюсь, мой опыт окажется полезным тем, кто переводит или собирается переводить IT-контент с английского на русский язык.  Содержание:
 В момент перевода было неизвестно, что "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.
 В интерфейсе тип резервной копии называется "Инкреметный".  А в документации тот же тип был назван "Добавочным". Ну и, конечно, если мы просим в документации нажать на какую-то кнопку и ссылаемся на её имя, то имя это должно быть переведено точно так же, как в UI. Тут уже глоссарий не всегда помогает, так как все названия из интерфейса туда не поместить. Так что в этом случае мы пользуемся функцией поиска по памяти переводов, чтобы найти, как имя этой кнопки переведено в UI, и используем нужный перевод.Как назвать главыВо всех гайдах ко всем продуктам мы используем одни и те же названия типовых глав. Благодаря этому документация становится более узнаваемой, и пользователям легче в ней ориентироваться. Например:
Лучше всего список типовых названий внести в руководство по стилю (Style guide) для соответствующего языка. Style guide для документации на исходном языке обычно пишут технические писатели, а вот составить аналогичные руководства для других языков — задача переводчиков.
Ориентироваться можно, например, на терминологию Microsoft или просто гуглить тот или иной термин, чтобы понять, какой перевод встречается чаще.
 Названия метода и аргумента не переводятся.Уточняем терминыНасколько мне известно, среди IT-переводчиков инженеры и разработчики встречаются довольно редко. И это нормально, так как для перевода обычно требуются другие умения и навыки. Но если вы IT-переводчик и переводите для разработчиков, нужно очень внимательно отнестись к терминам и переводить их так, как разработчики привыкли, даже если эти переводы кажутся сленговыми. Придумывая более «литературные» названия, мы порой только усложняем их понимание.Поэтому я бы рекомендовала советоваться с разработчиками по поводу каждого термина, по которому есть сомнения. Можно спрашивать на специальных форумах или в группах соцсетей. Например, помню, что мне пришлось довольно долго искать адекватный перевод термина “hook”, и я советовалась в специальной группе Фейсбука и с разработчиками, и с переводчиками. Советы мне давали разные: были варианты «перехватчик» и «обработчик», но всё же большинство разработчиков написали, что самым понятным переводом будет просто «хук». На этом варианте я и остановилась.Перевод маркетинговых текстов: "we’ll give you peace of mind"Маркетинговые тексты в чистом виде мы переводим нечасто. Но время от времени они встречаются нам прямо в интерфейсе: это описания наших платных функций и расширений (например, в Каталоге расширений Plesk можно выбрать и купить то или иное расширение). И этот тип контента стоит отметить отдельно, поскольку он заметно отличается по стилю от технического. Ведь его цель — не столько объяснять, сколько продавать.Эмоциональность — это хорошо!Если технический текст обычно не отличается художественным разнообразием, то в маркетинговом тексте используются метафоры, восклицательные и вопросительные знаки и прочие эмоциональные проявления — и в переводе в этом случае они тоже будут уместны.  Маркетинговые тексты эмоциональны.Не переводим дословноДословный перевод маркетингового текста может выглядеть неестественно. Нужно настроиться на маркетинговый лад, поймать нужную идею и интонацию и передать её на своем языке своими словами, искренне и убедительно. Некоторые метафоры типа “peace of mind” вообще почти нереально перевести напрямую, и нужно тщательно выбирать наиболее уместные выражения. Скажу прямо, это достигается не сразу, и тут нужна практика. Могу порекомендовать искать похожие тексты на русском языке и ознакомиться с основами копирайтинга.Проговариваем текстКогда человек читает рекламу или другой маркетинговый текст, задействованы все каналы восприятия. Текст должен легко проговариваться, быть певучим, не содержать много шипящих и т.д. Поэтому после перевода проговариваем его вслух — если он звучит приятно и легко, а язык ни обо что не запинается, значит мы на верном пути.ВыводыПодводя итог, могу сформулировать такие общие рекомендации, основанные на моем опыте перевода:
=========== Источник: habr.com =========== Похожие новости:
Блог компании Plesk ), #_kontentmarketing ( Контент-маркетинг ), #_upravlenie_media ( Управление медиа ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:52
Часовой пояс: UTC + 5