Что такое код локализации

Пролог

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

Проанализировав эти проблемы, я пришел к выводу о необходимости создания собственной библиотеки для локализации проектов, которая будет лишена перечисленных выше недостатков. В этой статье я расскажу о принципах ее работы с примерами кода на 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 и пишите свои комментарии и мысли по дальнейшему развитию библиотеки.

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

Источник

Локализация продукта: 10 практических советов

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

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

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

Перевод, то есть замена одних строк на другие. Скажем, при локализации команд меню программы: “New file” заменяется на «Новый файл», переводятся названия месяцев, дней недели и так далее.

Адаптация. Здесь мы трансформируем форматы данных, логически зависимые от той страны, для которой создается модель локализации. Простейший пример — символ местной валюты ($ или какой-либо другой) и отображение числовых значений (с соответствующими десятичным и тысячным разделителями).

Ниже мы расскажем о подходах и инструментах, которые помогают нам с коллегами в локализации продуктов МойОфис для операционных систем Windows, Linux и macOS.

1. Всегда учитывайте важность основных составляющих локали

Язык локали крайне важен. Однако если локаль включает в себя только язык, то часть сведений, такие как форматы даты/времени и обозначения валют, могут быть установлены неправильно. Иногда в зависимости от региона отличается даже правописание на одном и том же языке: например, в случае с локалями английский — США (en_US) и английский — Британия (en_GB). Таким образом, если вы игнорируете регион — вторую существенную составляющую локали, — ваше приложение может оказаться недостаточно адаптированным под пользователя. Помните также, что зачастую библиотеки и внешние инструменты требуют дополнительной локализации: большинство распространенных инструментов поддерживают небольшое количество языков и знают небольшое количество локалей. Но как только вы выйдете на специфический регион, то вам нужно будет дорабатывать библиотеку, так как вам могут потребоваться и специфические языки.

Если вы, как и мы, разрабатываете приложение для нескольких локалей, то необходимо определить базовую (или дефолтную) локаль. Приложение будет использовать ее, если пользовательская локаль отличается от поддерживаемых. В МойОфис в качестве базовой локали используется английский — США (en_US), поскольку продукт разрабатывается с прицелом на международный рынок. Кроме того, базовая локаль важна для работы с автоматизированными средствами локализации.

2. Используйте системные настройки в своих интересах

Всякий раз, когда вы разрабатываете ПО, вы должны учитывать системные настройки пользователя — они влияют на всю операционную систему и установленные в ней приложения. Системные настройки позволяют изменять язык, который влияет на меню, и регион, который определяет другие параметры, такие как первый день недели, время/дата, календарь, форматы десятичного и тысячного разделителей. Пользователь может самостоятельно настроить некоторые параметры, определяемые регионом — доступные варианты зависят от платформы, на которой он работает.

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

Корректная работа с системными настройками довольно сложна. Вы поддерживаете ограниченное количество локалей, в том время как из системы могут исходить самые разные варианты. Что будет при обнаружении системой неконсистентной локали? Например, если в настройках ОС указана связка голландский — Перу (nl_PE; т.е. голландский в качестве языка и Перу в качестве страны), немецкий — Вьетнам (de_VN) или английский — Россия (en_RU)? Изначально мы в МойОфис размышляли, разрешать ли работу с неконсистентными локалями, но пришли к отрицательному выводу. Наш механизм всегда выбирает из числа поддерживаемых локалей ту, которая, по нашему мнению, наиболее подходит пользователю, без потери возможности использовать региональные настройки как «заданные пользователем». Например, со стороны пользователя нам поступает локаль финский — Финляндия (fi_FI). Мы видим, что не поддерживаем ни этот язык, ни этот регион. Смотрим, должны ли мы выбрать конкретный язык или регион, если нет — применяем дефолтную локаль, в данном случае это английский — США (en_US). При этом подтягиваем параметры из системных настроек: десятичный и тысячный разделители, валюту, ее позицию, паттерн даты и времени.

Такое решение оказалось верным и минимизировало рассинхрон. Плюс позволило нам работать с четко определенными файлами ресурсов и добавлять внешние библиотеки, которые мы смогли правильно настроить с самого начала (подробнее о них читайте в пункте 8).

Подытоживая, локализации можно добиться двумя способами:

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

Напрямую повлиять на процесс локализации путем гибкой работы с системными настройками пользователя.

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

3. Храните код и логику локализации отдельно

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

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

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

4. Обеспечьте независимость внутренних механизмов от локали

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

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

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

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

5. Подозрительные локалезависимые элементы — повсюду

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

