Home

Автор: Симкин Алексей, Lead QA Enginner

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

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

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

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

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

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

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

1. В принципе можно пойти в лоб и создать по 1 приложению на каждый регион/страну. Такой вариант очень дорого и неудобно поддерживать, ведь работать нужно будет с каждым продуктом отдельно. Понятно, что никто так делать в наше время не будет.
2. Далее приходит на ум более удобный вариант — создать 1 приложение, которое включает в своём коде локализацию для всех необходимых вам регионов/стран. Вариант уже лучше, но и его достаточно сложно будет поддерживать. Да и хранить инфу о всех регионах/странах значит сильно увеличить размер приложения + велика вероятность, что данные локализации будут вплотную пересекаться с основным кодом приложения.
3. Как итог наших умозаключений, мы приходим к мысли, что было бы удобно создать продукт, в котором региональные и культурные особенности (текст, картинки, форматы даты, времени и т.п.) будут вынесены в отдельные блоки (никакого хардкода в переводимых местах), которые будут подгружаться при использовании того или иного региона/страны. Данный набор ресурсов называют "локалью" (locale).

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

• Помогает избежать хардкода для ресурсов, которые должны быть переведены. Если вы переключились на какой-то регион/язык, но видите текст не на ожидаемом языке — это явно баг, если вы изначально не решили, что определённые места не будут переведены (подробнее об этом можно узнать в разделе о псевдо-локализации ниже)
• Файлы, нужные для локали, уже предопределены, их удобно отслеживать, обновлять и создавать новые для новых локалей.
• В случае, если нужно добавить новую локализацию, то всё, что нужно сделать — создать нужные данные для вашего региона/страны и подгрузить их в приложении. И да, вы уже знаете, что и где нужно тестировать!
• Также стоит отметить, что не нужно хранить все локали изначально в вашем продукте. Такой подход уменьшает изначальный размер приложения.
• Баги, найденные при тестировании локализации, как правило, будут связаны непосредственно с локалью, а не с самим приложением. Если баг связан с кодом приложения, то скорее всего проблема связана с тем, что данный ресурс не был вынесен в локаль или не был переведён, т.е. это баг интернационализации вашего приложения, либо самой новой локали.

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

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

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

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

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

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

