Home

Автор: Илья Ивасюв, тестировщик компании "Лаборатория качества"

Оригинальная публикация: http://quality-lab.ru/localization-testing/

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

Что такое локализация?

Языковая локализация – это процесс адаптации продукта, который ранее был переведен на несколько языков, для определенной страны или региона.

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

Способ перевода
Может быть, для кого-то из вас это станет новостью (особенно если вы привыкли к качественному подходу к работе), но при переводе сайта на другой язык используются следующие варианты переводчиков:

• сотрудник;
• программное обеспечение (для автоматического перевода).

Как правило, пользоваться ПО для перевода сайтов не рекомендуется, особенно если речь идет о программах, которые автоматически переводят, а не предоставляют средства локализации (о них речь пойдет ниже). Но поскольку именно заказчик имеет право выбора варианта (из-за субъективных предпочтений или размера бюджета), тестировщикам нужно заранее выяснить, какими средствами проводится перевод.

Сотрудник
К сожалению, привлечение сотрудника – это не повод расслабиться в надежде, что перевод будет качественным, и вам нужно будет всего лишь «чисто проверить, что все, типа, работает». Дело в том, что в этом случае вас могут поджидать следующие неприятности:

• переводчик не лучшим образом владеет языком;
• переводчик недостаточно хорошо знаком с темой, которой посвящен переводимый контент.

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

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

Итак, если заказчик в силу некоторых причин (в первую очередь – финансовых) выбрал именно такой способ перевода, то для тестирования самого ПО можно применить тот же способ, что и по отношению к сотруднику-переводчику. То есть, изначально тщательно проверяется большой (желательно) фрагмент текста. При обнаружении ошибок под сомнение ставится как вся проделанная работа, так и целесообразность применения либо ПО вообще (и тогда придется убеждать заказчика в необходимости привлечения для перевода сотрудников), либо конкретной программы.

Моя любимая «четырехсимка». Вы подумали, что «Ясно» – это «ОК»? Нет, это локализаторы так перевели слово «Clear» («Стереть»).

Если программа-переводчик на первый взгляд хорошо справляется с заданием, то при тестировании нужно взять на заметку следующие факторы:

• программа не всегда работает стабильно; сбои при переводе могут вылиться в некачественно переведенные тексты, которые не всегда можно вовремя распознать (при проверке контента на родном языке ошибки обнаруживаются на порядок быстрее, чем на другом языке, пусть и хорошо изученном);
• при использовании обновляемого ПО сбои в работе могут появиться даже там, где их раньше не было, что отрицательно скажется на качестве перевода.

Для первого случая рекомендую изучить отзывы в сети об используемом программном обеспечении. Часто пользователи могут описать появление тех или иных ошибок, которые не всегда проявляются и не всегда описаны на сайте разработчика. Особенно это касается «плавающих» ошибок. Зная о них, можно регулярно проверять места их вероятного возникновения для своевременного обнаружения. Во втором случае рекомендую следить за историей обновления ПО: нередко разработчик публикует changelog, из которого можно узнать, где программа уже успела «наследить». Вот так, к примеру, выглядит changelog для Jenkins.

Средства локализации

Не могу обойти упоминанием и программы, применяемые в качестве средства локализации (например, Poedit). В этом случае программа всего лишь помогает создать переведенную копию продукта, используя уже переведенный заранее (без помощи данного ПО) контент. Частой проблемой в данном случае является вкрапление контента на оригинальном языке: из-за ошибки или сбоя программа «пропускает» уже переведенный контент и заменяет его оригинальным содержанием (то есть, непереведенным текстом). В качестве превентивной меры также нужно следить за changelog и за отзывами пользователей данного ПО: это позволит предусмотреть, в каких случаях данная программа может допустить ошибки.

Особенность конечного потребителя продукта

Часто ТЗ для проекта настолько объемное и специфическое, что запомнить все нюансы, детали и требования не представляется возможным: если основные положения еще удается держать в голове, то мелкие детали иногда упускаются из внимания. В нашем случае очень трудно запомнить нюансы, касающиеся культурных особенностей языка. К счастью, существует способ заставить себя их учитывать. Возможно, он покажется вам странным, но не удивляйтесь: тестировщик – творческий работник, он должен уметь перевоплощаться в разные типы пользователей для понимания их ожиданий на выходе. Умение мыслить, ожидать, рассуждать как пользователь позволяет лучше представить итоговый вид продукт, следовательно, выявить несоответствия в реализованной локализации.

Две разные культуры

