что такое тестирование локализации

Тестирование локализации мобильных игр для чайников от чайника

Введение

Я уже полгода работаю тестеровщиком мобильных игр и хотел немного рассказать о своём самом любимом тестировании — Тестировании локализации. В этой статье я поделюсь своим опытом тестирования именно локализации, в основном будет опора именно на локализацию текста.
Немного о себе и о своей работе: Я придерживаюсь принципа, «Тестировщики — это такие люди, которые мешают программистам спокойно жить. Если бы не программисты мы бы сидели без работы и наоборот».

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

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

Как тестировать текст в локализации (что обычно делаю я)

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

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

Сочетание интерфейса и перевода

Заходя на какой-либо зарубежный сайт без встроенного перевода я часто обращаюсь к сторонним переводчикам, типа «Google translate» и естественно много сайтов просто ломаются и едут от родного для меня Русского языка. Читать такие сайты становится больно для глаз и всё печально. Так вот к чему, перейдем к нашим реалиям — мобильным играм. В мобилках в точности такая же беда длинный русский текст, ломает всю красоту интерфейса банально выезжая из полей выходя за краешки окна. Более извращённая проблема это поплывший текст в анимациях и всплывающих подсказках и других трудно уловимых элементах интерфейса. Тут важно просмотреть все точки где текст есть и может быть. Особенно сделаю акцент на «может быть» так как это ещё более интересное место для поиска багов.

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

Дак вот к чему вся эта история: тут как минимум две ключевые точки для тестирования это подгрузка переводов и подгрузка атласов с буквами

Почему тут есть, а там нет?! Интересные места в практике

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

Куда копать если всё-таки что-то не так?

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

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

Мои претензии к языкам

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

Начнём с самого простого и постепенно пройдемся по всем языкам с которыми я работал:

Полезные советы и хитрости при тестировании текста

Текстуры. Звук. Игровые события

Объединю все три пункта в одну сборную солянку, так как в мобильном геймдиве это мало локализуемые объекты. Ну камон, это вам не дорогущие игрушки от знаменитых студий.

Выделим основные аспекты, которые надо протестировать в каждой группе, начнём с текстур:

Как я писал ранее, в каждых галактиках, возможны свои непристойные вещи. Что уж говорить о странах, которые есть на нашей планете. Именно поэтому в зависимости от страны в которой игра будет распространяться, особенно если она суперконсервативная редактуре поддаётся многое (или всё) и набор акций и игровые объекты и сюжет и многое другое. Но опять же это справедливо, только для стран где язык локализации малораспостранённый. Например, если язык английски, то практически любую тематику можно запустить и в какой-то англоговорящей стране — это точно найдет отклик и будет воспринято правильно. А если допустим для англичан запустить праздник «Петра и Февроньи» вместо «Дня всех влюбленных», то это будет воспринято максимально странно.

Что общего или на что забивают локализаторы

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

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

Незаконченная вещь или вырезанный контент

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

Источник

Гайд по тестированию локализации и интернационализации, а также большой и полезный checklist

Привет, хабровчане. Сегодня я хочу осветить и обсудить тему локализации (L10N) и интернационализации (I18N). В интернете и, в том числе и на Хабре уже есть полезные и интересные статьи, но часто они дают более-менее общую информацию о подходах, без углубленной информации о том, что и как можно проверить. Я бы хотел с вами поделиться своим опытом, просуммировать кое что из статей, которые вы можете найти в интернете, а также постараюсь описать большой checklist с самыми распространёнными кейсами как для локализации, так и для интернационализации. В чеклистах я буду стараться упоминать только те проверки, которые вы можете сделать сами, без (глубоких) знаний языка новой для вас локали.

Что такое I18N, L10N и G11N?

Для начала давайте в целом разберём, что же такое интернационализация, локализация и, как следствие — глобализация (globalization) и для чего это всё нам нужно.

Зачем же нам нужна локализация? В первую очередь — распространение нашего продукта на глобальный рынок. Чем в большем количестве стран он будет доступен, тем больше ширится список потенциальных и фактических клиентов. Следующим пунктом является так называемый «customer satisfaction», ведь всем приятно пользоваться продуктом на родном языке, даже если вы хорошо владеете иностранными. Как следствие из пунктов выше — наш доход и прибыль увеличиваются! Стоит сразу сказать, что локализация не равно перевод. Локализация — это перевод и культурная адаптация продукта к особенностям определенной страны или региона.

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

