Наши потребительские мобильные продукты уникальны тем, что распространяются в более чем 100 странах на 34 языках — возможно, рекордное значение в российской IT-индустрии. В основном лишь считанные продукты отдельных компаний переводятся на десяток-другой языков; у нас же масса флагманов, которые переводятся на все 34. И конечно, если бы мы в группе разработки документации и локализаций (Doc&Loc) переводили каждую локаль «от корки до корки» по отдельности и никак это не оптимизировали, то пожалуй, никаких рекордов бы не было.
Меня зовут Никита Авилов, я — технический писатель в группе Doc&Loc Mac & Mobile «Лаборатории Касперского». В этой статье расскажу, как именно мы выстроили работу внутри команды, а также кроссфункциональное взаимодействие с другими подразделениями, чтобы меньшими усилиями раскатывать наши продукты на такое количество локалей.
Одна из ключевых задач технического писателя — создать человеческий и продающий GUI (Graphical User Interface)-текст. Пользователю бывает недостаточно функционала и внешнего вида приложения, ему необходимо понимать, чем полезны те или иные функции, что следует за нажатием кнопки и зачем его совершать. И техпису нужно построить доверительное общение между интерфейсом и пользователем. Следовательно, нужно стараться избегать технической терминологии, сложных конструкций и так далее — то есть разговаривать с пользователем понятным языком.
Наше основное ноу-хау — использование английского языка как исходника, а русского — в качестве локализации. При двойном переводе (русский -> английский -> локальный язык) не только увеличивается время и расходы на перевод, но и появляется риск искажения смысла. В свою очередь, английский язык, как исходный язык, более универсален поскольку дословный перевод с него на другой иностранный язык позволяет максимально сохранить смысл текста. К тому же русский, как локализация, менее привязан к английскому языку, поэтому можно позволить себе полет фантазии без оглядки на другие локализации.
Что касается непосредственно интерфейсов, то по договоренности с дизайнерами мы сразу пишем текст на макетах, чтобы оценить размер текста на экране и определиться с форматированием. Опытный глаз писателя или инженера по локализации также оценивает макет на локализуемость — как текст будет выглядеть на иностранном языке. Например, бывают очень длинные немецкие слова, а на некоторых полях экрана могут быть ограничения по символам — надо предусмотреть, поместится ли перевод.
После этих процедур текст согласуется кроссфункциональной командой, которая обычно состоит из продуктового менеджера, UX-дизайнера, системного аналитика и маркетинг-менеджера. И наконец, после утверждения всех формулировок техпис вносит текст в строки, которые уже завел разработчик в репозитории, и передает в локализацию.
В локализации особенно ценна помощь CAT (Сomputer-Assisted Translation)-системы — системы автоматизированного перевода, которая парсит входящий из репозитория английский текст на сегменты в левый столбец редактора и подставляет готовые предварительные переводы из памятей переводов (ТМ — Translation Memory), где содержатся переводы прошлых итераций, в правый столбец. Нетрудно догадаться, что такая подстановка также позволяет ускорить процесс перевода текста.
Раньше мы использовали локальные CAT-системы вроде SDL Trados или Passolo, мы собирали пакет строк в проприетарных форматах на перевод, импортировали его в CAT-систему, делали локализацию, экспортировали пакет, распаковывали, генерировали и загружали в GIT переведенные строки. С нашей частотой релизов такой подход оказался слишком медленным и неудобным, поэтому мы перешли на облачное решение SmartCAT, которое позволяет оперативно и напрямую загружать файлы из GIT через утилиту Syncer. Кроме того, традиционные CAT-системы работают по принципу одна лицензия — один конечный пользователь. Каждая лицензия покупается отдельно, что уже выходит дороже, чем платный корпоративный аккаунт в SmartCAT. К тому же локализатор может остаться без доступа к CAT-системе в нужный момент, если все свободные лицензии заняты коллегами.
Кстати, загрузка файлов в SmartCAT у нас также автоматизирована через наш внутренний сервис Syncer, который позволяет гибко настраивать обработку файлов, которые пойдут на перевод и список локализаций.
В CAT-системе находятся и поддерживаются сотни проектных памятей переводов (Translation Memory — TM). В ряде ситуаций техписы ищут в ней похожие тексты от коллег с соседних проектов — это тоже экономит время и расходы на локализацию новых текстов. К тому же единообразие текстов делает использование наших продуктов на разных платформах комфортнее.
Для локализации GUI-текстов мы используем отдельный пул профессиональных, тщательно подобранных лингвистов-носителей языка на аутсорсе. За их работой зорко следят сотрудники нашего отдела, большинство из которых знает более одного языка. Подбором, тестированием и взаимодействием с вендорами (подрядчиками), в том числе заключением и исполнением NDA-соглашений, отвечает специально выделенная группа Doc&Loc Vendor Management.
Если же говорить о централизованной разработки документации, то нам помогает AuthorIT — своего рода функциональный комбайн, где мы пишем онлайн-справки к продуктам. В нем можно гибко настраивать стили текстов, оставлять комментарии, использовать разные версии и варианты статей и экспортировать документацию в HTML, DOCX и XML.
Дальше черновик английской статьи отдается носителю английского языка на вычитку и системному аналитику для проверки на соответствие требованиям; а в некоторых случаях к согласованию справки привлекается еще и тестировщик. Справка на английском языке выкладывается на Stage — внутреннем портале пользовательской документации для проверки перед публикацией на проде. Проверенная справка утверждается аналитиком и продуктовой командой по необходимости, после чего по уже известной вам схеме согласованная английская справка передается в локализацию.
Итак, английский вариант онлайн-справки готов и прошел все круги согласования. Казалось бы, теперь следует отправить тексты на локализацию в агентства, где профессиональные лингвисты подготовили бы качественные переводы с учетом специфики каждого языка.
Однако на традиционный перевод мы потратили бы куда больше времени и денег, чем при текущем подходе, когда сперва мы применяем машинный перевод (MT — machine translation) с английского с помощью САТ-программы, и именно этот вариант инженер по локализации отправляем лингвистам на пост-редактуру. Для сравнения, новый текст онлайн-справки из 1000 слов требует от лингвиста около рабочей недели на перевод с чистого листа — а при нашем подходе редактура будет выполнена за 2–3 дня, а дальше дело за инженером по локализации.
Опять же, есть нюанс, что это не простой Google-переводчик, а его обучаемая нашими текстами модель — и кстати, вдобавок МТ дает нам возможность качественного предварительного перевода новых сегментов, поскольку в документациях, как правило, используется типичная терминология. Неочевидное преимущество машинного перевода в том, что он исключает опечатки, что не скажешь про человеческий фактор при традиционном переводе. Повторюсь, все это существенно сокращает временные и финансовые затраты.
Локализация технической документации — достаточно трудоемкий процесс, и вовсе не потому, что текст документации длиннее, чем тексты интерфейсов — просто названия GUI-элементов в справке должны быть в точности идентичны названиям в интерфейсе приложения. Если пользователь откроет справку, где он не увидит знакомые элементы из интерфейса, то он не найдет ответ на вопрос, и, скорее всего, пойдет в техподдержку. И основная задача справки — помочь разобраться со сложными и нетипичными кейсами и снизить нагрузку на техподдержку за счет снижения количества обращений.
Как я уже говорил, вручную обрабатывать 34 языка нерационально, поэтому процесс сверки терминов в локализациях мы тоже автоматизировали: с помощью Hash ID. Это инструмент, с помощью которого каждой строке интерфейса присваивается уникальный идентификатор, который вставляется в справку и потом заменяется на его значение из ресурсного файла приложения со строкой. Для этого техпис сперва генерирует Excel-таблицу с названиями GUI-элементами и их хэшами в квадратных скобках, а потом подставляет в топиках справки в AuthorIT к каждому элементу его ID. После этого справка экспортируется в формат HTML и отправляется локализаторам.
Стоит отметить, что именно использование Hash ID позволяет нам эффективнее использовать тот самый МТ (машинный перевод, основанный на нашем обучаемом движке) для предварительного перевода новых сегментов. МТ и Hash ID дополняют друг друга в разработке технической документации — непринципиально, как машина или человек переведет кнопку или название раздела, с помощью Hash ID неверный перевод исключен. Кроме того, в использовании Hash ID есть и еще один плюс — он не только существенно облегчает и ускоряет процесс работы над справкой, но и сводит к нулю человеческий фактор — вероятность ошибок или несоответствий в упоминаниях GUI-элементов.
Следующий шаг тот же, что и при переводе GUI-текстов: инженер по локализации отправляет предварительно переведенный с английского файл нашим лингвистам-подрядчикам.
После получения отредактированной справки локализатор выгружает справку, заменяет Hash ID в локализациях через утилиту, пересобирает справку через AIConverter и загружает на Stage в релизную папку справки. AIConverter — это наша утилита, которая обновляет верстку справки и настраивает правильную индексацию текста в поиске.
Любой цифровой продукт всегда сопровождается различными юридическими документами: пользовательскими соглашениями, политиками использования и так далее. И неизбежно получается, что эти документы должны быть готовы в кратчайший срок перед релизом, когда все и так горит. Однако мы нашли способ оптимизировать и этот процесс.
Для удобства мы разделили его на два этапа: предварительный перевод и финализация документов.
На первом этапе юристы составляют юридическую документацию, а мы обеспечиваем вычитку, проверку документов на английском и русском и перевод на требуемые языки. Здесь есть плюс: все готовые шаблоны у нас давно есть, а новые документы составляются редко. Поэтому обычно приходят задачи на изменения в существующие, и процесс не такой длинный, каким он мог бы быть. Системные аналитики заранее знают об этих дополнениях и создают задачу на предварительный перевод для инженера по локализации.
Локализатор, получив задачу на предварительный перевод, загружает документ с данными в SmartCAT и отправляет его на перевод в агентства, которые работают с юридическими документами. Особенность перевода юридического текста заключается в том, что он выполняется в два этапа: перевод и обязательная редактура, без которой исполнитель не сдает работу. Думаю, не нужно объяснять, что юридическое сопровождение — очень тонкий момент, требующий скрупулезного отношения. Полученные переводы мы сохраняем в соответствующих ТМ, после чего закрываем задачу.
Финализация документов инициируется аналитиком, и для доклоков она становится приоритетной задачей, не только потому, что дедлайн близко, но и потому, что могут появиться элементы, требующие особой внимательности. Если появились новые передаваемые данные, надо отправить их на английском на вычитку носителю языка. Если внесены правки в шаблоны документов, надо об этом сообщить аналитику, чтобы поправить перевод в Посейдоне — системе, в которой аналитики работают с потоками данных.
Далее редактор или писатель вычитывает финальные документы на английском и русском. Затем обязательно запускаются все автотесты и, по необходимости, вносятся правки. Обязательно проверяется секция В, которая содержит списки обрабатываемых данных — надо удостовериться, что всё в порядке с форматированием и количеством буллитов с передаваемыми данными в обоих языках, так как при составлении некоторые буллиты могут случайно объединиться. Это, кстати, очень удобно делать в Beyond Compare — программе для выявления разницы в папках и текстовых файлах.
На следующем этапе писатель конвертирует соглашения в HTML, проверяет все документы на предмет форматирования, работающих ссылок, копирайтов, отсутствия опечаток и выкладывает готовые HTML рядом с RTF.
Наконец, инженер по локализации, получив задачу от техписа, обеспечивает перевод финальных документов. Как правило, переводы для новых строк уже есть в ТМ благодаря работе, проделанной на этапе предварительного перевода, и инженеру остается собрать финальные документы локализаций из готовых сегментов.
После подстановки предварительного перевода локализатор выгружает готовые документы в папку в TFS и запускает автотесты по локализациям. Если ошибок нет, то задача выполнена.
Именно скриншоты стали нашим оптимизационным решением, позволяющим своевременно загружать верные GUI-тексты на всех языках в финальную сборку. После того как инженер по локализации получает готовые переводы от лингвистов-подрядчиков, он выгружает их из CAT-системы в рабочую ветку и снимает скриншоты к задаче на всех языках через автоскриншотилку. Автоскриншотилкой мы называем наш конвейер по получению скриншотов приложения по заданным параметрам: класс, локализации, параметры экрана.
Эффективные UI-тесты стали возможными благодаря нашему фреймворку для автотестов Kaspresso.
Полученные скриншоты мы собираем в пакеты для сравнения в формате для работы в программе ScreenshotLab, которая является полностью нашей разработкой. Мы ее создали для того, чтобы быстро собирать скрины, отправлять их на проверку и заводить баги; и в ней же мы формируем пары: локализованная версия и английская. Все наши подрядчики проходят обучение по работе с этой утилитой и узнают, как она помогает и ускоряет локализацию. Тексты английской и русской версий мы проверяем сами: написаны ли тексты в одной стилистике, соблюден ли Tone of Voice, везде ли правильные склонения и так далее.
Несколько лет назад мы собирали скриншоты в Screenshot Lab вручную через интерфейс программы, но недавно мы прописали эту утилиту в реестре Windows и создали шорткат, который позволяет собрать пакеты скриншотов для тестирования по щелчку правой кнопки мыши! Совсем недавно можно было сказать, что на сбор пакетов скриншотов для тестирования тратился один рабочий день. Сейчас, получив скриншоты от автоскриншотилки с утра, мы можем с уверенностью сказать, что во второй половине дня они уже проверяются лингвистом-вендором. Кстати, скоро у нас выйдет статья, посвященная нашим инструментам, где вы сможете подробнее узнать о принципах работы Screenshot Lab.
Далее мы загружаем скриншоты локализаций в папки в защищенном файлообменнике и отправляем лингвистам на проверку. Они проверяют тексты уже с точки зрения своего языка и речевых особенностей: везде ли соблюдено принятое обращение на вы/ты; везде ли написано «Войдите» или «Войти» на кнопке; вычищены ли грамматические ошибки, не осталось ли косметических дефектов (когда текст «вылезает» за поля) и т.д. Кстати, открыть эти файлы можно через дистрибутив Screenshot Lab: мы выдаем каждому подрядчику отдельный ключ, с помощью которого он получает доступ к скриншотам и утилите на нашем файлообменнике. Это очень сильно повышает уровень конфиденциальности.
Получив протестированные скриншоты, мы вносим правки в CAT-систему, чтобы верный текст попал в ТМ и в сами ресурсы, и выгружаем в систему контроля версий, откуда уже можно получить сборку с готовыми к релизу текстами.
В завершение расскажу про еще один наш инструмент — Terminarium, единая терминологическая система компании. Это внутренний веб-портал, где собрана вся необходимая для работы терминология на всех языках — названия продуктов и их компонентов, специфические термины наших продуктов, общие IT-термины и т.д. Для удобной организации терминологии была разработана система на основе связки проект-платформа-версия, которая позволяет удобно работать с наборами терминов, актуальных для конкретного продукта; сравнивать терминологию продуктов между собой; переиспользовать общие термины и т.д.
Можно подключить глоссарий к проекту в SmartCAT и включить соответствующую базу терминов (Term Base — TB) в настройках проекта — так лингвисту будет удобнее переводить, ведь у многих слов есть несколько переводов, а в рамках продуктов компании нужно придерживаться единой терминологии. Благодаря этой общей базе вероятность попадания текста с багом в релизную версию продукта существенно снижается.
При необходимости, любой сотрудник может предложить добавить в Терминариум тот или иной термин, нужный для работы. Нередко термины вносят представители региональных офисов, которые лучше знают маркетинговую специфику языка региона локализации. Этот механизм позволяет постоянно находить способы улучшения продукта и пользовательского опыта.
Для внешних пользователей глоссарии можно экспортировать в обычные файлы Excel, например, для лингвистов, которые проверяют переводы на скриншотах, чтобы они могли сверять специфические термины и поддерживать единообразие переводов продукта.
***
Итак, раньше мы использовали традиционные офлайн CAT-системы вроде Trados и Passolo. Однако переход на облачный SmartCAT и Syncer позволил отправлять ресурсы на перевод буквально сразу после появления английских строк в репозитории. Кроме того, SmartCAT позволяет отправлять на перевод все языки сразу парой кликов, без возни с генерацией пакетов для перевода и выгрузкой их каждому переводчику. Это также снизило затраты на хранение ресурсов для локализаций на сервере — больше нет необходимости хранить громоздкие пакеты для переводов и базы терминов в папках и ждать, пока коллеги освободят лицензию-другую. Локализация происходит буквально бесшовно между гитом и CAT-системой.
Создание и усовершенствование Screenshot Lab позволило нам сократить процесс сборки и отправки скриншотов на тестирование с рабочего дня до одного часа максимум. Обработка комментариев лингвистов по скриншотам стала также удобнее.
В справке больше всего текста, поэтому использование машинного перевода, Hash ID и пост-редактуры позволяет сильно экономить на переводе.
Резюмируя, внедренный нами многоэтапный и местами автоматизированный процесс локализации позволяет сэкономить много времени и средств на перевод и тестирование. Благодаря этому мы можем выпускать как минимум раз в месяц релиз продукта, локализованного на все 34 языка, с сопутствующими онлайн-справкой и юридической документацией.
Если вам было интересно, и вы тоже хотите поработать с таким большим количеством языков и лично увидеть, как соединяются в единый продукт все 34 локализации, то приходите к нам в «Лабораторию Касперского» в отдел документирования и локализации (Doc&Loc). Будем делать наши приложения и документацию доступными для всех — и делать это легко и быстро :)
Меня зовут Никита Авилов, я — технический писатель в группе Doc&Loc Mac & Mobile «Лаборатории Касперского». В этой статье расскажу, как именно мы выстроили работу внутри команды, а также кроссфункциональное взаимодействие с другими подразделениями, чтобы меньшими усилиями раскатывать наши продукты на такое количество локалей.
С чего начинается локализация
Одна из ключевых задач технического писателя — создать человеческий и продающий GUI (Graphical User Interface)-текст. Пользователю бывает недостаточно функционала и внешнего вида приложения, ему необходимо понимать, чем полезны те или иные функции, что следует за нажатием кнопки и зачем его совершать. И техпису нужно построить доверительное общение между интерфейсом и пользователем. Следовательно, нужно стараться избегать технической терминологии, сложных конструкций и так далее — то есть разговаривать с пользователем понятным языком.
Наше основное ноу-хау — использование английского языка как исходника, а русского — в качестве локализации. При двойном переводе (русский -> английский -> локальный язык) не только увеличивается время и расходы на перевод, но и появляется риск искажения смысла. В свою очередь, английский язык, как исходный язык, более универсален поскольку дословный перевод с него на другой иностранный язык позволяет максимально сохранить смысл текста. К тому же русский, как локализация, менее привязан к английскому языку, поэтому можно позволить себе полет фантазии без оглядки на другие локализации.
Что касается непосредственно интерфейсов, то по договоренности с дизайнерами мы сразу пишем текст на макетах, чтобы оценить размер текста на экране и определиться с форматированием. Опытный глаз писателя или инженера по локализации также оценивает макет на локализуемость — как текст будет выглядеть на иностранном языке. Например, бывают очень длинные немецкие слова, а на некоторых полях экрана могут быть ограничения по символам — надо предусмотреть, поместится ли перевод.
После этих процедур текст согласуется кроссфункциональной командой, которая обычно состоит из продуктового менеджера, UX-дизайнера, системного аналитика и маркетинг-менеджера. И наконец, после утверждения всех формулировок техпис вносит текст в строки, которые уже завел разработчик в репозитории, и передает в локализацию.
В локализации особенно ценна помощь CAT (Сomputer-Assisted Translation)-системы — системы автоматизированного перевода, которая парсит входящий из репозитория английский текст на сегменты в левый столбец редактора и подставляет готовые предварительные переводы из памятей переводов (ТМ — Translation Memory), где содержатся переводы прошлых итераций, в правый столбец. Нетрудно догадаться, что такая подстановка также позволяет ускорить процесс перевода текста.
Раньше мы использовали локальные CAT-системы вроде SDL Trados или Passolo, мы собирали пакет строк в проприетарных форматах на перевод, импортировали его в CAT-систему, делали локализацию, экспортировали пакет, распаковывали, генерировали и загружали в GIT переведенные строки. С нашей частотой релизов такой подход оказался слишком медленным и неудобным, поэтому мы перешли на облачное решение SmartCAT, которое позволяет оперативно и напрямую загружать файлы из GIT через утилиту Syncer. Кроме того, традиционные CAT-системы работают по принципу одна лицензия — один конечный пользователь. Каждая лицензия покупается отдельно, что уже выходит дороже, чем платный корпоративный аккаунт в SmartCAT. К тому же локализатор может остаться без доступа к CAT-системе в нужный момент, если все свободные лицензии заняты коллегами.
Кстати, загрузка файлов в SmartCAT у нас также автоматизирована через наш внутренний сервис Syncer, который позволяет гибко настраивать обработку файлов, которые пойдут на перевод и список локализаций.
В CAT-системе находятся и поддерживаются сотни проектных памятей переводов (Translation Memory — TM). В ряде ситуаций техписы ищут в ней похожие тексты от коллег с соседних проектов — это тоже экономит время и расходы на локализацию новых текстов. К тому же единообразие текстов делает использование наших продуктов на разных платформах комфортнее.
Для локализации GUI-текстов мы используем отдельный пул профессиональных, тщательно подобранных лингвистов-носителей языка на аутсорсе. За их работой зорко следят сотрудники нашего отдела, большинство из которых знает более одного языка. Подбором, тестированием и взаимодействием с вендорами (подрядчиками), в том числе заключением и исполнением NDA-соглашений, отвечает специально выделенная группа Doc&Loc Vendor Management.
Онлайн-справка — разработка, робот, человек
Если же говорить о централизованной разработки документации, то нам помогает AuthorIT — своего рода функциональный комбайн, где мы пишем онлайн-справки к продуктам. В нем можно гибко настраивать стили текстов, оставлять комментарии, использовать разные версии и варианты статей и экспортировать документацию в HTML, DOCX и XML.
Дальше черновик английской статьи отдается носителю английского языка на вычитку и системному аналитику для проверки на соответствие требованиям; а в некоторых случаях к согласованию справки привлекается еще и тестировщик. Справка на английском языке выкладывается на Stage — внутреннем портале пользовательской документации для проверки перед публикацией на проде. Проверенная справка утверждается аналитиком и продуктовой командой по необходимости, после чего по уже известной вам схеме согласованная английская справка передается в локализацию.
Итак, английский вариант онлайн-справки готов и прошел все круги согласования. Казалось бы, теперь следует отправить тексты на локализацию в агентства, где профессиональные лингвисты подготовили бы качественные переводы с учетом специфики каждого языка.
Однако на традиционный перевод мы потратили бы куда больше времени и денег, чем при текущем подходе, когда сперва мы применяем машинный перевод (MT — machine translation) с английского с помощью САТ-программы, и именно этот вариант инженер по локализации отправляем лингвистам на пост-редактуру. Для сравнения, новый текст онлайн-справки из 1000 слов требует от лингвиста около рабочей недели на перевод с чистого листа — а при нашем подходе редактура будет выполнена за 2–3 дня, а дальше дело за инженером по локализации.
Опять же, есть нюанс, что это не простой Google-переводчик, а его обучаемая нашими текстами модель — и кстати, вдобавок МТ дает нам возможность качественного предварительного перевода новых сегментов, поскольку в документациях, как правило, используется типичная терминология. Неочевидное преимущество машинного перевода в том, что он исключает опечатки, что не скажешь про человеческий фактор при традиционном переводе. Повторюсь, все это существенно сокращает временные и финансовые затраты.
Hash-координатор или как сделать так, чтобы кнопки не путались
Локализация технической документации — достаточно трудоемкий процесс, и вовсе не потому, что текст документации длиннее, чем тексты интерфейсов — просто названия GUI-элементов в справке должны быть в точности идентичны названиям в интерфейсе приложения. Если пользователь откроет справку, где он не увидит знакомые элементы из интерфейса, то он не найдет ответ на вопрос, и, скорее всего, пойдет в техподдержку. И основная задача справки — помочь разобраться со сложными и нетипичными кейсами и снизить нагрузку на техподдержку за счет снижения количества обращений.
Как я уже говорил, вручную обрабатывать 34 языка нерационально, поэтому процесс сверки терминов в локализациях мы тоже автоматизировали: с помощью Hash ID. Это инструмент, с помощью которого каждой строке интерфейса присваивается уникальный идентификатор, который вставляется в справку и потом заменяется на его значение из ресурсного файла приложения со строкой. Для этого техпис сперва генерирует Excel-таблицу с названиями GUI-элементами и их хэшами в квадратных скобках, а потом подставляет в топиках справки в AuthorIT к каждому элементу его ID. После этого справка экспортируется в формат HTML и отправляется локализаторам.
Стоит отметить, что именно использование Hash ID позволяет нам эффективнее использовать тот самый МТ (машинный перевод, основанный на нашем обучаемом движке) для предварительного перевода новых сегментов. МТ и Hash ID дополняют друг друга в разработке технической документации — непринципиально, как машина или человек переведет кнопку или название раздела, с помощью Hash ID неверный перевод исключен. Кроме того, в использовании Hash ID есть и еще один плюс — он не только существенно облегчает и ускоряет процесс работы над справкой, но и сводит к нулю человеческий фактор — вероятность ошибок или несоответствий в упоминаниях GUI-элементов.
Следующий шаг тот же, что и при переводе GUI-текстов: инженер по локализации отправляет предварительно переведенный с английского файл нашим лингвистам-подрядчикам.
После получения отредактированной справки локализатор выгружает справку, заменяет Hash ID в локализациях через утилиту, пересобирает справку через AIConverter и загружает на Stage в релизную папку справки. AIConverter — это наша утилита, которая обновляет верстку справки и настраивает правильную индексацию текста в поиске.
Куда же доклоку без документов… Юридических
Любой цифровой продукт всегда сопровождается различными юридическими документами: пользовательскими соглашениями, политиками использования и так далее. И неизбежно получается, что эти документы должны быть готовы в кратчайший срок перед релизом, когда все и так горит. Однако мы нашли способ оптимизировать и этот процесс.
Для удобства мы разделили его на два этапа: предварительный перевод и финализация документов.
На первом этапе юристы составляют юридическую документацию, а мы обеспечиваем вычитку, проверку документов на английском и русском и перевод на требуемые языки. Здесь есть плюс: все готовые шаблоны у нас давно есть, а новые документы составляются редко. Поэтому обычно приходят задачи на изменения в существующие, и процесс не такой длинный, каким он мог бы быть. Системные аналитики заранее знают об этих дополнениях и создают задачу на предварительный перевод для инженера по локализации.
Локализатор, получив задачу на предварительный перевод, загружает документ с данными в SmartCAT и отправляет его на перевод в агентства, которые работают с юридическими документами. Особенность перевода юридического текста заключается в том, что он выполняется в два этапа: перевод и обязательная редактура, без которой исполнитель не сдает работу. Думаю, не нужно объяснять, что юридическое сопровождение — очень тонкий момент, требующий скрупулезного отношения. Полученные переводы мы сохраняем в соответствующих ТМ, после чего закрываем задачу.
Финализация документов инициируется аналитиком, и для доклоков она становится приоритетной задачей, не только потому, что дедлайн близко, но и потому, что могут появиться элементы, требующие особой внимательности. Если появились новые передаваемые данные, надо отправить их на английском на вычитку носителю языка. Если внесены правки в шаблоны документов, надо об этом сообщить аналитику, чтобы поправить перевод в Посейдоне — системе, в которой аналитики работают с потоками данных.
Далее редактор или писатель вычитывает финальные документы на английском и русском. Затем обязательно запускаются все автотесты и, по необходимости, вносятся правки. Обязательно проверяется секция В, которая содержит списки обрабатываемых данных — надо удостовериться, что всё в порядке с форматированием и количеством буллитов с передаваемыми данными в обоих языках, так как при составлении некоторые буллиты могут случайно объединиться. Это, кстати, очень удобно делать в Beyond Compare — программе для выявления разницы в папках и текстовых файлах.
На следующем этапе писатель конвертирует соглашения в HTML, проверяет все документы на предмет форматирования, работающих ссылок, копирайтов, отсутствия опечаток и выкладывает готовые HTML рядом с RTF.
Наконец, инженер по локализации, получив задачу от техписа, обеспечивает перевод финальных документов. Как правило, переводы для новых строк уже есть в ТМ благодаря работе, проделанной на этапе предварительного перевода, и инженеру остается собрать финальные документы локализаций из готовых сегментов.
После подстановки предварительного перевода локализатор выгружает готовые документы в папку в TFS и запускает автотесты по локализациям. Если ошибок нет, то задача выполнена.
Автотестирование интерфейсов всех локализаций
Именно скриншоты стали нашим оптимизационным решением, позволяющим своевременно загружать верные GUI-тексты на всех языках в финальную сборку. После того как инженер по локализации получает готовые переводы от лингвистов-подрядчиков, он выгружает их из CAT-системы в рабочую ветку и снимает скриншоты к задаче на всех языках через автоскриншотилку. Автоскриншотилкой мы называем наш конвейер по получению скриншотов приложения по заданным параметрам: класс, локализации, параметры экрана.
Эффективные UI-тесты стали возможными благодаря нашему фреймворку для автотестов Kaspresso.
Полученные скриншоты мы собираем в пакеты для сравнения в формате для работы в программе ScreenshotLab, которая является полностью нашей разработкой. Мы ее создали для того, чтобы быстро собирать скрины, отправлять их на проверку и заводить баги; и в ней же мы формируем пары: локализованная версия и английская. Все наши подрядчики проходят обучение по работе с этой утилитой и узнают, как она помогает и ускоряет локализацию. Тексты английской и русской версий мы проверяем сами: написаны ли тексты в одной стилистике, соблюден ли Tone of Voice, везде ли правильные склонения и так далее.
Несколько лет назад мы собирали скриншоты в Screenshot Lab вручную через интерфейс программы, но недавно мы прописали эту утилиту в реестре Windows и создали шорткат, который позволяет собрать пакеты скриншотов для тестирования по щелчку правой кнопки мыши! Совсем недавно можно было сказать, что на сбор пакетов скриншотов для тестирования тратился один рабочий день. Сейчас, получив скриншоты от автоскриншотилки с утра, мы можем с уверенностью сказать, что во второй половине дня они уже проверяются лингвистом-вендором. Кстати, скоро у нас выйдет статья, посвященная нашим инструментам, где вы сможете подробнее узнать о принципах работы Screenshot Lab.
Далее мы загружаем скриншоты локализаций в папки в защищенном файлообменнике и отправляем лингвистам на проверку. Они проверяют тексты уже с точки зрения своего языка и речевых особенностей: везде ли соблюдено принятое обращение на вы/ты; везде ли написано «Войдите» или «Войти» на кнопке; вычищены ли грамматические ошибки, не осталось ли косметических дефектов (когда текст «вылезает» за поля) и т.д. Кстати, открыть эти файлы можно через дистрибутив Screenshot Lab: мы выдаем каждому подрядчику отдельный ключ, с помощью которого он получает доступ к скриншотам и утилите на нашем файлообменнике. Это очень сильно повышает уровень конфиденциальности.
Получив протестированные скриншоты, мы вносим правки в CAT-систему, чтобы верный текст попал в ТМ и в сами ресурсы, и выгружаем в систему контроля версий, откуда уже можно получить сборку с готовыми к релизу текстами.
Единая терминологическая база — чтобы точно не запутаться
В завершение расскажу про еще один наш инструмент — Terminarium, единая терминологическая система компании. Это внутренний веб-портал, где собрана вся необходимая для работы терминология на всех языках — названия продуктов и их компонентов, специфические термины наших продуктов, общие IT-термины и т.д. Для удобной организации терминологии была разработана система на основе связки проект-платформа-версия, которая позволяет удобно работать с наборами терминов, актуальных для конкретного продукта; сравнивать терминологию продуктов между собой; переиспользовать общие термины и т.д.
Можно подключить глоссарий к проекту в SmartCAT и включить соответствующую базу терминов (Term Base — TB) в настройках проекта — так лингвисту будет удобнее переводить, ведь у многих слов есть несколько переводов, а в рамках продуктов компании нужно придерживаться единой терминологии. Благодаря этой общей базе вероятность попадания текста с багом в релизную версию продукта существенно снижается.
При необходимости, любой сотрудник может предложить добавить в Терминариум тот или иной термин, нужный для работы. Нередко термины вносят представители региональных офисов, которые лучше знают маркетинговую специфику языка региона локализации. Этот механизм позволяет постоянно находить способы улучшения продукта и пользовательского опыта.
Для внешних пользователей глоссарии можно экспортировать в обычные файлы Excel, например, для лингвистов, которые проверяют переводы на скриншотах, чтобы они могли сверять специфические термины и поддерживать единообразие переводов продукта.
***
Итак, раньше мы использовали традиционные офлайн CAT-системы вроде Trados и Passolo. Однако переход на облачный SmartCAT и Syncer позволил отправлять ресурсы на перевод буквально сразу после появления английских строк в репозитории. Кроме того, SmartCAT позволяет отправлять на перевод все языки сразу парой кликов, без возни с генерацией пакетов для перевода и выгрузкой их каждому переводчику. Это также снизило затраты на хранение ресурсов для локализаций на сервере — больше нет необходимости хранить громоздкие пакеты для переводов и базы терминов в папках и ждать, пока коллеги освободят лицензию-другую. Локализация происходит буквально бесшовно между гитом и CAT-системой.
Создание и усовершенствование Screenshot Lab позволило нам сократить процесс сборки и отправки скриншотов на тестирование с рабочего дня до одного часа максимум. Обработка комментариев лингвистов по скриншотам стала также удобнее.
В справке больше всего текста, поэтому использование машинного перевода, Hash ID и пост-редактуры позволяет сильно экономить на переводе.
Резюмируя, внедренный нами многоэтапный и местами автоматизированный процесс локализации позволяет сэкономить много времени и средств на перевод и тестирование. Благодаря этому мы можем выпускать как минимум раз в месяц релиз продукта, локализованного на все 34 языка, с сопутствующими онлайн-справкой и юридической документацией.
Если вам было интересно, и вы тоже хотите поработать с таким большим количеством языков и лично увидеть, как соединяются в единый продукт все 34 локализации, то приходите к нам в «Лабораторию Касперского» в отдел документирования и локализации (Doc&Loc). Будем делать наши приложения и документацию доступными для всех — и делать это легко и быстро :)