Итак, изучив особенность аудитории, тестировщику нужно… «влезть в его шкуру»: пользоваться продуктом так, как это бы сделал предполагаемый юзер – китаец, кореец, немец, американец… Да, это трудно. Но творчество – это всегда труд. «Да где вы видели, чтобы тестировщики этим озадачивались? Обычно подобным никто не занимается!» – скажете вы и будете правы.

Отвечу: «А где вы видели, чтобы хороших тестировщиков было много?» Как правило, нам встречаются «обычные» специалисты, и очень редко – «необычные». Попросту говоря, к этому вопросу можно подойти «как все», а можно – как профессионал. В конечном итоге от этого будет зависеть качество вашей работы, ваша репутация и опыт работы.

Длина переведенных слов

Бывают случаи, когда в соответствии с ТЗ требуется придерживаться строго определенной длины слов; при локализации довольно трудно соблюдать это требование, не жертвуя качеством перевода. Схожая проблема возникает в ситуациях, когда перевод оказывается существенно длиннее оригинала и просто не вписывается в первоначальный макет интерфейса. Таким образом, в первом случае тестировщикам нужно проверять соблюдение требования при адекватном качестве перевода, а во втором – сохранение юзабилити сайта (например, отсутствие смещения верстки). Ниже рассмотрим тестирование обоих вариантов.

Длина оригинала равна длине перевода
Такие формулы применяются крайне редко, да и то только при переводе интерфейса меню; при этом допускается расхождение в 1-2 символа. В том случае, если на проекте все-таки пришли к решению применять именно такую формулу, придется определиться, допустимо ли использование сокращений для облегчения реализации.

1. Сокращения не применяются.
В некоторых проектах одним из требований действительно является максимальное соблюдение выбранной формулы без использования сокращения. Я не стану рассуждать о целесообразности данного требования. Замечу лишь, что в этом случае при тестировании придется обращать внимание на проверку следующих условий:

• количество символов оригинала равно количеству символов перевода;
• перевод при этом остается адекватным в рамках согласованной буквальности перевода;
• во всплывающих окнах переведенный текст кнопок остается в рамках самих кнопок.

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

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

2. Сокращения применяются.
Этот вариант – относительно более простой, но он также требует внимательной проверки на корректность сокращения. Не следует думать, что сокращения проверяются легко. К примеру, догадайтесь, какое слово было сокращено до «к-во»: «количество» или «качество»? Да, верно, это некорректное сокращение; даже в контексте не всегда можно понять, что имелось в виду. Также злую шутку со смыслом перевода могут сыграть сокращения-омонимы (на языке оригинала некое сокращение расшифровывается лишь одним способом, а при переводе может быть истолковано двояко). Тестировщики должны убедиться в том, что пользователи правильно поймут расшифровку сокращения в контексте.

Приведем примеры таких сокращений:

• АЗУ:
  – аналоговое запоминающее устройство;
  – ассоциативное запоминающее устройство»;
• АМС:
  – авиационная метеорологическая служба;
  – артиллерийская метеорологическая служба» (примеры взяты из книги «Справочник издателя и автора» Аркадия Мильчина);
• CAT:
  – computer-assisted trading (компьютеризованная торговля товарами);
  – corrective action team (группа, вносящая изменения);
  – capital acquisitions tax (налог на приобретение капитала);
  – customer activated terminal (терминал, активируемый клиентом).

Конечно, данный случай чаще встречается при переводе текстов (например, статей), чем, скажем, меню интерфейса. Если подобная ситуация во время проведения тестирования не возникнет – это прекрасно. Но вот за пропущенное неоднозначное сокращение заказчик спросит с тестировщиков.

Длина оригинала не равна длине перевода
При выборе формулы, разрешающей не придерживаться длины оригинала, можно столкнуться с другой проблемой: если интерфейс продукта не предполагает свободного изменения размеров, то существует вероятность необходимости применения переносов в некоторых словах.

Такая ситуация редко, но встречается, особенно при попытке создателей сделать верстку удобной одновременно для десктопных и мобильных систем, используя фиксированную верстку (это касается тех проектов, где уже бессмысленно объяснять заказчику нецелесообразность такого решения). В этом случае придется обращать внимание на правила переноса, ведь оригинал может состоять из 5-7 символов, а перевод – из 15-20 (например, sign up – зарегистрироваться).

В своей практике я встречал следующие ошибки:

• перенос был сделан не по правилам;
• при переносе слов не использовался знак переноса.

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

Параметры шрифта пользовательского интерфейса

