Всем привет! Меня зовут Владислав Москалёнок, и я работаю техническим переводчиком и редактором в сфере телекома и IT уже более 20 лет. Сегодня хочу поделиться опытом команды Bercut в цифровизации переводческих процессов. Из статьи вы узнаете, как мы реализовали комплексное решение, в котором сочетается технология накапливаемой памяти и нейронного машинного перевода. Если вы технический переводчик или вам просто интересна тема локализации ПО — добро пожаловать под кат!

Большие объёмы, сжатые сроки, повышенная сложность текста —  эта картина до боли знакома каждому профессиональному переводчику. К тому же в последние годы постоянно нарастает цифровизация во всех сферах жизни — от бытового ритейла до международных научных симпозиумов. Это порождает новые вызовы для нас — вплоть до необходимости переосмыслить некоторые аспекты своей профессии. Становится ясно, что масса «серых» середняков в ближайшие годы покинет рынок переводческих услуг. Ведь чтобы остаться на плаву в эпоху бурной цифровой трансформации, надо постоянно поддерживать уровень своей лингвистической и технической компетенции.

Появился новый вид перевода — цифровой. Это симбиоз традиционных («человеческих») и цифровых информационно-коммуникационных технологий. Меняется не только технология процесса переводческой деятельности, но и характер когнитивных процессов в сознании переводчика. В цифровом переводе функции человека уподобляются уже функциям дирижёра: переводчик как бы дирижирует разными процессами перевода, который исполняет искусственный интеллект.

В нашей компании мы используем именно такой подход к реализации больших проектов по локализации ПО и переводу пользовательской и технической документации. За последние 20 лет мы вместе с отраслью прошли большой путь: от использования самых примитивных систем машинного перевода до комплексного решения, где технология накапливаемой переводческой памяти (Translation Memory, TM) продуктивно сочетается с нейронным машинным переводом (neural-machine translation, NMT).

Именно о таком подходе к переводу и о практической его реализации я расскажу в данной статье.

Читаем «партитуру»

По аналогии с дирижёром большого оркестра опытный переводчик перед тем, как приступить к работе, внимательно читает «партитуру» — оценивает объём материалов на перевод:

• Количество строк кода для локализации GUI, описаний параметров в БД и системных сообщений, которые в виде файлов Excel он получает от разработчиков.

• Количество знаков в комплекте документов на ПО.

• Количество графического материала, включая скриншоты, схемы и рисунки.

После оценки объёма работ мы в первую очередь оцениваем трудозатраты (человеко-дни) в соответствии с особой методикой. Также применяем разные коэффициенты сложности — в зависимости от типа документа. Перевод справочника параметров БД с его короткими и однотипными предложениями не столь сложен, как перевод руководства администратора системы, которое включает более сложный лингвистический материал, схемы и рисунки.

Например, один из проектов по поставке ПО заказчику и по переводу всей сопроводительной документации на английский язык включал в себя около 5-ти миллионов знаков, то есть около 3-х тысяч страниц. При этом норма качественного перевода сложного технического текста в день, даже повышенная, составляет не более 15 тысяч знаков (8 условных страниц). Вы легко можете подсчитать, сколько одному профессиональному переводчику потребовалось бы времени на перевод этого, скажем прямо, катастрофического объёма. После вычета 100-процентных совпадений с Translation Memory, повторов (Repetitions) и контекстуальных совпадений (Context Match), мы получили цифру примерно в 250 человеко-дней. Это очень дорого! Вот пример лога анализа количества знаков в тех документах, которые остались для аутсорсеров:

И мы поняли, что настало время переходить к следующему этапу — совершить технологический прорыв. Пора ускорить темп исполнения «симфонии» перевода.

Ищем исполнителей «симфонии»

Каким бы гениальным ни был композитор и дирижёр, без профессиональных музыкантов никто не услышит прекрасное музыкальное произведение. Так же и без опытных переводчиков невозможно реализовать объёмный и комплексный проект по поставке ПО зарубежному заказчику. Пользователь увидит непонятный интерфейс приложения, с нелепыми лексическими и терминологическими ошибками типа “press the OK button”. Из руководства по настройке читатель не сможет понять, как лучше настроить функциональность. Инженер технической поддержки из-за некорректного описания параметра задаст неверное значение и произойдёт авария.

При поиске кандидатов-переводчиков мы руководствуемся следующими техническими требованиями, помимо обязательного наличия опыта работы в телекоме и IT:

• Поддержка перевода текста в виде топиков, написанных на  DITA (XML) и умение переводить текст в связке с XML-редактором. Наша исходная документация на русском языке создаётся в формате DITA (XML). Технические писатели уже давно отказались от неудобного и тяжеловесного формата .doc и довольно продуктивно создают контент для пользователей в XML-редакторе. Поэтому от переводчика требуются навыки работы с XML- и DITA-файлами.

• Поддержка системы автоматизированного перевода и Translation Memory. Переводчик должен уметь обращаться с настройками такой системы, которые позволят обрабатывать разные теги в исходных DITA-файлах и топики разного типа.

• Поддержка и обмен файлами в облачном хранилище. У переводчика должна быть возможность получать многочисленные объёмные файлы и выкладывать результаты работы. В целях информационной безопасности у нас используется корпоративное облачное хранилище — при необходимости мы предоставляем доступ аутсорсерам по паролю.

Удивительно, но на рынке перевода в России очень трудно найти переводчиков, включая агентства и ИП, которые умеют быстро и эффективно работать с переводами XML-файлов. Такое ощущение, что базовые языки цифровизации — HTML и XML — являются для большинства переводчиков какой-то новостью. И это спустя несколько десятков лет после их появления!

Однако, не теряя надежды, мы нашли такого толкового аутсорсера. Затем провели для него подробный инструктаж, как надо работать с XML-редактором и SDL Trados Studio в одной связке — для последовательного перевода всех топиков из карты документа .ditamap.

И вот настало время расписать партии для всех исполнителей.

Раздаем «ноты»

Чтобы не нарушить темп и сыграть симфонию в едином порыве, каждый музыкант оркестра получает нотную запись своей партии. И мы, в свою очередь, распределяем задачи в самом начале реализации большого проекта по переводу:

• Перевод ресурсных файлов локализации GUI, описаний параметров БД, системных сообщений. Эту задачу выполняю я, штатный переводчик компании, поскольку необходимо быть постоянно на связи с разработчиками и техническими писателями, а также разбираться в базовых принципах работы функциональности. Кроме того, иногда приходится переводить с русского на русский — с технического жаргона на нормированный научно-технический язык отрасли.

• Перевод пользовательской документации. Большую часть объёма мы отдаем аутсорсеру. Но самые важные документы я оставляю себе. Это, например, руководства по настройке функциональности или техническое описание платформы.

При передаче материалов аутсорсеру мы собираем XML-пакеты по каждому документу, которые включают в себя все необходимые файлы, нужные для финальной сборки переведённых топиков в итоговый PDF-файл на английском языке. В состав такого пакета входят:

• Карта документа (.ditamap).

• Все основные топики (Concept, Task, Reference).

• Все повторно используемые топики, необходимые для документа, включая термины из глоссария (Reusable content, References, Glossary).

• Файлы с изображениями (Images) и схемами в редактируемом формате (Visio).

Переводчик, получив этот пакет, может самостоятельно открыть его в XML-редакторе и перевести, не нарушая все взаимосвязи и ссылки между топиками.

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

Дирижёр

Вспомним, что в наше время переводчик-человек «дирижирует переводом», который исполняет искусственный интеллект. Исходя из моей практики, цифровой перевод — это комплекс действий, который направлен на извлечение максимальной пользы из CAT-инструментов, чтобы на выходе получить приемлемый по качеству перевод в сжатые сроки. При этом уровень качества и степень сжатия сроков можно регулировать по договорённости с менеджерами. Этот процесс мне напоминает bandwidth throttling в мобильной связи — регулирование скорости передачи данных в зависимости от тарифного плана.

• Если заказчик согласен получить ПО с ограниченным количеством документов — мы имеем простор для переводческого манёвра и распределяем усилия так, чтобы достичь оптимального соотношения качества и количества трудозатрат.

• Если же в краткие сроки требуется предоставить полный комплект, да ещё и с качественным GUI приложений — мы смело подключаем NMT к нашей накопленной переводческой памяти, и совесть нас не мучит. Правда, иногда она просыпается в процессе постредактирования полученных переводов.

Итак, если вы хотите получить приемлемый перевод 5 миллионов знаков через 65 человеко-дней, а не через 250, то нужно «дирижировать» в такой манере:

