Как мы в SM Lab локализацией занимаемся
Всем привет! Мы (Никита Звонилкин и Дмитрий Ёжиков) работаем в отделе локализации в SM Lab. Мы провели презентацию по теме интеграции локализации в процесс тестирования ПО на конференции SQA Days. Для этой статьи мы адаптировали эту презентацию, чтобы показать, чем локализация отличается от перевода. А ещё расскажем про основные этапы локализации, поговорим о подборе команды для проведения тестирования и о полезном софте.
Немного цифр. Спортмастер — большая компания, торговые сети представлены в 6 разных странах, а в 11 есть дополнительные офисы, в которых работают более 45 000 сотрудников. SM Lab — отдельно IT-подразделение, которое занимается разработкой софта и, собственно, его локализацией для стран нашего присутствия.
Тонкости локализации
Локализация это не просто перевод, но и адаптация текста и содержания под культуру конкретной страны, ее стандарты и менталитет. В локализации важно не только хорошо перевести текст, но и донести культурный код, который может выражаться как в изображениях, так и во всяких смайлах, эмоджи, жестах, символах и так далее.
Например, белый цвет, который в принципе везде считается нейтральным, в Японии могут расценить как траурный, так что не всегда будет уместно его использовать. В разных странах по-разному могут воспринимать ещё и жесты с символами, которые вам кажутся привычными и стандартными. Скажем, значок мира, который у нас так и воспринимается, в Великобритании лучше не показывать, он считается оскорбительным жестом. Большой палец вверх тоже у нас считается вполне себе адекватным, а вот жестовое обозначение «ОК» в той же Бразилии расценивается совсем иначе.
Если кто-то смотрел фильм Квентина Тарантино «Бесславные ублюдки», то вы явно помните сцену, в которой офицер под прикрытием (персонаж Майкла Фассбендера) заказывает жестом три пива, чем и выдает себя.
Немцы начинают жестовый отсчет с большого пальца. В общем, как понимаете, подобные мелочи могут вызывать весьма неожиданную реакцию у пользователя по ту сторону экрана.
Давайте поговорим о пользе ранней локализации.
Во-первых, это наилучший пользовательский опыт. Пользователи тратят на 70% меньше времени на обучение или работу в ПО, которое локализовано на их родной язык.
Во-вторых, сокращение временных затрат. Это обуславливается тем, что настройка профильных средств для локализации сразу позволяет сократить затраты и быстрее в этот процесс влиться.
В-третьих, повышение уровня качества локализации в целом. Чем раньше запускаете процесс локализации, тем проще будет им заниматься, потому что времени, которое отведено на него, будет больше, чем если его запустить в самом конце разработки. А спешка неизбежно скажется на качестве.
Этапы локализации
Первый этап — это машинный перевод (МТ) или обычный перевод, человеческий. Это самый простой этап. Тут переводчик (либо машина) просто адаптирует текст под ту страну, для которой переводится.
Следующий этап — редактура, специалист отслеживает все возможные ошибки и правит их. Тут важно как можно больше отследить и исправить. Сюда также можно отнести еще корректуру, когда появятся уже небольшие помарки, какие-то пунктуация, опечатки. Но, тем не менее, все мы люди, и всегда может случиться так, что самые неочевидные ошибки остаются незамеченными.
С этим помогает следующий этап, FQA, формальная проверка качества. Здесь используется специализированное ПО, которое умеет отслеживать подобные мелочи, ему можно задавать нужные параметры для проверки. Например, конкретные числовые значения — если человек может не заметить на глаз лишний нолик в длинном числе, то программа это сразу отметит.
Затем идёт лингвистическая проверка качества, LQA. Тут эксперт отсматривает конкретный кусочек текста (как правило, единый отрывок или случайную выборку), и на его основе формирует отчёт о качестве перевода. Существует ряд метрик, позволяющих нормально это оценить (у нас внедрена собственная метрика на основе MQM).
Финальный этап — тестирование. Несмотря на то, что он в списке последний, сам этап очень важный, потому что именно здесь можно увидеть всю картину целиком и при необходимости поправить длину текста, какие-то мелкие огрехи, или заметить вещи, несовместимые с культурным кодом какой-то страны.
Выбор команды
Важным подготовительным этапом перед локализацией, в том числе для проведения тестирования локализации, является выбор команды. Потому что самый частый вопрос в плане локализации звучит так: «Кто вообще будет этим заниматься?». Самый очевидный ответ — мы сами, если в достаточной мере знаем язык. В целом это действительно так. Но бывает так, что локализация не всегда требуется с русского на английский или в обратную сторону. Есть и более редкие языки, которые мы используем, и тогда нам в любом случае надо обращаться к дополнительным специалистам.
Вот подходы к выбору команды и плюсы и минусы каждого из них.
Чем хороша самостоятельная работа по локализации? Тем, что мы минимально используем финансы, поскольку мы не привлекаем сторонние ресурсы и делаем все сами.
Очевидный минус — скорее всего, мы будем ее делать дольше, чем профессиональные переводчики, которые заточены на быстрый подбор эквивалентов и грамотных гармоничных предложений. Еще очевидный момент — нам будет не хватать дополнительной пары глаз и рук, поскольку всегда есть необходимость, а объёмы со временем могут возрастать.
Другой подход — использование штатной команды переводчиков, которые также способны иметь все специальности и хранить в себе всю специфику продукта, который мы планируем локализовать, что, несомненно, плюс. А если подходить к вопросу о тестировании локализации, то у них всегда будет доступ к самому ПО под рукой, как и у нас самих.
Очевидный минус работы штатных специалистов — скорее всего, их невозможно будет подобрать на любую языковую пару. Или если у вас локализация происходит на несколько языков, это сразу увеличивает штат. Использовать такой подход не всегда релевантно.
Есть ещё один вариант — использование фрилансеров, то есть той команды, которая, по сути, может работать и в выходные, и в праздничные дни, и вечерами. Но тут всё упирается в знание специфики, требуется дополнительное составление стайлгайдов и направление их фрилансером. К сожалению, не всегда это срабатывает, но, тем не менее, это немного помогает им в плане специфики.
Отдельно стоит учитывать, что фрилансеры — это такие люди, которые могут заниматься непосредственно переводческой сферой, а потом потихонечку вдруг начинают заниматься саморазвитием в другом направлении и реже начинают брать ваши проекты на перевод. И тогда тоже мы сталкиваемся с тем, что фрилансеров требуется постоянно контролировать, отслеживать их уровень качества. А это уже дополнительная нагрузка на нас.
С этим могут помочь переводческие агентства, которые забирают контроль качества на себя. То есть мы можем масштабировать любой проект и выполнить практически любую языковую пару в тех условиях, которые нам предоставлены. Это могут быть даже супер-срочные проекты.
Минус такого подхода — цена. Особенно с учетом того, что мы тут платим не только фрилансерам, но и самим менеджерам компании. И снова боль в том, что они могут просто не знать специфики нужной страны или знать ее недостаточно, без составления инструкций, стайлгайдов и предподготовки проектов часто не обойтись.
Что стали делать мы
В нашей компании мы решили, что нам наиболее удобна история с выделением собственного отдела локализации, который в принципе и будет брать на себя функции тех четырех вариантов, о которых мы говорили выше. Получается, что менеджеры локализации включают в себя не только экспертизу переводчиков, но и людей, которые могут смотреть на сам процесс, и при необходимости оптимизировать его таким образом, чтобы выполнить проект в наиболее оптимальной обстановке, которая бы устраивала по цене, качеству и времени.
Важно отметить, что этот подход показался удобным именно нам, но это не серебряная пуля, которую можно советовать вообще всем. Подобный вывод отдела локализации не всегда оправдан — потому что, если у вас есть только один продукт, который требует единоразовой локализации, то, скорее всего, смысла содержать весь отдел у вас нет. Но если вдруг у вас много продуктов, которые надо переводить периодически, или продукт, который переводится на несколько языков сразу — то тут уже выбор будет более очевидным.
Итак, команду подобрали, теперь тестируем
Локализационное тестирование важно встроить же в тот же момент, когда идет основное тестирование. Само по себе локализационное тестирование мы можем разделить на несколько этапов.
Подготовительный. Команда локализации знакомится с командой разработки, условно — с самим контентом, который будет реализовываться, со всей сопутствующей документацией .
Региональная подготовка к культурной среде. На этом этапе важно посмотреть, все ли соответствует той стране, куда будет поставляться локализация. Отследить все возможные картинки, цвета, эмоджи и прочее. Не только текст.
Совокупная лингвистическая проверка и проверка функциональных и визуальных багов.
Какие бывают виды тестирования? Во-первых, это билд-тестирование. В этом варианте лингвистам выдается доступ к ПО, лучше к тестовой версии, нежели к проду, но варианты бывают разные.
Во-вторых, есть ещё и тестирование скриншотов. Тут лингвистам выдаются пакеты скриншотов с оригинальным текстом и с текстом перевода, который можно посмотреть, сравнить всё и заполнить специальный отчёт (он в этой схеме называется багрепортом).
Давайте чуть подробнее про лингвистические и функциональные ошибки.
Лингвистические — ошибки с языковой подоплекой, это в первую очередь отсутствие единообразия в переводе. В этом случае переводчик-лингвист может заметить, что где-то одна и та же кнопка с одними и теми же функциями чуть ниже на сайте переведена по-другому. Это может запутать пользователей, так что такого следует избегать.
Также это наличие непереведенного текста. Тут все просто, выпустили какое-то обновление небольшое и забыли перевести пару строк. Бывает. Или в ходе срочного хотфикса не перевели какое-то слово. Это тоже легко отлавливается и вносится в багрепорт.
Несоответствие перевода графическим элементам. Может случиться, что переводчик не совсем понял, о чем именно шла речь в оригинальном тексте, и перевел не так. Допустим, «Выпадающий список» он перевел просто как «раскрыть». просто. И если такой элемент появится на сайте или еще где то, то пользователю не всегда это будет понятно. Это тоже стоит отмечать.
Также есть разные лексические ошибки, которые может отловить только тестирование — слова, которые, казалось бы, перевели правильно, но в ходе тестирования видно, что оно тут явно не к месту, по стилю не совпадает или еще что-то. Плюс возможное несоответствие перевода контексту.
Функциональные ошибки — делят на три главных вида. .
Некорректное отображение текста. Например, слетела кодировка, и вместо текста отображается какая-то белиберда. И это, соответственно, надо обязательно исправить,
Неверные форматы дат, времени, валют. Все мы знаем, что в разных странах они отображаются по-разному. В Америке сперва идет месяц, потом число, в России — сначала число, потом месяц, и подобные примеры.
Несоответствие длины текста графическим элементам. Когда у вас идет кнопка, и она вылезает за текст, или текст вылезает за пределы кнопки, то, естественно, это смотрится некрасиво. Это может быть обусловлено тем, что в разных языках длина фраз бывает разная. Например, русский язык в целом чуть длиннее в интерфейсах получается, чем английский. Поэтому в таких случаях важно искать альтернативные варианты перевода.
Вот примеры.
Кстати, внизу справа — пример из настольных игр. В них есть термин «тайл», сама плитка как игровой элемент местности. А дальше вы можете читать текст правил и наткнуться на слово «файл местности» вместо «тайл местности», например. Всего лишь одна опечатка в локализации (или непонятное переводчиком слово) — и вот.
Инструменты тестирования
Скорее всего, если вы занимались локализацией, то вы знаете про переводческие платформы, на которых всё и держится — CAT-ы, в которые можно загружать тексты, которые надо перевести, а также добавить в них все необходимые команды. Это могут быть и переводчики, и менеджеры по работе с качеством, и редакторы, в общем, весь набор спецов, которых вы подключили к работе. Успешный вариант работы с CAT-ами заключается в работе с накопленной базой памяти переводов, которая может кочевать из проекта в проект и сильно экономить вам время. А главное — это помогает соблюдать консистентность.
В своей работе мы используем платформу SmartCat. Но сейчас, в принципе, таких платформ много — кроме SmartCat, есть ещё Crowdin, SDL, memoq, memsource, и все они так или иначе конкурируют друг с другом и иногда выбиваются в топ. И эти компании пошли намного дальше и сейчас встраивают в свои CAT-платформы еще и дополнительные возможности проверки качества. На их платформах существуют маркетплейсы по подбору фрилансеров, планируют еще и подключить сразу оплату услуг таких фрилансеров, что сильно упростит работу.
Что еще из полезного?
В первую очередь — онлайн-инструменты, как, например, ABBYY Aligner. Они позволяют брать оригинальный текст, если у вас есть какой-то файл, и файл перевода, сопоставлять их с памятью переводов, потом загружать в CAT-ы, использовать предперевод и выполнять перевод оставшихся сегментов, которые ранее не переводились.
Программы-глоссарии позволяют создавать на основе имеющегося у вас огромного пула текста переводческие термины, которые можно делить по тематикам и тоже загружать в CAT-ы.
FQA-инструменты, которые встроены в CAT-системы. Дополнение в том, что можно создавать некие шаблоны, по которым можно будет прогонять наши периодические проекты и отлавливать ошибки ещё быстрее. А LQA-инструменты позволяют независимо оценить уровень качества выполненного продукта и понять, требует ли он какой то доработки, или в целом уже готов для публикации.
Последний элемент — относительно новое введение в CAT-инструменты, это возможность интегрироваться с системами контроля версий, в которых работают разработчики. Таким образом, мы максимально сокращаем цикл разработки, сближаясь с их командой.
Благодаря таким настройкам наши файлы автоматически забираются из репозиториев и веток, в которых работают разработчики, и передаются в CAT-платформы, где переводчики их переводят. После выгрузки файлы попадают в работу лингвистам в автоматическом режиме или через назначение ответственным менеджером проекта. Также в автоматическом режиме эти документы загружаются в репозитории разработчиков. Соответственно, это сокращает наши временные затраты. Нам не нужно передавать файлы туда-сюда, создавать ТЗ и в целом заниматься дополнительной работой по организации процесса.
Подведём итоги
Давайте повторим еще раз основные преимущества интеграции локализации в процесс тестирования.
Во-первых, при этой интеграции мы поддерживаем полноту локализации. У нас есть время на то, чтобы все корректно перевести и проверить.
Во-вторых, благодаря этому можно удостовериться, что мы соответствуем культурным и языковым нормам, включая цвета, смайлы, эмоджи, жесты, и всё-всё-всё.
В-третьих, это гарантирует корректное отображение текстовых значений и соответствие элементам интерфейса.
И ещё одним большим плюсом является сокращение временных затрат. А временные затраты это ещё и финансовые затраты. Чем больше времени на локализацию, тем проще ее сделать, и меньше придется потом выправлять.
Спасибо, что дочитали. Если вдруг вы тоже занимаетесь локализацией и у вас есть вопросы — пишите в комментах, ответим :)