Размер шрифта и его семейство заранее определяются дизайнерами. Этот момент очень важен, так как, например, размер шрифта восточных символов (китайских, японских) значительно больше размера европейских. Простой перенос параметров шрифта оригинала на перевод может привести к нечитабельности текста или, наоборот, к раздуванию его размеров. Поэтому важно, чтобы заранее определенные параметры шрифта были соблюдены.

Такие одинаковые и такие разные… Огромные и компактные, широкие и узкие, большие и маленькие… Три языковые версии Aliexpress.

Увы, на практике это правило не всегда соблюдается из-за невнимательности разработчика или из-за многочисленных правок, при которых проявляется наследственность параметров CSS. Исходя из этого, при тестировании локализации приходится проверять название и размер шрифта.

Обычно для проверок используются встроенные в браузер «инструменты разработчика» и/или расширения для браузеров. В первом случае для начала работы достаточно нажать F12 или комбинацию Ctrl+Shift+I. Я же настоятельно рекомендую пользоваться расширениями, так как они помогают существенно сэкономить время. Вот некоторые из них:

• Какой шрифт;
• Typ.io Peek;
• csscan;
• WhatFont;
• typ.io;
• FonFace Ninja;
• Type Sample;
• Fount.

Мне встречались советы по использованию программ типа FontMatch и Kleptomania, но они более пригодны для подбора шрифта, чем для его идентификации, а потому я не стал бы рекомендовать применять данное ПО при тестировании шрифтов.

Степень дословности перевода

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

При наличии каких-либо сомнений в дословности перевода лучше обсуждать их «на лету»: таким образом, на конкретных примерах будет отшлифовываться само требование по переводу, а тестировщики смогут лишний раз проверить, насколько они поняли степень «буквальности». Способ обсуждения «на лету» (переписка в чате или созвон) способно сэкономить время, так как баг при выяснении может оказаться вовсе не багом. Кроме того, обсуждения такого рода проблем чаще всего не ограничиваются несколькими предложениями, а общение вживую менее затратно по времени, чем «общение» в рамках баг-репорта.

Ввод текста в разных локализациях

Одно время пользователи сайта Aliexpress сталкивались с проблемой авторизации на русской версии сайта (подобное случалось не только с Aliexpress). На форумах предложили перед авторизацией… переключить язык сайта на английский. Удивительно, но после этого авторизация проходила правильно. Видимо, ошибка была допущена именно при русской локализации сайта.

Кстати, такая же ситуация может возникнуть и при поиске по сайту. Я лично встречался со случаями, когда в русской версии сайта в строку поиска вбивалось искомое слово, а система проводила поиск по каким-то иероглифам; при переключении сайта на английский язык все работало нормально.

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

После регистрации необходимо обязательно проверить авторизацию под только что использованными данными (я имел дело с системой, которая по некоторым причинам «обрезала» заданный при регистрации пароль).

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

RTL-языки

К языкам, написание которых происходит справа налево (right-to-left), относятся иврит, арабский, сирийский и некоторые другие языки. При тестировании RTL-языков нужно учитывать целый ряд особенностей, но для начала стоит сосредоточиться на следующих:

• «арабские» числа пишутся по-европейски, слева направо (здесь могут быть нюансы, и их нужно будет уточнять дополнительно, но в целом это универсальное правило);
• значки и иконки обычно отзеркаливаются;
• не все названия можно переводить (например, названия программ не переводятся и не транслитерируются вопреки расхожему мнению);
• перенос в тексте отсутствует.

При тестировании RTL-языков есть искушение в качестве проверки завести какой-нибудь текст (например, в строку поиска). Тестировщик, вбив что-то вроде «sfjlsdjflsdjf», обнаруживает, что текст печатается… слева направо. Баг ли это? Нет, это не ошибка. Благодаря использованию специальных библиотек, сайт «умеет определять», на каком языке пишет пользователь (точнее, какими литерами); полученную информацию он использует для того, чтобы на ходу поменять направление текста.

Значки и иконки отзеркаливаются.

Значки отзеркалены, название ПО не переводится и не транслитерируется, переносов в тексте нет.

Поэтому, проверяя RTL-тексты, используйте:

• «восточный» язык для проверки реализации ввода «справа налево»;
• кириллицу и латиницу для проверки обработки ввода «слева направо»;
• числа для проверки переключения направления на «слева направо».

Перевод сокращений или аббревиатур

Казалось бы, в этом нет ничего сложного: нужно просто расшифровать аббревиатуру на языке оригинала, перевести расшифровку, сократить ее – и получится «локализованная аббревиатура». Но не тут-то было.