Хоть английский и является самым распространённым интернациональным языком, но участники глобального рынка не ограничиваются одними США и англоговорящими странами. Показательным примером будет тот же Tik-Tok, активных пользователей которого насчитывают около 1 миллиарда, а количество скачиваний на сегодняшний день перевалило за 2.6 миллиарда. При этом большинство пользователей данного приложения из США, Индии и Китая. И такая тенденция просматривается на всём рынке приложений.

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

Такой вариант дизайна приложения имеет множество плюсов:

Интернационализация (I18N)

Звучит интересно, но как же нам заставить всё это работать именно в таком виде? Тут нам на помощь приходит интернационализация. Интернационализация — процесс разработки приложения, при котором код самого приложения независим от любых языковых и культурных особенностей региона/страны (cultural specific data). Internationalization принято сокращать как «I18N», где 18 — это число символов между «I» и «N». Суть интернационализации в том, чтобы сделать процесс локализации проще, дешевле и быстрее. Реализацию I18N обычно начинают на ранних этапах проекта, чтобы подготовить ваш продукт к будущей локализации.

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

Локализация (L10N)

Теперь можно поговорить чуть подробнее и о локализации. Локализация (localization или L10N) — это процесс перевода и культурной адаптации продукта к особенностям определенной страны, региона. Как упоминалось выше, на этой стадии участники разработки продукта работают с локалями — внешними ресурсами (файлами), которые подгружаются приложением для загрузки локализации для вашей страны/региона. Нюансов, на которые стоит обратить внимание, очень большое количество и их я приведу в разделе с чеклистом ниже, а пока хочу выделить основные зоны локализации:

Глобализация (G11N)

Завершая обзорную часть, хотелось бы ещё упомянуть термин Globalization (G11N), который используется для обозначения комбинации I18N и L10N. Также он используется для обозначения процесса, благодаря которому компания может выпустить свой продукт на глобальном рынке. Честно говоря не скажу, что есть конкретное определение глобализации вашего продукта (т.е. использования такого количества локалей, после которого ваша глобализация достигает 100%), поэтому я бы охарактеризовал процесс глобализации формулой вида: G11N = I18N + n*L10N, где n — количество локалей, используемой вашим продуктом.

Напоследок я бы хотел ещё указать сокращение для Translation — T9N. На практике используется редко, но тоже встречается.

Тестирование локализации. Метод псевдо-локализации (Pseudo-localization)

Разобрав что есть что, можем перейти непосредственно к тестированию локализации. Здесь я бы выделил 2 подхода: когда у нас есть локаль и когда её нету. С первым вариантом всё просто, берём локаль и проводим необходимый комплекс операций для проверки её качества. Но, как ни странно, 2й вариант тоже имеет место на жизнь и будет крайне полезен, когда интернационализация вашего продукта только завершилась и у вас ещё нету новой локали. В данном случае нам очень поможет техника псевдо-локализации (Pseudo-localization approach). В рамках этого подхода вам нужно подготовить псевдо-локаль (сделать это может и сам тестировщик, не имеющий знаний нужного языка), используя любой другой язык и добавить в файлы необходимые вам данные, например спец. символы определенного языка. Также можно добавить большее количество символов в строки, чтобы проверить будет ли обрезаться текст (truncate), ведь текст может стать длиннее после перевода на новую локаль и не вместиться в отведённое для него пространство. Ещё такой подход поможет вам найти проблему с объединением строк (concatenation) и проблемы, связанные с отображением шрифта, если таковые имеются. Для того, чтобы такие проблемы можно было проще найти, то в начало и конец строки можно добавить какой-нибудь символ. К примеру Microsoft использует такой подход ещё с 90х и вставляет квадратные скобки для обозначения начала и окончания строки.

Для более наглядной иллюстрации нашёл хороший пример. Вот скриншот оригинального приложения

А вот как это же приложение выглядит после подгрузки псевдо-локали с использованием всех подходов, описанных выше:

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

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

Internationalization checklist

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

Базируясь на вышесказанном, я бы выделил следующие пункты для проверок:

Localization checklist

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

Региональные и культурные особенности

Раздел, на проверки которого нужно обратить внимание в первую очередь. Сюда можно внести:

Календари

В мире используются разнообразные календари и это стоит учитывать, когда вы оцениваете кто будет вашей аудиторией и удобство использования вашего приложения для этого региона. В большинстве англоязычных стран, а также на территории СНГ используется Григорианский календарь (Gregorian Calendar). Если же ваше приложение нацелено на глобальный рынок, то вы должны иметь возможность использования других календарей. К примеру можно выделить следующие: японский, буддийский, хиджринский, еврейский лунный и тайваньский. Одно из основных различий между календарями заключается в том, что каждый из них может иметь разное значение года для текущей даты, в зависимости от старта исчисления времени текущего периода. Давайте рассмотрим несколько примеров различий разных календарей:

Продолжительность года и месяцев может варьироваться, также как и способы обработки високосных лет. Даже первый день недели может начинаться в день, отличный от понедельника (Европейские страны) или воскресенья (США). Ну а напоследок стоит отметить, что в некоторых локалях может использоваться более одного календаря как, например, в японской локали на Windows.

Форматирование дат

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

Для отображения даты обычно используется маска вида DD/MM/YYYY, где D — день, M — месяц, а Y — год. При этом количество букв в каждой части обозначает количество символов, которые будут указаны в каждой секции. Например для маски вида DD/MM/YYYY дата будет выглядеть как 16/06/2021, а для маски вида DD/MM/YY — 16/06/21.

По полноте отображения даты я бы выделил 4 основных формата:

Не стоит забывать и о символах-разделителях. В зависимости от формата, разделители могут отличаться. Самые распространенные — косая черта (/), точка (.), пробел ( ).

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

Варианты, представленные выше, даже достаточно экзотические типа J, M и т.д., на самом деле не являются чем-то из-ряда вон выходящим. К примеру все эти варианты для использования вы можете найти в системных настройках языка и региона в MacOS.

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

Подытоживая тему с датами, обязательно стоит упомянуть и специфическое написание дат для разных регионов/стран. Давайте сравним даты, написанные в формате таких стран как США, Мексика, Япония (используем длинный формат даты — long date):

Как вы видите из примера выше, названия месяцев и дней недели в разных регионах различаются. Однако есть и другие заметные отличия. В Мексике день стоит перед месяцем, всё пишется строчными буквами и добавлен артикль «de». В Японии день недели не показан, а для отображения слов «год, месяц, день» используются иероглифы.

Рассмотрим также пример с коротким форматом даты (short date):

В короткой дате мы снова видим, что в мексиканском примере порядок — день/месяц/год, в США это месяц/день/год, а для Японии порядок такой — год/месяц/день. Это может вызвать путаницу, если не следить внимательно. Например, в зависимости от того, в какой стране вы находитесь, дата, указанная как 07/04/01, может означать:

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

Форматирование времени

Как и в случае работы с датами и календарями, форматы времени не являются константой во всем мире. Хоть самым распространённым представлением является «часы, минуты, секунды», формат их написания и разделительные символы могут сильно различаться. Различия могут быть даже в рамках разных регионов одной страны. Ниже вы найдёте различные варианты отображения форматов времени и комментарии к ним:

Использование 12-часового или 24-часового формата.
В большинстве европейских и азиатских регионов используется 24-часовой формат времени вместо 12-часового (AM/PM), который, к примеру, используется в США. Также AM/PM часть может отображаться на языке страны, а местоположение этой части может быть как до, так и после числового значения времени.

Разделительный символ для часов, минут и секунд.
Хотя двоеточие (:) и является самым распространённым разделителем, в некоторых азиатских языках используются идеографические символы. Кроме того, в некоторых регионах требуется использование символов «h», «m» и «s» для соответствующей части при отображения времени.

Отображение часовых поясов.
Наиболее распространенным форматом отображения часового пояса является формат вида: GMT +3:30. Давайте его разберем на составляющие. Один из вариантов отображения часового пояса, по совместительству — самый распространённый, — это отображение времени по Гринвичу (используется аббревиатура GMT — Greenwich Mean Time) или его современной замены UTC (Coordinated Universal Time). Затем следует символ, показывающий смещение времени в положительную (+) или отрицательную (-) сторону от данного стандарта. Далее же идут конкретные значения смещения, отображаемые в часах и минутах. (В некоторых часовых поясах используется 30-минутное или 45-минутное смещение.) Например, часовой пояс для Бангалора, Индия, будет отображаться как UTC +5:30, а для острова Чатем, Новая Зеландия, это будет UTC +12:45. Другой способ отображения часовых поясов — использование названий местных часовых поясов.

При проверке отображения часовых поясов вы должны принять во внимание следующее:

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

По полноте отображения даты можно вновь выделить 4 основных формата:

Каждый элемент выше может писаться в своём формате, например:

Если углубиться и разбить время на элементы для использования, то я бы выделил следующие:

Интересный момент касательно обозначения времени до и после полудня: в некоторых системах, к примеру на Mac OS, вы можете задать свои обозначения вместо стандартных AM и PM.

Первый день недели

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

Форматирование чисел

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