Глобализация (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

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

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

1. Установка и удаление продукта при использовании локали, отличной от дефолтной. Раз мы можем и должны использовать различные локали, то мы должны иметь возможность устанавливать и удалять приложение, используя любой язык.
2. Настройка приложения на локали, отличной от дефолтной. Все изменения в настройках должны сохраняться и использоваться.
3. Приложение должно работать на окружении, локаль которого отличается от дефолтной локали нашего приложения.
4. При запуске приложения на новой локали вам нужно проверить, что форматы даты, времени, спец.символы алфавита, денежных валют, календари и прочие вещи, связанные с культурными особенностями можно переключать в приложении без каких-либо ошибок (вручную или автоматически). Как правило такие ошибки выявляются при первом запуске новой локали.
5. Локализованный текст, изображения и прочие ресурсы не вшиты (hard-coded) в приложение. Баги такого рода вы найдёте достаточно быстро, ведь, к примеру, оставшиеся английские слова будут сразу видны на фоне азиатского текста.
6. Также я бы посоветовал обратить внимание на то, что документы (к примеру гайды, FAQ и т.д.) переключаются на нужный вам язык при смене локали.

Localization checklist

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

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

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

Календари

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

• 2016 год по григорианскому календарю — это двадцать восьмой год в японской эре Хэйсэй и 1437 год в календаре хиджры.
• Первый день года может не быть 1 января.
• Китайский Новый год приходился на 8 февраля (в 2016 году) по григорианскому календарю.

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

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

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

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

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

1. короткий (short) — 16.06.2020
2. средний (medium) — 16 Jun 2020
3. длинный (long) — 16 June 2020
4. полный (full) — Monday, 16 June 2020

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

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

1. День: 01, 1
2. Месяц: 06, 6, June, Jun, J
3. Год: 2020, 20
4. День недели: Monday, Mon, Mo, M, 01, 1

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

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

• День недели (Monday)
• Месяц (June)
• День месяца (1)
• Год (2020)
• Эра (AD)
• День года (153)
• Неделя года (23)
• Неделя месяца (1)
• День недели в месяце (1)
• Квартал (2)

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

• USA -Tuesday, October 12, 1954
• Mexico: martes 12 de octubre de 1954
• Japan: 1954年10月12

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

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

• United States: 10/12/54
• Mexico: 12/10/54
• Japan: 54/10/12

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

• United States: July 4th, 2001
• Mexico: April 7th, 2001
• Japan: April 1st, 2007

На сегодняшний день существует достаточное количество различных 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. Другой способ отображения часовых поясов — использование названий местных часовых поясов.

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

1. Не все страны используют местные названия для часовых поясов.
2. Аббревиатуры часовых поясов не уникальны.
3. Не во всех странах используется летнее время, при этом летнее время может начинаться и заканчиваться в разные дни для разных стран.
4. Один часовой пояс может иметь много разных названий в зависимости от страны и языка.
5. Как упоминалось выше, смещение может быть не только на пол часа или час, но также и на 15-минутное значение (к примеру UTC +12:45 для острова Чатем в Новой Зеландии).

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

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

• короткий (short) — 23:20 (часы, минуты)
• средний (medium) — 23:20:59 (часы, минуты, секунды)
• длинный (long) — 23:20:59 GMT+3 (часы, минуты, секунды, часовой пояс)
• полный (full) — 23:20:59 Moscow Standard Time (часы, минуты, секунды, полное локальное обозначение часового пояса)

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

• Часы: 1-12, 01-12, 0-23, 00-23, 0-11, 00-11, 1-24, 01-24
• Минуты: 01, 1
• Секунды: 01, 1
• Часовой пояс: GMT+3, Moscow Standard Time, Belarus Time, bymsq, Europe/Minsk, +0300, +03:00, GMT+03:00

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

• Часы (07)
• Минуты (08)
• Секунды (09)
• Обозначение времени суток (AM/PM)
• Часовой пояс/Временная зона (GMT+3)
• Миллисекунды (000)

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

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

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

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

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

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

   • США — запятая (1,147)
   • Германия — точка (1.147)
   • Россия, Беларусь — пробел (1 147)

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

   • США — точка (1,147.55)
   • Германия — запятая (1.147,55)
   • Россия, Беларусь — запятая (1 147,55)

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

   • -123
   • 123-
   • (123)
   • [123]

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

   • Латинские числа 0 1 2 3 4 5 6 7 8 9
   • Арабские числа ٠‎ ١‎ ٢‎ ٣‎ ٤‎ ٥‎ ٦‎ ٧‎ ٨‎ ٩
   • Японские числа 〇 一 二 三 四 五 六 七 八 九 十…
   • Корейские числа — 일 이 삼 사 오 육 칠 팔 구…

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

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

   • 98%
   • 98 %
   • %98
   • 98 pct

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

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

В качестве символа валюты может использоваться заранее определенный символ (например европейский евро — €, Доллар США — $, Новый Израильский Шекель — ₪), комбинация букв (Доллар США — USD, Белорусский рубль — BYN), а также их сочетание (к примеру новый тайваньский доллар пишется как NT$). Местоположение символа валюты может быть как до, так и после цифрового значения суммы. Стоит также отдельно выделить, что для отображения отрицательных значений сумм могут использоваться разные способы:

• Знак ставится до символы валюты и суммы: UK (-£127.54), France (-127,54 €)
• Знак ставится до суммы, но после символа валюты: Denmark (kr-127,54)
• Знак используется после суммы: Netherlands € 127,54-
• Вместо отрицательного знака используются круглые скобки: US ($127.54)

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

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

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

Системы мер

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

Интересный факт: зонд Марса был утерян, потому что его система наведения была разработана для одной системы мер, а ученые, использующие ее, думали, что это была другая система мер.

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

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

• Windows 10 — Control Panel > Clock, Language and Region > Region (часть настроек тут) > Additional Settings (большая часть настроек тут).
• Mac OS — Apple menu > System Preferences > Language & Region > General (часть настроек тут) > Advanced… (большая часть настроек тут)
• Ubuntu — System menu > System Settings > Region & Language

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

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

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

1. Усечение/обрезка слов и предложений.
2. Не вместимость текста в нужный элемент из-за его увеличения после перевода.
3. Закодированный (hard-coded) текст.
4. (Не) отображение спец. символов для данного языка.
5. (Не) отображение конкретного шрифта.
6. Объединение нескольких строк в одну.
7. Размер символов шрифта на экране (к примеру некоторые иероглифы могут быть слишком маленькие на вашем элементе, из-за чего их крайне сложно или невозможно прочитать).

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

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

1. Сам шрифт может весить достаточно много и, если у вас нету запаса памяти для таких прожорливых шрифтов, то в процессе работы ваше приложение рано или поздно может выдать Out Of Memory exception и прекратить работу.
2. На одном из моих game-dev проектов были случаи, когда возникали проблемы при игре людей с разными локалями, например English и French. В этих случаях игра, в лучшем случае теряла соединение с сервером, в худшем — крашилась. В такой ситуации, в наихудшей ситуации у вас будет сразу 3 разных локали: у каждого игрока своя + локаль сервера, не совпадающая ни с одной из локалей игроков. Так что есть смысл проверить конект всех локалей со всеми методом тестирования всех пар.

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

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

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

Эта тема достаточно обширная. Здесь я пробегусь вкратце. Больше информации и примеров можно найти в документации Microsoft.

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

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

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

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

• только цифры, например 5 цифр у США и Франции (85001) или 6 цифр у Беларуси (220123)
• почтовые индексы Канады состоят из двух групп по три символа — M5R 3H5
• в некоторых странах/регионах код страны или региона вставляют перед почтовым индексом — F-92300

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

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

Давайте рассмотрим несколько примеров форматов телефонных номеров для разных стран (без учета кода самой страны):

• Китай — 1234 5678
• Франция — 01-23-45-67-89
• Польша — (12) 345.67.89
• Сингапур — 123 4567
• Тайланд — (01) 234-5678 или (012) 34-5678
• Великобритания — 0123 456 7890 или 01234 567890
• США — (123) 456 7890
• Беларусь — +375-29-123-45-67

В некоторых странах наравне с международным стандартом набора номера, может использоваться еще и "полный локальный" вариант записи номера телефона. К примеру в Беларуси как раз есть оба варианта. Например, если стандартный номер телефона для населенного пункта имеет вид "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+ по тем или иным причинам. Что-то так вообще запрещается рекламировать в одном регионе/стране, но без проблем можно в другом.

Звуки

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

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

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

• гиперссылки могут работать некорректно либо переводить пользователей на некорректные версии сайтов.
• валидация полей ввода и вывода. Не всегда пользователи могут вводить данные на их языке при использовании их или другой локали, также как и вывод не всегда может отображаться корректно.
• как писалось выше, сортировка должна работать корректно на каждой локали.
• в некоторых случая шорткаты клавиатуры могут отличаться в зависимости от используемой локали. К примеру сочетание клавиш для файлов, которые в English локали завязаны на букву F (от слова File), для German локали желательно переделать, чтобы использовалась буква D (от слова Datei), т.к. в данном слове вообще нету буквы F. А такие языки как, например, Китайский, Японский и Корейский вообще не основаны на латинском алфавите. Для таких групп языков обычной практикой является сохранение сокращений исходного языка на основе латыни.

Заключение

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

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

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

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