Как бы вы, например, перевели FAQ? У нас принята аббревиатура ЧаВо (аллюзия на простонародный вариант «чего?», который звучит как «чаво?»). В своей практике я встречал вариант ЧЗВ («Часто Задаваемые Вопросы»): этот вариант, переведенный по всем канонам, не очень понятен (согласитесь, что трудно вот так сразу сказать, что в нем зашифровано), а потому и не прижился. И если кто-то из иностранных локализаторов использует ЧЗВ для перевода FAQ, то я уверен, что лишь немногие из пользователей догадаются, о чем идет речь. Таким образом, аббревиатуры должны быть не только правильно переведены, но и понятны.

Существуют определенные правила перевода аббревиатур, их нужно если не знать наизусть (вряд ли это кому-то под силу), то хотя бы держать под рукой во время работы над локализацией.

Наметим некий алгоритм работы с аббревиатурой:
1) Первым делом ищется аналог аббревиатуры на том языке, на который переведен продукт. Если такой существует – дело сделано.
2) Если аналог найти не удалось, а сама аббревиатура широко известна, то ее можно транслитерировать (пример – НАТО, НАСА, ФОРТРАН) или же оставить так, как есть (HTML, CSS).
3) Если аббревиатура не столь известна – ее можно перевести без сохранения сокращения (например, SMPs (Small and Medium Practices) – практика малого и среднего бизнеса, SME (Small and medium-sized entity) – малые и средние предприятия).
4) Если аббревиатура неизвестна и поэтому не переведена – не надо спешить оставлять все как есть (а именно такие советы вы можете встретить на различных форумах). Задача локализации – сделать понятную версию исходного варианта сайта для конечного потребителя. Но если переводчик и тестировщик не совсем хорошо понимают, что означает та или иная аббревиатура, то вряд ли она станет понятной и конечному пользователю, будучи оставленной в оригинальном написании или транслитерированной. В таком случае нужно выяснить значение аббревиатуры и потом уже решить, какой вариант локализации к ней должен быть применен.

Мета-теги

Нелокализованные мета-теги могут привести к ряду последствий, например:

• к проблеме СЕО и замедлению продвижения (вообще, СЕО должно вновь проводиться после локализации);
• к отображению названия вкладки на языке оригинала.

Наведите мышку на вкладку этой страницы в браузере. Видите всплывающие названия? А теперь представьте, что информация появилась на непонятном для вас языке. Казалось бы, мелочь, но клиента подобное упущение может насторожить (особенно если это серьезный сайт по оплате, продаже или страховке). Поэтому при тестировании важно убедиться в грамотной локализации следующих тегов:

• Title.
• Description.
• Keywords.

В Title проверяется перевод заголовка страницы. Если Title – динамический (то есть, формируется автоматически в зависимости от контента страницы), то следует запросить механизм формирования (разработчики объяснят, как это происходит) и протестировать, локализованы ли все нужные части этого тега. Аналогично тестируются и остальные два мета-тега. В этом случае проверка проще, так как теги «статичны», то есть, не меняют свое содержание в зависимости от открытой страницы.

Благозвучие

Начну с примера. Однажды в середине 90-х на украинском рынке появилась минеральная вода «Blue water». Реклама транслировалась по ТВ, водой торговали в магазинах и на рынках… Но популярностью она не пользовалась, да и не мудрено, ведь произношение «блю вотер» очень напоминало слово «блювота», что с украинского переводится как «рвота». Посудите сами, кто захочет покупать минеральную воду с такой ассоциацией?

Вот она, жертва упущения маркетологов.

И таких примеров немало. Я не стану подробно описывать изощрения маркетологов, которые, например, при продаже автомобилей в разные страны меняли названия машин (например, «Жигули» на «Лада») в том случае, когда возникали подозрения на их неблагозвучность. О тех, кто вовремя не подсуетился и не сменил название, вы можете прочесть в статье «Самые смешные названия…»; только представьте, что подобное может случиться и с вашим проектом. Поэтому настоятельно рекомендуется на определенном этапе тестирования попросить носителя языка, на который переводится продукт, проверить, нет ли в нем чего-либо такого, что может вызвать у конечного пользователя либо истеричный хохот (что не так страшно), либо, к примеру, гнев и попытки засудить за религиозные оскорбления.

Заключение

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

Локализация часто затрагивает как техническую часть, так и культурную. Этим и объясняется наличие столь разных проверок и подходов, которые не всегда можно подогнать под какие-либо шаблоны. Чем более разносторонними будут тесты – тем больше шансов, что продукт пройдет всестороннюю проверку и в итоге полностью удовлетворит как заказчика, так и пользователей.

Обсудить в форуме