Привет!
Итак, две части про локализацию и её тестирование позади (раз, два), пришло время для третьей.
Как и обещал, сегодня про подробности интеграции в процесс тестирования, чеклист и другие полезности.
С чего стоит начинать интеграцию тестирования в разработку? Правильно, как и любое другое важное дело — с планирования. Причём чем раньше вы всё это дело запланируете, тем будет лучше.
В нашем случае шаги интеграции в процесс разработки ПО выглядят вот так:
Планирование
Интеграция инструментов (например,как раз все те CAT-инструменты, что мы обсуждали в предыдущей статье)
Доступ к ресурсам
Создание тест-кейсов
Обратная связь
Мониторинг изменений
Доступ к ресурсам — штука местами сложная. В большинстве компаний разработчики по тем или иным причинам боятся предоставлять доступ к ресурсам, если вдруг нужно внести какие-то правки. Они считают, что «нет такого переводчика, который не мог бы что-то сломать в ресурсных файлах». На самом-то деле эта проблема решается, если просто, сделать отдельный репозиторий или ветку в нём, где переводчики и будут ковырять всё то, что им нужно, и забирать потом оттуда готовые файлики.
Важность тест-кейсов вы и без меня понимаете — без них вам будет очень сложно, особенно, если вы используете билд-тестирование.
То же самое касается и качественного фидбека, потому что коммуникация с командой локализации — это и вправду важно. Бывает, что команды разработки и команды локализации существуют довольно обособленно друг от друга, и в таком случае коммуникация между ними может превратиться в испорченный телефон. Наладили прямую коммуникацию между командами — получил профит.
И последний пункт списка — мониторинг изменений. Выкатили вы какой-либо хотфикс —, проверьте, нужно ли в нем что-то локализовать, попали ли в него все нужные данные.
Преимущества правильно проведенного локализационного тестирования
Разница в трудозатратах при багфиксе
Значительно дешевле отлавливать баги до официального релиза, не приходится регистрировать хотфиксы и тратить нервы. Нашли баг на раннем этапе — поправили его — всё здорово.
Более высокий уровень качества продукта
Тут всё просто, чем меньше у вас багов в продукте, тем меньше недовольных и тем меньше негативной обратной связи. Это важная штука — представьте, что вы чувствуете, когда видите косяки в локализации того или иного продукта. Например, сайт большой компании, мобильное приложение, компьютерная игра, меню в ресторане, да хоть характеристики смартфона на картонной коробке. Сразу же начинает казаться странным и нелепым, что какая-то большая и богатая компания не осилила просто взять и правильно написать какие-то фразы.
Например, 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 — когда первичный перевод выполняется машиной, а потом его уже редачит живой человек.
И самое главное — не забывайте про тестирование локализации, любое тестирование лучше, чем его отсутствие. Даже если у вас нет возможности провести нормальное полноценное тестирование вашей локализации, прогоните ваши тексты хотя бы через инструменты псевдолокализации. Часть багов всё равно отловите даже так.
Спасибо, что дочитали до третьей части, если у вас есть вопросы по локализации в целом или по ее тестированию — пишите в комментарии, постараюсь ответить.