Страна и язык не одно и то же, хотя в формах их регулярно ставят в одну связку и выводят одно из другого. Из этого вывода рождается целый класс дефектов: данные начинают проверяться по правилам той страны, язык которой случайно оказался выбран в интерфейсе. Ошибка незаметна, потому что выглядит логично: пользователь говорит на этом языке, значит, и данные у него такие же.
Разберём, почему два измерения нельзя сворачивать в одно, что именно подразумевается под локализацией и как построить проверку, которая не путает эти оси.
Почему страну нельзя вывести из языка?
Первая причина в том, что соответствие не однозначно ни в одну сторону. Один язык может быть официальным сразу в нескольких странах, а одна страна может иметь несколько официальных языков. Как только вы фиксируете правило «язык определяет страну», вы гарантированно ошибётесь на целом ряде пользователей.
Вторая причина практическая: язык интерфейса — это выбор человека, а не свойство его данных. Пользователь может читать интерфейс на одном языке, находиться в другой стране и указывать адрес в третьей. Все три вещи независимы, и каждая из них законна.
Третья причина связана с качеством проверок. Если правило выводится из языка, то дефект в проверке маскируется под верное поведение: тест проходит, потому что язык и страна совпали. Ошибка обнаруживается только тогда, когда их разводят намеренно.
Есть и ещё одна причина, менее очевидная. Письменность и раскладка влияют на то, как человек вводит данные, но не на то, какие значения допустимы. Смешивая эти вещи, легко получить форму, которая отвергает корректный ввод только потому, что он набран в другой раскладке.
Что такое три слоя локализации
Локализация — это не одно решение, а три, и они принимаются отдельно друг от друга.
- Язык интерфейса. На каком языке показаны подписи, подсказки и сообщения об ошибке. Это свойство сеанса работы, оно меняется свободно и не влияет на значения.
- Регион содержания. По какому набору правил трактуются значения: как читается дата, как записывается число, какой порядок полей ожидается. Это свойство данных, а не интерфейса.
- Формат данных. Как именно выглядит конкретное значение: порядок элементов в адресе, состав обязательных полей, наличие дополнительных уровней.
Три слоя могут не совпадать все сразу. Интерфейс на одном языке, регион содержания другой, а данные, введённые пользователем, относятся к третьей стране. Это не ошибка и не редкий случай: это нормальное устройство международного продукта.
Пока слои различимы в модели, всё работает. Как только их соединяют в одно поле «язык и регион», слой содержания начинает зависеть от выбора интерфейса, а это уже дефект.
Чем языковая метка отличается от кода региона
Языковая метка и код региона отвечают на разные вопросы, хотя записываются похоже и часто стоят рядом.
Языковая метка описывает текст: на каком языке показывать подписи, в каком направлении выводить строку, какие правила переноса применять. Код региона описывает значения: по какому набору правил трактовать дату, число, состав адреса и порядок его частей. Один и тот же язык в разных странах может требовать разных наборов правил для значений, и это нормально.
Практический вывод простой: никогда не используйте языковую метку как переключатель формата. Даже если сегодня совпадение выглядит полным, завтра появится страна, где на том же языке значения устроены иначе, и переключатель начнёт ошибаться молча.
Отдельно стоит помнить, что метка может содержать и необязательную часть с регионом. Это удобно для выбора правил, но не отменяет предыдущего правила: решать, по какому набору трактовать данные, должен тот, кто эти данные вводит, а не тот, кто выбрал язык.
Какие дефекты появляются при выводе формата из языка?
Самый частый дефект — проверка значения по набору правил соседней страны с тем же языком. Язык совпал, регион не совпал, и корректное значение объявляется неверным. Разбирательство обычно долгое, потому что в журнале ошибок видно только «значение не подходит», без указания, по какому набору правил оно проверялось.
Второй по частоте дефект связан с длиной текста. Один и тот же язык в разных странах даёт разную длину подписей: отличаются и названия населённых пунктов, и привычные сокращения. Если ширина колонки подбиралась по одной стране, в другой она окажется тесной.
Третий дефект — порядок частей. Правило порядка берут из одной страны, а применяют ко всем носителям языка. Как устроен порядок частей в международном адресе, разобрано в отдельном материале про формат международного адреса; здесь важно только то, что порядок привязан к региону, а не к языку интерфейса.
Четвёртый дефект тоньше: сообщение об ошибке выводится на одном языке, а пример правильного значения — по правилам другого региона. Пользователь видит согласованный текст, но противоречивый образец, и не понимает, что именно от него хотят.
Как строить матрицу проверок
Правильная матрица — это не список пар «один язык, одна страна». Это два независимых перечня, которые пересекаются выборочно.
| Ось | Что проверяет | Как выбирать значения |
|---|---|---|
| Язык | тексты, подписи, длину строк, направление | несколько языков разной письменности |
| Регион | правила значений, состав полей, порядок частей | страны с разным устройством адреса |
| Пересечение | согласованность подсказок и примеров | несколько намеренно несовпадающих сочетаний |
Такое построение экономит силы. Полный перебор всех пар быстро становится необозримым, а выборочные пересечения дают почти тот же результат при меньшем числе случаев. Ключевое — чтобы в выборке были сочетания, где язык и регион намеренно не совпадают.
Отдельно стоит проверять переходы: смена языка без смены данных и смена региона без смены языка. Именно на переходах проявляются дефекты, которые не видны в статичном состоянии.
Что важно разработчику
Первое: храните язык и регион двумя разными полями и никогда не выводите одно из другого. Даже временная связка в коде живёт дольше, чем планировалось.
Второе: пусть правила значений зависят от региона, а тексты — от языка. Это единственное разделение, которое выдерживает появление новых стран без переписывания логики.
Третье: в сообщениях об ошибке указывайте, по какому набору правил проверялось значение. Без этого поддержка будет получать жалобы, которые невозможно воспроизвести.
Четвёртое: держите примеры значений отдельно от правил. Пример на одном языке легко переносится в интерфейс на другом и начинает противоречить подсказке рядом.
Что делать дальше
Проверьте свою форму простым опытом: выберите язык, посмотрите, какие правила при этом применяются к значениям, и попробуйте поменять только язык. Если правила поменялись вместе с ним, значит, разделение ещё не сделано.
Дальше разберите выбор страны как отдельный элемент управления: сколько их в списке, как ищутся, как сортируются, что происходит после смены значения. Этому посвящён материал про тестирование поля выбора страны. А если набор стран ещё только формируется, начните со статьи про выбор стран для тестовых данных, где разобраны оси отбора.
Сверить, как выглядит распределение стран и регионов целиком, удобно по каталогу стран и регионов: там видно, какие группы представлены, и это помогает понять, где в вашей матрице остались незакрытые сочетания.
Сочетания языков и регионов, приведённые здесь как примеры, придуманы для объяснения подхода. Они не описывают распределение пользователей в каком-либо продукте и не являются выдержкой из настоящей статистики обращений.