Эта статья написана по следам онлайн-курса Translation Quality Management от ТГУ и агентства Palex, который я недавно прошла по совету коллеги. Этот курс посвящен обеспечению качества переводов и предназначен как для менеджеров, организующих процесс перевода, так и для переводчиков и редакторов. Поскольку я переводчик и редактор в одном лице, некоторые идеи из этого курса показались мне полезными, и я хотела бы ими поделиться, а также рассказать, как они могут помочь сделать проверку (и самопроверку) переводов эффективнее. Статья может быть полезна тем, кто переводит и проверяет тексты, в частности, в IT.
Содержание:
Как мы проверяем переводы
В Plesk мы занимаемся локализацией наших продуктов на 31 язык. О том, какие типы текстов мы переводим и каковы их особенности, я уже писала в этой статье. Но нам приходится не только переводить тексты, но и проверять собственные переводы, так как у нас нет отдельных редакторов (что неудивительно, ведь найти и нанять редакторов на 31 язык непросто).
Я работаю переводчиком с английского на русский язык, и так же, как и другие переводчики, проверяю свои переводы сама. Раньше я проверяла свои переводы довольно простым способом: сразу после перевода вычитывала оригинальную и переведенную строки в нашей программе переводов Crowdin: сравнивала их по смыслу и смотрела, чтобы при этом отсутствовали опечатки и грамматические ошибки.
Иногда я просматривала русскоязычную документацию и интерфейс и вылавливала там ошибки перевода и исправляла их. Происходило это не регулярно, а тогда, когда у меня появлялось свободное время и я вспоминала об этом. (А иногда ошибки вылавливали наши тестировщики и сообщали нам о них).
В принципе, это вполне рабочий способ, но, на мой взгляд, несколько бессистемный и не позволяющий учесть все, что нужно. В курсе Translation Quality Management предложен новый, более дифференцированный подход к проверке переводов, и сейчас я пытаюсь применять его на практике.
Подход к проверке, предложенный на курсе
Основная идея подхода к проверке переводов, предложенного на курсе, такова: переведенный текст считается качественным, если он решает ту же задачу, что и оригинальный текст. Например, если это пользовательская документация – объясняет, как пользоваться продуктом, если маркетинговый текст – побуждает купить продукт.
Исходя из этого, вводится понятие блоков качества и соответствующих им типов ошибок. Для каждого переведенного текста проводится анализ: какие блоки качества наиболее приоритетны для решения его задачи. И, исходя из этого, выбираются те этапы проверки качества, которые наиболее важны в данном конкретном случае. Поэтому одни тексты проверяются одним способом, другие – другим. Это позволяет обратить особое внимание на то, что важно, и не тратить время на то, что неважно.
Рассмотрим этот подход подробнее.
Блоки качества и типы ошибок
Можно выделить следующие основные блоки качества и соответствующие им типы ошибок:
Блок качества | Ошибки |
Предметное содержание (subject matter) | Неправильный перевод терминов из предметной области или их неверное использование. |
Точность (accuracy) | Потеря или искажение смысла. |
Соответствие требованиям (compliance) | Несоответствие требованиям клиента, в частности, словарю или стайл-гайду. |
Язык (language) | Грамматические или пунктуационные ошибки, опечатки. |
Читаемость (readability) | Слишком «канцелярский» стиль, сложная структура предложений, избыточность, непонятные формулировки. |
Формальные правила (formal) | Двойные пробелы, отсутствие точек в конце предложений, неправильное форматирование чисел, единиц измерения и т.д. |
Внешний вид (container) | В зависимости от формата: съехавшие таблицы или списки в тексте, слишком длинные надписи в интерфейсе и т.д. |
Примечание: На курсе внешний вид не рассматривался как отдельный блок качества, о формате перевода говорилось отдельно. Но мне показалось логичным добавить его как отдельный блок, потому что он выделяет целую категорию ошибок.
Этапы проверки качества
Когда мы проверяем качество перевода, нам может потребоваться выполнить следующие этапы (в предположении, что мы используем не машинный, а «живой» перевод):
Редактирование (editing) – сравнение оригинальной и переведенной строки для проверки точного соответствия по смыслу.
Экспертная проверка (SME review) – проверка специалистом (subject matter expert, SME) переведенного текста на правильное использование терминологии и профессиональность.
Корректура (proofreading) – проверка грамотности и пунктуации переведенного текста. Это делает носитель языка перевода, необязательно знающий исходный язык.
Проверка стиля (copyediting) – чтение переведенного текста с целью оценить стиль. Для этого тоже достаточно быть только носителем языка перевода.
Автоматическая проверка (automated quality control) – проверка средствами CAT-программы или другой специальной программы верификации на отсутствие лишних пробелов, опечаток, неверных знаков препинания и т.д.
Постпроверка (final recheck) – визуальный просмотр уже опубликованного текста в зависимости от его формата. Например, для печатного текста в PDF – нумерация страниц и структура, для текста в HTML – правильная разметка, для UI – нормальные по размеру надписи, которые хорошо смотрятся на экране и вписываются в контекст.
Приоритезация блоков качества и выбор этапов проверки
Нужно ли каждый раз проходить все этапы проверки? К счастью, нет. А какие из них выбрать – зависит от приоритетов блоков качества:
Если нам особенно важно предметное содержание – проводим экспертную проверку.
В нашем случае мы, как правило, задаем вопросы специалистам прямо в ходе перевода, и этого достаточно. Хотя в одном проекте у нас все тексты интерфейса вычитывает менеджер проекта.Если важна точность – проводим редактирование.
У нас этот этап заключается в сравнении исходной и переведенной строк в программе перевода Crowdin, о котором я писала ранее.Если важен язык – проводим корректуру.
Наши переводчики – сами носители языка перевода и хорошо его знают, так что проводят корректуру прямо в процессе редактирования. К тому же в нашей программе перевода есть встроенная проверка орфографии, так что опечатки отлавливаются быстро. В общем, отдельно этот этап мы не проводим.Если важна читаемость – проводим проверку стиля.
То есть сам же переводчик бегло читает свой текст только на целевом языке, представляя себя на месте клиента.Если важны формальные правила – проводим автоматическую проверку.
В нашу программу переводов автоматическая проверка уже встроена: лишние пробелы и неверные знаки препинания отлавливаются программой при сохранении перевода каждой строки.Если важно соответствие требованиям – изучаем их перед началом перевода и проводим редактирование с учетом этих требований.
Поскольку мы не получаем от клиентов стайл-гайды, а глоссарий терминов встраивается прямо в программу переводов, то этот этап отдельно не проводится.Если важны визуальные требования – проводим постпроверку.
Просматриваем опубликованную документацию и интерфейс.
Применяем новый подход
Попробуем проанализировать несколько типов текстов, которые мы переводим. Расставим для каждого из них приоритеты блоков качества и определим, какие этапы проверки нам нужны. Каждому блоку дадим от одной до 6 звездочек (именно такая градация была предложена на курсе). Если звездочек больше трех – считаем, что этим блокам нужно уделить особое внимание.
User Interface
Для пользовательского интерфейса приоритетными будут такие блоки:
Точность ****** Точность очень важна, поскольку все сообщения в интерфейсе должны быть понятными и передавать верный смысл. Особенно это важно для сообщений об ошибках: среди них встречается много похожих, и, подставляя предложенные варианты из памяти переводов, легко спутать, например enabled и disabled в двух похожих сообщениях – а смысл от этого меняется на противоположный.
Внешний вид ****** Этот блок очень важен, так как сообщения интерфейса должны хорошо вписываться по длине и соответствовать контексту.
Предметное содержание ***** Это важно, так как продукт должен говорить на языке клиента (а большинство наших клиентов – веб-специалисты), термины должны быть верными.
Язык ** Язык сообщений интерфейса обычно прост. Опечатки не очень важны клиентам, но все же могут раздражать. Как правило, они отлавливаются автоматической проверкой.
Соответствие требованиям * Обычно никаких специальных требований к нам не предъявляется.
Читаемость * Сообщения интерфейса обычно коротки, и стиль их не очень важен. Хотя, если это сообщение маркетингового характера, то ситуация иная (см. раздел Маркетинговый текст)
Формальные требования * Пробелы и знаки препинания не очень важны, и они отлавливаются автоматической проверкой.
Итак, для сообщений интерфейса нам особенно важны точность, внешний вид и предметное содержание. Экспертную проверку, как я уже писала, мы обычно не проводим как отдельный этап. Таким образом, для сообщений интерфейса я выполняю следующие этапы проверки:
Редактирование – вычитываю строки и внимательно сверяю смысл с оригиналом. Особое внимание уделяю сообщениям об ошибках.
Постпроверка – обязательно смотрю интерфейс уже после публикации. Для этого я отслеживаю в программе переводов задачи, которым менеджер ставит статус Closed – это означает, что на следующий день я уже смогу посмотреть свой перевод в интерфейсе на нашем демо-сервере. Как правило, на этом этапе отлавливаются некоторые неточности, и их я сразу же правлю прямо в Crowdin.
Пример 1
В этом диалоге надпись «Бесплатная пробная версия» выглядит слишком длинной (гораздо длиннее, чем оригинальная “Free trial”), и заметила я это только после просмотра уже готового интерфейса. Поэтому заменила ее на более короткое сообщение: «Пробная версия».
Пример 2
В этом примере в результате просмотра интерфейса удалось заметить даже две проблемы:
Переведенная фраза не поместилась в заголовок – и это даже не наша проблема, а проблема разработки, т.к. размер окна и его заголовка не регулируется.
Неконсистентность: где-то используется слово «верификация», а где-то – «подтверждение».
О первой проблеме я сообщила менеджеру проекта. Расхождение же в терминологии исправила сама.
Документация для пользователей
Теперь попробуем выявить важные нам блоки качества для пользовательской документации.
Точность ****** Точность очень важна, поскольку пользователь должен получить понятные и верные инструкции (это и есть основная цель документации). Кроме того, нам важна консистентность: все элементы управления должны быть названы так же, как они называются в интерфейсе.
Читаемость ***** Если документация написана в сложном и неудобном стиле, то читать ее никто не будет: по непонятным вопросам клиенты скорее предпочтут обратиться в саппорт. А значит, этот блок тоже важен: текст в целом должен быть легко читаем.
Язык ***** Язык документации важен, так же, как и читаемость. Документацию с грамматическими ошибками и опечатками читать неприятно.
Предметное содержание *** Это тоже важно, но рисков ошибиться в терминах тут уже меньше: мы обычно переводим документацию после интерфейса, и нужные нам термины уже сохранены в глоссарии и памяти переводов. Мы, как правило, уже понимаем, о чем идет речь.
Внешний вид ** Наша документация пишется в разметке Markdown, и элементы форматирования в нее уже заложены, так что перевод на них, как правило, не влияет. Поэтому риск того, что таблицы или списки разъедутся – минимален.
Формальные требования ** Пробелы и знаки препинания важны, но они отлавливаются автоматической проверкой.
Соответствие требованиям * Обычно никаких специальных требований не предъявляется.
Таким образом, самые важные для нас блоки: точность, читаемость и язык. И для проверки перевода документации я выполняю следующие этапы:
Редактирование с одновременной корректировкой: сравниваю оригинальные и переведенные строки по смыслу, одновременно исправляя грамматические ошибки, если они есть. Особое внимание обращаю на названия элементов интерфейса – если есть сомнения в том, что они называются именно так, заглядываю в интерфейс.
Проверка стиля: бегло перечитываю строки только на русском языке подряд, как сплошной текст, и смотрю, насколько легко и логично этот текст читается.
Пример 1
В ходе редактирования документации у меня вызвало сомнение название кнопки «Экспортировать резервную копию» (перевод фразы “Export dump”).
Действительно, “dump” можно в некоторых случаях перевести как «резервная копия», но к базам данным обычно все же применяют термин «дамп». Кроме того, далее по тексту используется именно «дамп». Заглянув в интерфейс, я обнаружила, что кнопка действительно называется «Экспортировать дамп».
Так в ходе редактирования мне удалось выявить и исправить неконсистентность терминологии.
Пример 2
Если документация содержит список из нескольких пунктов, то нужно помнить, что правила его оформления в английском и русском языках различаются. Например, в английском тексте может встретиться список, в котором каждый пункт начинается с заглавной буквы и заканчивается точкой:
В русском же языке он должен выглядеть иначе: пункты начинаются со строчной буквы, а заканчиваются точкой с запятой (это правило можно найти, например, здесь):
В программе переводов каждый пункт идет как отдельный сегмент, так что мы можем не сразу понять, что это пункт списка, и просто перевести его, сохранив исходную пунктуацию. А если во время проверки прочитать строки подряд, как сплошной текст, становится понятно, что это список, и оформлять его нужно по правилам русского языка.
Маркетинговый текст
У нас маркетинговые тексты – это, как правило, описания наших расширений и функций в каталоге расширений и интернет-магазине. Цель такого текста – описать преимущества продукта и, в конечном итоге, продать его. Исходя из этого, попробуем расставить приоритеты блоков качества.
Читаемость ****** В маркетинговом тексте читаемость – главное. Текст должен быть привлекательным, легко читаемым и, можно даже сказать, певучим.
Язык ***** Язык тоже важен, так как неграмотный текст привлекательным уже не назовешь (во всяком случае, для клиентов, чувствительным к грамматическим ошибкам).
Внешний вид **** Опять же, текст должен быть привлекательным, в том числе и внешне.
Точность **** Точность в данном случае менее важна, так как главная цель – продать продукт. Дословный перевод в данном случае не нужен, передается лишь идея. Нужно только проследить, чтобы ни одна идея исходного текста не была потеряна.
Предметное содержание *** Маркетинговый текст обычно не содержит технических деталей, однако перечисляет основные возможности – достаточно перечислить их и верно передать их суть.
Формальные требования * Пробелы и знаки препинания не очень важны, тем более, что они отлавливаются автоматической проверкой.
Соответствие требованиям * Обычно никаких специальных требований не предъявляется.
Итак, в данном случае, главное для нас – читаемость, язык и внешний вид. Также не стоит забывать про точность в том смысле, чтобы не упустить ни одну идею. Поэтому мой алгоритм проверки маркетингового текста таков:
Редактирование: Бегло сверяю с оригиналом, чтобы понять, что ни одна исходная идея не упущена.
Проверка стиля: Читаю весь текст целиком только на русском языке и проговариваю (по возможности, вслух). Представляю себя при этом на месте потенциального клиента.
Постпроверка: Когда текст опубликован, смотрю еще раз, все ли хорошо смотрится, не съехали ли строчки и т.д.
Пример 1
В описании расширения SEO Toolkit в исходном варианте был такой заголовок: “Your visibility – our responsibility”. Я сначала перевела его дословно: «Ваша видимость – наша ответственность».
Когда я переводила, я была в контексте и понимала, что под «видимостью» здесь подразумевается термин «Видимость сайта в поисковых системах — количественная мера присутствия сайта в зоне видимости целевой аудитории». Поэтому меня ничто не насторожило.
Но когда я увидела этот лозунг в интерфейсе позже, поняла, что выглядит это не очень хорошо, так как без понимания контекста словосочетание «ваша видимость» может быть не сразу понятно читателю (даже веб-специалисту) и даже вызвать негативную ассоциацию:
Bидимость - внeшнocть, пpeимyщecтвeннo oбмaнчивaя (paзгoвopнoe). B. блaгoпoлyчия. Пo (вceй) видимocти, ввoдн. cл. (paзгoвopнoe) — пo-видимoмy, вepoятнo. Иcтoчник: https://ozhegov.textologia.ru/definit/vidimost/?q=742&n=166614
Поэтому, подумав, я перефразировала заголовок таким образом: «Видимость вашего сайта – наша ответственность». Кажется, так уже понятнее.
Пример 2
В этом примере в исходном тексте отсутствовал перенос в нужном месте, поэтому строки склеились и текст выглядел странно. Заметить эту ошибку мне удалось, лишь просмотрев опубликованный текст в интерфейсе.
Заключение
Приведенный выше анализ текстов по блокам качества может показаться несколько нудным, но, на самом деле, его достаточно провести всего один раз для каждого из типов текстов, а дальше уже применять выбранную стратегию.
Если подвести итог, чем отличается моя самопроверка сейчас от того, что было раньше?
Если раньше, когда менеджер менял статус задачи по переводу интерфейса на Closed, я отправляла эту задачу в архив. А сейчас сначала каждый раз просматриваю интерфейс сразу после публикации.
Если раньше я с примерно одинаковой тщательностью сверяла исходные и переведенные строки для всех типов текстов, то теперь делаю это особо тщательно для сообщений интерфейса (особенно для сообщений об ошибках), зато меньше времени трачу на такую сверку для маркетинговых текстов.
При проверке перевода документации не только сверяю строки, но и читаю строки на русском языке, как сплошной текст.
Маркетинговые тексты перечитываю целиком на русском языке и потом просматриваю после публикации.
По моим наблюдениям ошибки перевода стали теперь отлавливаться раньше — я чаще замечаю их сама до того, как на них наткнутся, например, тестировщики. Кроме того, я стала чаще находить проблемы с исходными строками или разметкой интерфейса, после чего сообщать о них менеджерам и разработчикам. Так что могу сказать, что сейчас мой процесс самопроверки становится более осознанным и, по моим ощущениям, более эффективным.
Если вас заинтересовал предложенный подход и вы хотите узнать о нем больше, рекомендую поучаствовать в курсе Translation Quality Management. Курс читается на английском языке на платформе Coursera (возможен бесплатный вариант без обратной связи).
А если у вас есть свои подходы к редактированию и самопроверке переводов — делитесь в комментариях!