Разделитесь для тысяч
Разделительный символ для тысячных значений отличается в зависимости от региона/страны. К примеру в США используется запятая (,), в Германии — точка (.), а в России, Беларуси, Швеции — пробел ( ).

Разделитель дробной части
В качестве символа разделителя дробной части обычно используются точка (.) или запятая (,).

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

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

Группировка чисел
Речь о количестве символов, содержащихся между каждым разделителем для всех групп цифр, которые появляются слева от десятичного разделителя (единицы, десятки, сотни и т.д.). В большинстве культур группировка идёт по 3 числа (к примеру Англия — 123,456,789.00), однако есть и исключения, например в Хинди все части числа, кроме сотен, группируются по 2, а сами сотни — по 3: 12,34,56,789.00

Местоположение символа процента (%)
Как и в случае со знаком отрицания, его местоположение и форма записи может варьироваться:

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

Форматирование значений валюты

В качестве разделителя десятичных значений и тысяч в сумме, чаще всего используется тот же разделитель, что и для чисел в этой локали, но бывают исключения. К примеру в большинстве мест в Швейцарии в качестве десятичного разделителя используется запятая (Sfr. 127,54), однако есть исключения, где используется точка (Sfr. 127.54).

Значение температуры

Важно следить правильные ли значения для подсчета температуры используются в вашей локали. Как правило используются значения в Цельсиях (3°C) и Фаренгейтах (3°F). Здесь стоит ориентироваться на возможные значения шкал Цельсия и Фаренгейта, а также на правила записи чисел, что мы уже обсудили выше.

Системы мер

В большинстве случаев вы столкнетесь с одной из 2х систем: метрическая система мер (метры, литры, граммы и т.д.) и английская система, её ещё называют имперская система (футы, дюймы, фунты и т.д.). Речь идет о таких измерениях как: длина, вес, площадь, объем, обозначение угла и т.п. Таким образом, необходимо убедиться, что если вы имеете дело с измерениями, то можете отображать их с помощью различных систем. Кроме того, убедитесь, что пользователю ясно, какая система используется в данный момент. В некоторых случаях английская/имперская система может быть разбита на подвиды для разных стран. К примеру Mac OS позволяет вам выбрать систему измерений из 3х вариантов: Metric, UK, US.
Интересный факт: зонд Марса был утерян, потому что его система наведения была разработана для одной системы мер, а ученые, использующие ее, думали, что это была другая система мер.

Где и как можно переключить региональные настройки на операционной системе вашего ПК

Вы можете изменить параметры используемые для вашего региона на странице свойств «Региональные параметры/Regional Options», затем переходите на «Язык и региональные стандарты/Regional And Language Options».

Буквенные и числовые значения

Алфавит/Шрифт

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

Также стоит учитывать и то, что в одной стране может быть несколько государственных языков. Тут уже вам решать, реализовывать ли все варианты или только определённые. К примеру в Беларуси государственных языка 2: белорусский и русский.
В дополнении, я хочу выделить ещё несколько нюансов, которые не связаны с отображением символов, но их всё равно важно учитывать при добавлении элементов нового языка:

Ориентация текста

Текст в разных регионах может читаться по-разному: у нас принято читать текст слева-направо сверху-вниз (построчно), в арабских странах, например, читают справа-налево (построчно), а в азиатских странах есть следующие вариации: чаще всего встречается вариант справа-налево и сверху-вниз (в столбик), реже — построчно.

Сортировка строк

Эта тема достаточно обширная. Здесь я пробегусь вкратце. Больше информации и примеров можно найти в документации Microsoft.
Каждый язык имеет свой уникальный набор правил (иногда более одного) описывающий как языковые строки должны быть «отсортированы» или «сопоставлены» в упорядоченный список. Ожидания пользователей от этих списков могут варьироваться в зависимости от того, где представлена ​​информация, например, таблицы, словари, телефонные справочники и т.д. Однако бывают случаи, например для файловых систем или веб-URL, когда согласованность компьютеров важнее правил любого человеческого языка. В таких случаях реализация сортировки может быть изменена под наши нужды. Стоит учитывать, что, как правило, пользователи вообще не думают о сортировке, пока с ней не что-то не так =)
В азиатских языках существует несколько различных порядков сортировки в зависимости от фонетики, радикального порядка и т. д., а сам фонетический порядок может зависеть от контекста.

Формат адреса