• Предварительно переводим все ресурсные файлы локализации GUI. Это основа основ. Без локализованного GUI невозможно корректно перевести многочисленные руководства пользователя, которые по содержанию связаны с описанием GUI.

• Составляем глоссарий терминов по каждому продукту, приложению, системе, которые входят в поставку ПО заказчику. Эти глоссарии я составляю в процессе перевода ресурсных файлов локализации GUI — быстро добавляю с помощью специального плагина из окна редактора SDL Trados Studio в приложение Multiterm. Есть еще вариант: после локализации GUI просто обработать двуязычные файлы Excel (RUS-ENG) и отправить аутсорсеру в помощь.

• Готовим Translation Memory. Необходимо максимально оптимизировать TM для исполнителей и для себя: убрать все дубликаты, разночтения в терминологии и проиндексировать память с помощью стандартных операций. Это значительно упростит процесс перевода разных документов по одной системе с соблюдением единого стиля и терминологии.

• Нанимаем аутсорсера, который отвечает нашим техническим требованиям. Проводим подробный инструктаж по работе с ресурсными файлами и отправляем ему в облако всё перечисленное выше: глоссарии терминов по продуктам, Translation Memory и пакеты с исходными файлами по каждому документу.

Итак, подготовлены и предоставлены аутсорсеру все ресурсы и материалы для качественного перевода и локализации ПО. Дирижёр взмахнул палочкой, симфония звучит.

Coda

Исполнение «симфонии» перевода близится к завершению: мы получили все переводы в виде пакета файлов. Теперь необходимо выполнить постредактирование всех документов для достижения единого стиля и терминологии. Это можно сделать с помощью массовых операций в XML-редакторе: используем операции поиска и замены, регулярные выражения и другие инструменты, в зависимости от возможностей редактора. При поиске и замене кусков текста с лексическими ошибками очень помогают теги. Например, можно массово заменить везде “select ” на “click” — получить все результаты поиска глагола “select ” перед иконками кнопок в GUI, которые обрамлены специальными тегами:

Итак, проект по переводу завершён. Теперь необходимо, не дожидаясь аплодисментов, собрать все полученные ресурсы в единой Translation Memory и обновить глоссарий. Это позволит сэкономить время и деньги, когда настанет время выполнять новый проект по переводу.

Подведём итоги — расставим все основные акценты в «партитуре».

Максимально эффективный метод технического перевода – автоматизированный, с использованием накопленной памяти переводов + NMT:

1. Высокая скорость — экономия до 40 % ТЗ. Повторное использование уже переведённых кусков текста (сегментов), которые хранятся в специальной базе переводов. С каждым новым переведенным сегментом текста скорость работы возрастает, так как в комплекте документации содержится много одинаковых или похожих фрагментов.

2. Высокое качество текста. Соблюдение единой терминологии.  Многие термины из корпоративного глоссария и общая терминология телекома на английском хранится в едином источнике — Translation Memory. С учетом контекста и нашей специфики. Накоплено за 20 лет, постоянно актуализируется.

3. Красивая сборка PDF из переведённых XML-файлов для заказчика с соблюдением всех требований корпоративного стиля. Нажимаем на одну кнопку — получаем PDF-документ.

4. Быстрое внесение изменений в документ и в GUI по новому релизу ПО. Берём нужный топик (файл .dita) и быстро переводим новые фразы в SDL Trados Studio, сохраняем в нужный формат. При изменениях в GUI — быстрая правка файла локализации Excel в редакторе SDL.

5. Удешевление последующих переводов аутсорсерами, которые тоже используют технологию Translation Memory (системы SDL Trados, MemoQ, SmartCat и другие). Чем больше совпадений текста с ТМ — тем меньше будет стоимость. Применяется понижающий коэффициент в зависимости от процента совпадений.

 И напоследок — краткая информация к размышлению.

Сейчас поставщики систем автоматизированного перевода предоставляют возможность работать в облаке — обрабатывать текст в режиме реального времени и передавать его версии друг другу. При этом использование NMT часто играет уже решающую роль в реализации больших проектов. По факту в будущем мы все окажемся в таком облаке. Такова неизбежная логика четвёртой промышленной революции: меняется парадигма взаимоотношений в процессе перевода, что приводит к появлению новых типов пользователей с новыми задачами и потребностями.

«Симфония» перевода всё время требует новой аранжировки.

А как вы ускоряете процессы перевода? Используете ли движок NMT? Поделитесь в комментариях вашими мыслями.