что такое код локализации
Локализация
Платформа «1С:Предприятие 8» локализована на 23 языка, включая английский, немецкий, французский, китайский, вьетнамский.
Механизмы локализации, заложенные в платформу, позволяют использовать различные языки как при разработке прикладного решения, так и при работе пользователей прикладного решения. Кроме этого, на уровне платформы поддерживаются различные национальные стандарты представления дат, чисел и т. д.
UNICODE
Поддержка различных языков в системе «1С:Предприятие 8» возможна благодаря тому, что все тексты конфигурации и базы данных хранятся в формате UNICODE. Этот формат позволяет включать в любую текстовую информацию одновременно символы различных языков. Таким образом, пользователь может вводить данные на различных языках, например, если описание товара или текст договора нужно включить на языке страны-производителя. В этом случае система будет не только корректно отображать такие тексты, но и выполнять по ним поиск и сортировку.
Два варианта встроенного языка
При разработке прикладных решений, активно используется встроенный язык. С его помощью разработчик может описывать собственные алгоритмы функционирования прикладного решения. Все операторы встроенного языка имеют как русское, так и англоязычное написание, которое можно использовать одновременно в одном исходном тексте. Для этого не требуется изменения каких-либо настроек конфигуратора — система будет правильно воспринимать операторы, написанные на обоих языках. Документация и синтакс-помощник содержат англоязычный синтаксис и синонимы для всех операторов встроенного языка.
Различные языки интерфейса платформы
Платформа может использовать различные языки для формирования командного интерфейса.
Локализация прикладных решений
Сопроводительные файлы на двух языках
Сопроводительные файлы, содержащие описание изменений платформы, поставляются как на русском, так и на английском языках.
Поддержка национальных дат, чисел
Для основных европейских языков поддерживаются национальные представления дат, чисел, а также порядок сортировки текстов. Существует возможность настроить конкретное прикладное решение на использование региональных настроек, которые приняты в странах, говорящих на данном языке. Причем, администратор информационной базы имеет возможность использовать как установки, принятые в операционной системе по умолчанию, так и собственные, отличающиеся от них.
Поддержка интернационализации во встроенном языке
Встроенный язык содержит набор функций, поддерживающих интернационализацию: НСтр (), ПредставлениеПериода (), ЧислоПрописью (), Формат ().
Отчеты, использующие текстовый документ или табличный документ, могут быть получены на языке, отличающемся от языка, который указан для текущего пользователя прикладного решения.
Механизм криптографии
Вопросы, задаваемые механизмом криптографии, формируются на языке интерфейса платформы.
Различные языки интерфейса программы установки
Программа установки обеспечивает установку на том языке, который наиболее соответствует установкам операционной системы на компьютере пользователя. Например, если операционная система использует латвийские региональные установки, то программа установки будет выводить все сообщения на латышском языке, если английские — то на английском.
Пролог
Начну с того, что за много лет работы программистом я неоднократно сталкивался с задачей внедрения в проект локализации в том или ином виде, но обычно это были решения, работающие на основе подгружаемого словаря с парами ключ-значение. Такой подход вполне оправдан для небольших проектов, но имеет ряд существенных недостатков:
Проанализировав эти проблемы, я пришел к выводу о необходимости создания собственной библиотеки для локализации проектов, которая будет лишена перечисленных выше недостатков. В этой статье я расскажу о принципах ее работы с примерами кода на C#.
Состав библиотеки
В сборку входят следующие проекты:
Основные принципы
Менеджер локализаций
Библиотека построена на базе плагинов и работает следующим образом: при запуске приложения создается менеджер локализаций (LocalizationManager), которому указывается путь к каталогу, где он будет производить поиск доступных пакетов локализаций (LocalizationPackage), каждый из которых отвечает за некоторую культуру (пакет русской локализации, английской и т.п.). После этого дается команда на поиск и загрузку дескрипторов всех пакетов, весь код инициализации выглядит примерно следующим образом:
Если все прошло без ошибок, в менеджере появится список доступных локализаций в виде их кратких описаний (дескрипторов, LocalizationDescriptor). Эти дескрипторы не содержат в себе какой-либо логики, а служат только лишь описанием того или иного пакета, который можно загрузить и начать применять в программе.
Список всех локализаций можно получить из менеджера:
Например, мы захотели подключить русскую локализацию, для этого необходимо загрузить ее непосредственно в менеджер:
После загрузки с локализацией можно работать — получать из нее строки, ресурсы и т.д., а если она более не нужна, ее можно выгрузить:
Важно! Можно загружать и выгружать неограниченное число локализаций, т.к. все они создаются в собственных доменах (AppDomain).
Пакет локализации
Каждая локализация представляет из себя набор файлов в отдельном каталоге, корневым для всех является тот, который был выбран при загрузке менеджера локализаций. В примере выше, это будет каталог [ProjectDir]\Localization, а непосредственно пакеты локализаций будут размещаться в каталогах [ProjectDir]\Localization\ru, [ProjectDir]\Localization\en и т.д…
Каждый стандартный пакет, обязательно должен содержать следующие файлы:
Пример для русской локализации:
Пример исполняемого кода для русской локализации:
Ниже будет дано пояснение, что такое метод Plural.
Применение пакетов локализации
Итак, мы создали менеджер локализаций и загрузили в него пакет с переводом. Теперь его можно использовать в программе тремя способами:
В качестве аргументов могут использоваться любые объекты. Подробнее об этом методе будет рассказано ниже.
Интерпретатор строк
Сила библиотеки заключается в ее интерпретаторе строк. Что же он из себя представляет?
Если вкратце, то это набор инструкций, включаемых в локализованные строки, с помощью которых можно адаптировать перевод под ту или иную культуру.
Интерпретатор строк вызывается описанным выше методом получения строки с заданными аргументами (при обычном обращении по ключу возвращается локализованная строка в «чистом» виде) или специальным методом GetFormattedString(string format, params object[] args), который работает точно так же, но при этом в качестве первого аргумента передается произвольная строка формата.
Теперь подробнее об этих инструкциях. Всего их две:
Формат инструкции:
Результат: встраивание в строку аргумента под номером index
Обратите внимание, что символ %, будучи служебным, должен экранироваться другим таким же символом, как в этом примере.
Аргументами могут быть числа, строки в двойных кавычках (сами кавычки экранируются, как и %, двойным повтором), аргументы строки по их номеру (%index) или вызовы других функций.
Встроенные функции и интеграция
В классе LocalizationPackage встроено несколько «стандартных» функций, часть была использована в примере выше:
Обратите внимание, что для функции допустимо задание списка ее псевдонимов (для краткой записи), например Plural может вызываться как через основное имя (Plural), так и через псевдоним (P), при этом регистр в названиях функций не имеет значения.
В качестве аргумента для InjectFormatterFunction может быть передан метод (MethodInfo) или делегат (в примере выше передаются делегаты).
Дополнительные возможности
Помимо основных функций, библиотека предоставляет еще два дополнения.
Отладочный режим
В Debug-версии библиотеки включена возможность не только получения локализованных строк описанными выше способами, но и их непосредственная запись:
В этом случае будет создана новая локализованная строка с указанным ключом и значением (либо перезаписана уже имеющаяся), а сам пакет сохранен на диск. Также в режиме отладки при попытке чтения строки с отсутствующим ключом, будет возвращено пустое значение, но при этом будет создана новая запись. Это удобно на начальном этапе разработки — нам не нужно заботится о наполнении словаря — он сам будет пополняться пустыми значениями, которые мы потом заполним данными.
В релизе функции записи недоступны, что вполне логично — промышленная программа не должна уметь пополнять свой словарь локализации.
Маппинги
Это наш десерт. Назначение — быстрая локализация форм, контролов и других сложных объектов.
Данная функция используется в демонстрационном проекте LocalizationViewer.
Приведу отрывок описания главной формы:
Заключение
Библиотека в скором времени будет опробована в одном из моих проектов, так что скорее всего будут кое-какие доработки, в основном направленные на расширение базового функционала пакетов. Следите за обновлениями на SourceForge и пишите свои комментарии и мысли по дальнейшему развитию библиотеки.
Возможно, вы скажете, что я изобретаю велосипед. Пусть так, но изобретать велосипеды — это мое хобби…
К тому же, это намного интереснее и полезнее в плане самосовершенствования в программировании.
По этой же причине здесь не будет ссылок на литературу и прочие источники информации — все было написано с нуля.
Гайд по тестированию локализации и интернационализации, а также большой и полезный 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 инженеры, которые никак не связаны с ними, так как многие аспекты можно проверить без (глубокого) знания языка локали!
Статью можно дополнить ещё большим количеством менее распространённых проверок для частных случаев, например лицензии, карты, обработка кредитных карточек и т.д. и я буду обновлять её по мере появления такого опыта. Также будет здорово, если вы поделитесь своим опытом в комментариях и эта информация появится здесь ещё раньше! Так мы сделаем эту статью ещё полезнее большему количеству людей!
Надеюсь вам была полезна данная информация и вы узнали для себя что-то новое. Буду рад пообщаться с вами по теме в комментариях!