Предположим, что два сотрудника, чьи локали: английский — США (en_US) и русский — Россия (ru_RU), выступают соавторами документа. Каждый из них может видеть одно и то же число, локализованное как «1,000.1» и «1 000,1» соответственно. В упомянутом случае локализация нацелена на форматирование чисел, а именно на символы десятичного и тысячного разделителя. В США в качестве десятичного разделителя используется знак точки (.). В России это запятая (,). Тысячным разделителем в США выступает запятая (,), в России — пробел. Аналогично локализация определяет внешний вид других символов (например, символов валюты), шаблонов (таких как шаблоны формул, времени и даты) и системы измерений для разных культур.

6. Информируйте переводчиков и дважды проверяйте качество их работы

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

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

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

Второй подход используем мы в МойОфиc, и заключается он в том, что две основные локали наших продуктов (en_US и ru_RU) мы ведем сами, а для остальных случаев задействуем пул проверенных внешних переводчиков. Мы сами выбирали подрядчиков под конкретные собственные требования и сотрудничаем с ними уже длительное время; это обеспечивает погруженность переводчиков в контекст.

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

7. Никогда не игнорируйте кодировки символов

Работая со строками, помните о разных стандартах кодировки символов (Unicode). Рассмотрим реальную ситуацию из нашей практики: в русской локали используется один символ пробела (обычный, U+0020), в то время как во французской локали – другой (non-breaking space, U+202F). При этом в системе устанавливается именно обычный пробел, а для конкретной локали «под капотом» из ресурсов вроде Общего репозитория языковых данных Unicode (CLDR) приходит другой. Затем в какой-то момент приложение выходит из строя из-за множества пробелов, обнаруженных системой.

Подобные проблемы могут быть связаны не только с пробелами, но и с другими символами – например, апострофом, который в определенных локалях является разделителем.

Помните о кодировках, если вы работаете со строками в контексте поисковых или сложных операций. Тщательно подумайте, как вы будете обрабатывать строковую информацию и различные операции, включающие строки. Никогда не подходите ко всем строкам одинаково, без учета кодировки символов. Например, не адресуйте все строки так, как если бы они были закодированы с помощью ASCII.

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

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

8. Используйте внешние инструменты

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

Еще один аргумент в пользу внешних инструментов — тот факт, что существенная часть функциональности зависит от календарей. Мы много работаем со временем, датами и числами с точки зрения формул и форматирования. Например, даты в электронных таблицах могут быть записаны во множестве форматов — DDMM, MMDD, DDMMYY и так далее. И при вычислений формул, содержащих ссылки на такие данные, необходимо правильно их локализовать и внутренне приводить к единому формату. Это позволит корректно вычислять, скажем, какой день по отношению к тому или иному дню является пятым; или каков результат, когда вы вычитаете дату из даты или добавляете год или 25 дней к дате. Именно календари выполняют такие операции.

Для произведения календарных вычислений мы используем Общий репозиторий языковых данных Unicode (CLDR), который предоставляет приложениям информацию о локали, и Международные компоненты для Unicode (ICU), кросс-платформенную библиотеку на Unicode с поддержкой глобализации для программных приложений. ICU является обширной, всеобъемлющей библиотекой и используется в некоторых операционных системах Linux и в офисном ПО LibreOffice. Используйте ICU, если вы разрабатываете крупномасштабное решение для локализации.

9. Помните, что разные платформы имеют разные локализации

Мы разрабатываем ПО для различных платформ, таких как Windows, Linux, iOS, Web и Android. Приложения для разных платформ (например, в случае с Android и Windows) используют разные локализации. Поскольку изменить эту ситуацию нельзя, стоит просто принять ее. Имейте в виду, что у вас будут разные локализации, и с самого начала планируйте весь процесс с учетом этого.

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

Скажем, версии МойОфис для macOS и iOS поддерживают локаль французский_Бурунди (fr_BI), в то время как некоторые версии для Windows ее не поддерживают. Другой пример — наша настольная версия для Windows поддерживает локали башкирский — Россия (ba_RU) и татарский — Россия (tt_RU), однако другие платформы их не поддерживают.

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

10. Делайте запуск новых локалей эффективным с точки зрения ресурсов

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

Запуск новых локалей должен быть простым с точки зрения всех задействованных процессов и элементов, включая код, ресурсы, ваше взаимодействие с переводчиками, использование внешних библиотек, методы тестирования и автоматизации. Масштабирование механизмов в контексте локализации тесно связано с процессами тестирования и автоматизации. Протестируйте функциональность максимум в одной или двух локалях. В нашем случае это локали английский — США (en_US) и русский — Россия (ru_RU). Тестирование других локалей должно быть гораздо менее ресурсоемким. Создавайте меньше тестовых случаев и делайте тестирование более целенаправленным. На данный момент мы создали множество структур тестирования шаблонов, которые автоматизируют и облегчают тестирование новых локалей.

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

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

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

Источник