Home

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

Итак, две части про локализацию и её тестирование позади (раз, два), пришло время для третьей.

Как и обещал, сегодня про подробности интеграции в процесс тестирования, чеклист и другие полезности.

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

В нашем случае шаги интеграции в процесс разработки ПО выглядят вот так:

1. Планирование

2. Интеграция инструментов (например,как раз все те CAT-инструменты, что мы обсуждали в предыдущей статье)

3. Доступ к ресурсам

4. Создание тест-кейсов

5. Обратная связь

6. Мониторинг изменений

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

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

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

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

Преимущества правильно проведенного локализационного тестирования

Разница в трудозатратах при багфиксе

Значительно дешевле отлавливать баги до официального релиза, не приходится регистрировать хотфиксы и тратить нервы. Нашли баг на раннем этапе — поправили его — всё здорово.

Более высокий уровень качества продукта

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

Например, Windows Vista и её не самый удачный заход на японский рынок. Или Amazon, который при выходе на рынок Швеции вообще спутал флаг Швеции с флагом Аргентины. И это я молчу про истории про разные знаки и жесты, которые в зависимости от региона могут быть как дружелюбными, так и вообще оскорбительными (писал об этом в первой части).

Более простой процесс локализации на другие языки

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

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

Близкое знакомство команды локализации с продуктом

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

И опять же — ту же псевдолокализацию, возможно, вполне себе осилят выполнить и они.

Наилучший пользовательский опыт

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

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

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

В-третьих, обеспечиваем соответствие культурным особенностям других стран.

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

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

Чеклист

Я ещё в первой части обещал вам чеклист в конце этого рассказа.

Вот он. Сразу — можете скачать его себе и использовать в работе. А я пока особо отмечу некоторые моменты.

Лингвистические аспекты

Чем раньше отловлены баги, тем лучше, проще и дешевле.

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

Орфография — проверяем, что все слова написаны корректно, не пропускаем никаких ошибок, опечаток.

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

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

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

И в зависимости от того, где эти кавычки стоят, ставятся нужные.

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

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

Есть множество моментов, связанных с лексикой. 

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

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

Конечно же, очень важно учитывать контекст.

Были случаи, когда executioner переводили и как “палач”, и как “исполнитель”. Хочется надеяться, конечно, что всегда имели в виду исполнителя.

А ещё в разных языках могут быть свои особенности, например, в польском — там элементы интерфейса программ переводятся не в неопределённой форме, а в повелительном наклонении. То есть не “показать”, а “покажи”. Да, теперь до вас докапывается ещё и интерфейс.

Вот пример некорректного перевода в таком случае.

Спецсимволы

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

Форматы дат

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

Ведь могут использоваться, например, разные разделители — где-то через точку, где-то через слэш. А ещё в разных странах вполне себе могут записывать различные числа с помощью букв.

Например, в иврите, там вообще своя атмосфера, которая основана на порядковом номере той или иной буквы в алфавите.

Существуют разные варианты сортировки списков — арабские цифры, римские, и прочее.

Могут использовать различные календари — Григорианский, Хиджи, Лунный календарь (мусульманские страны), календарь Минго (КНР). Причем в Китае вполне себе используют как календарь Мингоа, так и Григорианский, что доставляет неудобств при тестировании. Даже начало года может приходиться на разные даты, и не во всех странах это 1 января.

Отличаются и форматы валют — я про местоположение символа самой валюты, до числа или после него.

Что ещё разного 

• формат времени (12-часовой или 24-часовой), 

• разные разделители — двоеточия, буквы, 

• системы мер и весов (метрическая, английская)

• форматирование чисел (разные разделители разрядов, в США — точка, в странах ЕС — запятая)

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

• дробные разделители

• знак процента (может быть как в начале, так и в конце числовой записи)

• разные форматы отрицательных чисел (в Италии, например, минус может стоять с другой стороны, а в Турции отрицательные числа всегда пишутся в скобках). Если вы это не поддерживаете, то пользователь вводит -5, а получает просто 5. 

• разные часовые пояса — Китай находится в пяти часовых поясах, но используется стандартное китайское время, +8 для всего Китая. В ряде регионов отклонение от UTC вообще может быть в виде дробного числа, а не целого. Например, в Индии — 5 часов 30 минут. В Непале — 5 часов 45 минут. И если вы подобное в приложении не поддерживаете, то в отчетах будете получать кучу ошибок при том же планировании различных событий.

• платёжные системы — всегда проверяйте, что ваш продукт поддерживает платежные системы, распространенные в стране, в которую вы выходите. Например, на скрине — 4 самых распространённых платёжных системы в Китае.

• форматы адресов — в зависимости от страны, в записи адреса могут быть не самые привычные символы, а также разный порядок записи адреса (город, регион, индекс, или наоборот). 

• форматы телефонных номеров — тут всё понятно в целом, смотрите скриншот.

• бумажные форматы — да-, да, они тоже отличаются, и если у нас в стране привычны А4, А2, то в США вы будете встречать Letter, Legal и т.д. В Японии, как обычно, своя атмосфера, и там используются свои форматы бумаги вида Shiroku ban, Kiku ban.

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

• Compliance testing — последнее в этом списке, но не последнее по важности. Это вопрос соответствия законам и нормам культуры и морали страны или региона. Как пример — игра Hearts of Iron 4, в 2018 она выходила на китайский рынок, и в итоге релиз немного подзадержали, потому что в игре присутствовали изображения уйгурского и тибетского флагов. Что в Китае, прямо скажем, не сильно-то и приветствуется.  Подобное было и с World of Tanks в 2014, игроделам даже пришлось перерисовывать дизайн танков, чтобы игру нормально пропустили на китайский рынок.

Best practices

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

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

Не забывайте и про регрессионное тестирование. Если нашли баг, пофиксили его, снова выкатили всё на прод — проверьте сам факт проноса фикса.

Отдельно я бы выделил и необходимость написания тест-планов. Особенно, если используете билд-тестирование, тогда вы ощутимо упростите жизнь лингвисту.

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

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

Ибо для приложений куда лучше подход Machine Translation and Post-Editing — когда первичный перевод выполняется машиной, а потом его уже редачит живой человек.

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

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