Адрес — это, пожалуй, самая нестандартная часть для проверки. Здесь стоит быть максимально внимательным и проявлять гибкость при проверке данных. Учитывайте то, что нету универсального порядка записи адреса. В разных странах способ написания может отличаться, к примеру где-то это может быть «Страна/Город/Улица/Дом/Квартира», а где-то «Улица/Дом/Квартира/Страна/Город». Также некоторые данные могут опускаться либо наоборот, добавляться, в зависимости от страны. Есть достаточно распространённый пример: часто бывает так, что какое-нибудь поле, например, «State» (для USA) или «Province» (для Канады) делают обязательным при вводе адреса. Для данных стран такой подход является верным и правильным, но ведь во многих других странах нету такого понятия как «штат». И тут мы сталкиваемся с проблемой, ведь пользователь не знает, что вписать в это, обязательное(. ), поле.
Крайне важно следить за способом ввода адреса, особенно если вы работаете на проекте связанным с магазинами, доставкой, логистикой и т.п. Но не редки и случаи-исключения, когда официально какой-то район может принадлежать одному населенному пункту, а на сайте он числится за другим. Как показывает моя практика, это скорее частные случаи, специально реализованные для удобства использования на конкретных проектах.
Ещё одним хорошим примером является проверка формата почтового индекса (ZIP code для США или Postal code для остального мира). Как вы уже догадываетесь, почтовый индекс не имеет какого-либо универсального формата или длины, а также он может состоять не только из цифр. Варианты написания почтового индекса можно привести следующие:

Формат телефонных номеров

И опять мы сталкиваемся с тем, что в мире нету универсального формата формат телефонных номеров. Здесь может разниться количество чисел, так и их группировка, использование дополнительных символов и символов-разделителей, таких как дефис (-), точка (.), знак международного префикса (например знак плюс (+)), круглые открывающие и закрывающие скобки (), пробел ( ) и т.д. Обычно для записи номера телефона используется 7-11 цифр.
Давайте рассмотрим несколько примеров форматов телефонных номеров для разных стран (без учета кода самой страны):

В некоторых странах наравне с международным стандартом набора номера, может использоваться еще и «полный локальный» вариант записи номера телефона. К примеру в Беларуси как раз есть оба варианта. Например, если стандартный номер телефона для населенного пункта имеет вид «123-45-67», то полная запись может выглядеть как 8-029-123-45-67 (полный номер телефона для набора внутри страны), так и +375-29-123-45-67 — вариант записи для международных звонков. Также вместо знака международного префикса (+) могут быть использованы его эквиваленты, чаще всего они цифровые. К примеру при замене и звонке из России в Беларусь, номер будет выглядеть следующим образом «8 – 10 – 375 – код города/мобильного оператора – номер телефона», а из Молдовы в Беларусь, следующим образом: «0 – 0 – 375- код города/мобильного оператора – номер телефона». Как видите, варианты форматов номеров может быть большое количество даже внутри одной страны.
Напоследок, стоит упомянуть про работу со службами, которые могут использовать короткие номера телефонов (к примеру 911, 101 и т.д.). Это ещё один хороший пункт для проверки.
Обязательно ознакомьтесь с тем, какие варианты чаще используются в необходимой вам стране/регионе!

Размеры листов бумаги

Кто бы ждал подвоха тут! И вновь все нюансы лезут из-за разных форматов. К примеру размеры бумаги в США и Канаде (например, Letter, Legal и т. д.) не совпадают со стандартами с других частей света. Например, в большинстве стран Европы и Азии используется всем нам известный формат «A4», который имеет немного другие размеры (297 x 210 мм) нежели чем упомянутые выше (например размер Letter в США составляет 279 x 216 мм).

Общие советы по локализации (потенциальные проблемы)

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

Изображения

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

Числовые и цветовые ассоциации

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

Рекламные ограничения

С рекламой всё тоже не так однозначно. Одни и те же вещи могут иметь различные возрастные ограничения в разных странах. К примеру кино, имеющее ограничение в США 12+, в странах СНГ может иметь ограничение 16+ или даже 18+ по тем или иным причинам. Что-то так вообще запрещается рекламировать в одном регионе/стране, но без проблем можно в другом.

Звуки

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

И давайте поговорим немного о функциональности

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

Заключение

Как вы видите, тестирование интернационализации и локализации — это интересное и комплексное занятие, на которое должно уделяться приличное время. I18N и L10N — очень важные аспекты современных приложений для запуска на глобальном рынке! Локализация не заключается в простом переводе текста с одного языка на другой. При этом заниматься тестированием интернационализации и локализации могут не только соответствующие команды, но и QA инженеры, которые никак не связаны с ними, так как многие аспекты можно проверить без (глубокого) знания языка локали!

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

Надеюсь вам была полезна данная информация и вы узнали для себя что-то новое. Буду рад пообщаться с вами по теме в комментариях!

Источник