Home

Автор: Михаил Кургузов

В первой статье цикла мы обсудили вводную про локализацию и её особенности. Пришло время поговорить про конкретные проблемы, с которыми можно столкнуться в процессе локализации. А ещё расскажу, как и кем выполнять тестирование.

Возможные проблемы

1. Плохое знание продукта и некорректное тестирование

   Тут многое зависит от того, кто именно будет проводить тестирование локализации. Представьте пример — у вас есть баг, при котором текст не появляется в нужном окошке. Но исполнитель не очень знаком с продуктом и вообще не знает, что в этом окошке должен быть текст. 

2. Отсутствие консистентности на разных версиях оборудования

   Это когда на десктопе у вас всё замечательно, а на мобильных устройствах что-то поехало, что-то не поместилось в элемент и прочее. Более того в зависимости от локализации может отличаться даже функционал конкретных окон. Например, что-то банально не поместилось в интерфейс, но это очень важно и это не сократить — тогда это можно перенести на другой интерфейс.

3. Интеграция с внешними сервисами

   Всегда важно смотреть на то, как у вас подтягиваются данные из внешних баз данных. Нужно проверять, всё ли корректно подставилось, уместилось ли.

4. Сжатые сроки

   На локализацию зачастую могут заложить время по остаточному принципу. Или не заложить вообще, да. И это не есть хорошо, поэтому для локализации лучше использовать раннее планирование.

5. Сложность построения процессов

   Очень важная штука, часто заключается либо в неиспользовании нужных инструментов для локализации, либо в необходимости соблюдать ИБ-политику компании. В итоге — проблемы с предоставлением тестовых доступов для лингвистов.

Основные инструменты

Вот список инструментов, с помощью которых можно существенно облегчить себе жизнь, если вы занимаетесь тестированием локализации.

Первое и самое главное — CAT-инструменты. Потому что, к сожалению, до сих пор встречается такое, что люди выполняют переводы чуть ли не в ворде. Чтобы переводить эффективнее и продуктивнее, используйте CAT-инструменты. Самые популярные —  SmartCat, CrowdIn, Trados от SDL, Phrase TMS, он же бывший Memsource, и прочие. У них есть функция глоссария и памяти переводов — если вы переводили один сегмент, то похожий сегмент переводить уже надо будет не с нуля. 

С их помощью получится масштабировать команду и организовать над проектом полноценную совместную работу.

Кстати, ещё в большинстве таких инструментов есть возможность формальной проверки качества (на те же опечатки, пунктуацию, следование глоссарию и прочее). Более того, иногда в них добавляют даже маркетплейсы, на которых можно подобрать исполнителей для локализации.

Кроме этих (привычных для отрасли) CAT есть ещё и CAT специализированные, настроенные для работы с ресурсными файлами.

С их помощью ресурсные файлы можно обрабатывать напрямую, без необходимости конвертировать их для работы, а также верстать интерфейсы. Из самых популярных  — Lingohub, Crowdin и Puzzle

Align-инструменты

Помогают создавать память переводов.

FQA-инструменты

Verifica, Xbench или Linguistic Toolbox от компании Lionbridge — всё это для автоматизированной проверки качества (орфография, пунктуация, единообразие, отсутствие запрещённой терминологии).

Глоссарные инструменты — помогают обрабатывать массивы текстов для составления глоссария по продукту, как следствие, обеспечивают максимально корректный перевод терминологии.

Continuous Localization, непрерывная локализация.

Это как раз синхронизация CAT-систем с системами контроля версий.

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

Вот как это выглядит на схеме.

Какие основные преимущества получаем от использования такого подхода?

Первый и самый главный — исключение человеческого фактора. Никто не застрахован от того, что что-то там забыли или не успели отправить на перевод.

Второй — банально сокращаются временные затраты. Локализаторам не нужно запрашивать у разработчиков ресурсные файлы в нужном формате. Если у вас JSON — работа идет непосредственно с ним.

Как и кем тестировать?

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

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

Небольшой совет — если планируете выводить продукт сразу на много рынков, лучше готовить псевдолокаль под каждую из стран.

Большой плюс такого метода в том, что его может использовать даже сотрудник, который не является носителем нужного языка. Да, какие-то баги вы потом, скорее всего, отловите, но это будет косметика.

Второй метод — тестирование по скриншотам. Вполне себе альтернатива предыдущему методу, если у вас ещё нет установленного билда или если нет доступов для лингвиста.

Тут тестировщики (или локализаторы) готовят пачки двуязычных скриншотов. Затем эти скрины сравниваются, заполняется баг-репорт и начинается баг-фикс.

Третий вариант, самый продвинутый — билд-тестирование. Здесь лингвист проверяет локализацию продукта непосредственно в установленном приложении. Плюсы — лингвист может отследить вообще все возможные моменты, не только лингвистику или соответствие языковым нормам другой страны, но и функциональность приложения под той или иной локалью.

Есть и минус — это сложнее организовать. Надо получать доступ для лингвиста, устанавливать продукт, нужны тест-планы, а то лингвист просто не поймёт, куда тыкать и что вообще проверять, чтобы попасть в нужный интерфейс. И уже потом заполняется баг-репорт.

Вот вам для примера один из баг-репортов нашего тестирования.

Итого, когда и что пригодится.

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

• Если у вас уже есть собственное подразделение для локализации, то можно переходить к более полноценному тестированию.

• А если у вас всё совсем продвинуто и команда локализации является неотъемлемой частью продуктовой команды — билд-тестирование для вас.

Это было про то, как тестировать. Теперь давайте обсудим, кем.

Фрилансеры

Пожалуй, самый просто способ собрать команду и найти исполнителей.

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

Минусы — классические для фриланса, может страдать обязательность. Да и зачастую наблюдается плохое знание продукта.

Отдел локализации

Когда речь заходит о сотрудниках отдела локализации, мы по умолчанию имеем в виду хорошее знание продукта. Но тут у вас могут значительно вырастать временные затраты, ибо вряд ли сотрудников выделят только под задачу тестирования.

Штатные лингвисты

Тоже гарантированные знания специфики и продукта, чаще всего без проблем получают нужные доступы, нет сомнений в их компетенциях.

Но тоже проблема с временными затратами, да и штатные сотрудники не будут работать по вечерам и тем более по выходным. Иногда бывает, что что-то надо было сделать ещё вчера, и тут время является определяющим фактором. Да, да, это плохо и надо всё лучше планировать, но подобное всё же встречается.

LSP, Language Service Providers

Это своего рода подрядчики, предоставляющие услуги локализации перевода. Тот же плюс, что и у фрилансеров — почти неограниченное количество языковых пар. Иногда даже можно делегировать им всю задачу ведения проекта целиком.

Минусы те же — возможно плохое понимание специфики именно вашего продукта. А ещё это, само собой, самый дорогостоящий вариант.

В третьей части цикла вас ждут:

• интеграция в процесс тестирования;

• чеклист;

• лучшие практики;

• полезные примеры.