Файлы локализации что это

Cotonti / Open Source PHP Content Management FrameworkContent Management Framework

Краткое описание файлов локализации

Cotonti спроектирован так, что позволяет легко локализовать (перевести) сайт (его интерфейс) на нужный язык. В базовый дистрибутив входят 2 набора языковых файлов — для английского и русского языков. Язык сайта, используемый по умолчанию, выбирается при установке.

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

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

На заметку: если вам требуется не просто локализация интерфейса, а мультиязычный сайт, где пользователь сможет сам выбирать предпочитаемый язык отображения интерфейса (и, возможно, содержимого), то вам стоит обратить внимание на статью «Делаем сайт мультиязычным».

Теперь поговорим, о том, что из себя представляют файлы локализации.

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

#1. Коды языков

#2. Размещение языковых файлов

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

#3. Структура файла локализации

Давайте для примера взглянем на основной файл локализации ` main.en.lang.php `:

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

В начале файла идет служебная информация в виде комментария формата PHPDoc, определяющая принадлежность к тому или иному расширению, копирайты и прочее.
Ниже строки ` defined(‘COT_CODE’) or die(‘Wrong URL.’); ` мы видим, собственно, определение языковых данных.

Текстовые данные задаются в формате как отдельные элементы плоского массива в виде ` ключ => значение `.

#4. Переключение языка на сайте

Существует 2 спосоа изменить язык интерфейса сатйа:

Изменить основной язык в файле настроек datas/config.php :

Эти изменения конуться всех не зарегистированных пользователей, а также всех новых пользователей.
Если вы хотите запретить пользователям менять язык интерфейса —это можно сделать в панеле управления опцией « Принудительная установка языка по умолчанию для всех пользователей » (Панель администрирования → Конфигурация → Локализация).

#5. Создание собственной локализации

В двух словах, чтобы создать собственную локализацию надо :

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

Источник

Локализация

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

Локализация приложений

Для отображения перевода строки слово на языке пользователя нужно в коде использовать следующие конструкции:

Если перевод строки слово не будет найден, система отобразит текст слово без перевода.

Пары «ключ—перевод»

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

Множественные формы строк локализации

Множественные формы перевода позволяют легко отображать в приложении слова в нужной форме, например: 21 запись, 22 записи, 25 записей.

Для получения нужной формы слова в PHP-коде нужно использовать следующую конструкцию:

Аналогичная конструкция для шаблонов Smarty:

Обратите внимание на отличие этой конструкций от синтаксиса перевода обычных (немножественных) форм, используемых в Smarty. Для немножественных переводов рекомендуется использовать в шаблонах Smarty конструкцию вида [`строка`].

Пример

Примеры

Сборка файлов локализации в режиме отладки

Пример

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

Пример

Локализация плагинов приложений

Локализация тем дизайна

Темы дизайна поддерживают 2 способа локализации текстовых строк:

Локализация темы дизайна в манифесте theme.xml

Такой способ локализации традиционно использовался в темах дизайна. Для локализации темы дизайна этим способом нужно добавить в корневой XML-элемент манифеста вложенный элемент по следующему примеру:

Ключи локализации в шаблонах темы дизайна нужно указывать в виде

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

Локализация темы дизайна с использованием gettext

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

А формы множественного числа в шаблоны дизайна нужно добавлять в формате

Локализация системных плагинов

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

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

Платформа

Магазин Webasyst

Помощь

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

Источник

Разбор формата файлов локализации Microsoft Office

Вариант в лоб

После недолгого поиска описаний аргументов функций по содержимому файлов в папке офиса был найден файл c:\Program Files\Microsoft Office\Office15\1033\XLINTL32.DLL. Где 1033 – LCID языка локализации (подробнее на msdn).

По беглому взгляду стало понятно, что в принципе я нашёл, что искал. Описания аргументов для функции AGGREGATE для обоих вариантов в файле было правильное. Выходило, что Excel неправильно парсит свой же файл локализации. Тогда было решено написать свой парсер файлов локализации Excel, либо хотя бы разобраться в формате файлов локализации MS Office.

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

Спускаемся глубже

Осталось решить проблему о том, какой функции какое описание принадлежит. Для этого я опять занялся поиском по содержимому файлов в папках MS Office, только в этот раз я искал названия функций. И мне повезло: рядом с файлом XLINTL32.DLL с описаниями функций лежал файл XLLEX.DLL, в котором было что-то похожее на названия функций:

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

Сначала я заметил, что и описания функций, и названия функций хранятся в dll файлах в ресурсе с именем «1» и типом «234». Вдумчивое изучение дампа ресурса из файла XLLEX.DLL (это тот, что с названиями функций), привело меня к следующему открытию: между участками с нормальным текстом идут участки с кракозябрами, которые должны нести определённый смысл. Тогда было решено эти участки изучить более глубоко, используя WinHEX и калькулятор. Возьмём участок кракозябров, которые идут перед участком с названиями функций:

Первые два байта: 01 00 – пока ещё не знаю, что означают. Вторые два байта 56 02 – если их перевернуть получится 0256, а если ещё перевести из шестнадцатеричной систему в десятичную – получится 598. Ровно столько, сколько имён функций, расположенных ниже в блоке осмысленного текста. Это уже радовало. Смотрим дальше: следующие пары байт, если их поменять местами, похожи на возрастающую последовательность. Так и есть, эти байты являются смещением описания отдельной функции от конца блока кракозябр. В самом деле, по скриншоту из файла XLLEX.DLL видно, что первой функцией идёт COUNT – 5 байт (0005h-0000h), вторая – IF – 2 байта (0007h-0005h), третья – ISNA – 4 байта (000Bh-0007h).

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

Разбираемся с кодировками

В принципе, этих данных, уже достаточно, чтобы сделать автоматический парсер файла XLLEX.DLL и вытащить названия всех функций на всех языках и много другой информации. Но в процессе возникла одна проблема: лишь очень маленькая часть локализаций хранит данные в UTF-8 формате. Большая часть данных хранится в каких-то совсем непонятных форматах: каждый символ кодируется 1 байтом с некоторым смещением относительно таблицы этого языка в UTF-8. Например, кириллические «С» и «Ч» были записаны как A1 и A7, а в таблице UTF8 у них номера D0A1 и D0A7, но при этом «р» была записана как C0, хотя она должна быть D180.

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

Из этого были сделаны некоторые выводы: первые два байта в описании блока – кодировка. Если первый байт = 0, то текст в этом блоке записан в Unicode LE, и тут всё просто. Если первый байт кодировки = 01, то надо смотреть на второй байт. Если второй байт = 00, то текст закодирован в простой кодировке UTF-8, тут тоже не надо голову ломать. Но что делать, если второй байт не равен 0?

Сначала я просто составлял словарь: значение второго байта – смещение в таблице UTF-8. Мне это быстро наскучило, и я стал искать закономерность. Очень скоро стало понятно, что смещение в таблице UTF-8 можно определить так: offset = (byte2-80h)*4+C0h. Единственная проблема, что для некоторых групп кодировок C0h приходилось менять на другое число.

В итоге, функции преобразования текста стали выглядеть вот так:

Докапываемся до самой сути

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

Для начала в файле XLINTL32.DLL я попытался найти что-то уже знакомое и похожее на данные из файла XLLEX.DLL. Знакомая картинка начиналась по смещению 0459h:

Т.е. начиная с 04B1h были описания блоков, такие же как в файле XLLEX.DLL, но выше этого смещения всё было какое-то непонятное. И не весь текст из ресурса подчинялся правилам, которое были выведены на основе разбора файла XLLEX.DLL.

Было решено в дальнейшем те блоки, что я уже научился распознавать называть блоками второго типа, а те, что ещё не умею – блоками первого типа, т.к. они шли в файле XLINTL32.DLL выше блоков второго типа.

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

В нём чётко видны такие строки: “Cut, copy, and paste”, “Print”, “For charts” и т.д. Кроме того, в hex кодах видна «характерная» лесенка из нулей и увеличивающихся значений. Первые два значения в этой лесенке — 46h и 6Eh – разница между ними в десятичном виде 40, т.к. текст явно задан в Unicode LE, то длина “Cut, copy, and paste” – будет 20*2 = 40. Сходится. Проверим другую пару значений: 78h-6Eh=10/2=5 – аккурат длина “Print”. Перепишем красиво все байты от смещения 07BE66h до начала осмысленного текста:
00 46000000
00 6E000000
00 78000000
…
FF E2020000

Общая длина получившейся выписки составляет 07BEABh — 07BE66h + 1 = 46h — где-то это уже было. Выходит, что описания элементов в блоке первого типа выглядят так: 1 байт тип элемента, 4 байта – смещение элемента относительно начала этого блока. Как позже выяснилось, типы элементов в блоке первого типа бывают 00h – обычный текст в Unicode, 0Ah – какие-то непонятные кракозябры, FFh – последний элемент в этом блоке.

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

Для начала я запомнил, что описание всех блоков второго типа заканчиваются по смещению 0A67h, а начинаются по смещению 0459h, итого длина описания блоков второго типа 0A67h-0459h+1 = 060Fh, а по адресу 0455h лежит четырёхбайтовое число 060Bh: 060Bh+4 = 060Fh. Выходит, по адресу 455h записана длина участка описания блоков второго типа.

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

Первый блок первого типа начинается там, где заканчиваются описания блоков второго типа – 0A68h.

А между началом ресурса и смещением 0455h находились байты, очень напоминающие возрастающую последовательность:

Попробуем вычесть из 01E8h (смещение 25h) число 011Ah (смещение 21h): 01E8h-011Ah=CEh, как раз длина второго блока. Ради интереса: вычтем 0330h (смещение 29h) из 01E8h (смещение 25h): 0330h-01E8=0148h, а 011Ah – похоже на длину первого блока. Выходит, что со смещения 1Dh идут описания смещений блоков первого типа. Записаны они в виде смещений начала блока от конца описаний блоков второго типа (или начала раздела с содержимым блоков – кому как удобнее). Осталось понять, что за байты лежат между 04h и 1D. Если вычесть 1D (начало описания смещений блоков первого типа) и 0455h (смещение по которому хранится длина описания блоков второго типа, т.е. заканчиваются описания блоков первого типа): 0455h-1D=0438h, как раз такое число лежит по смещению 19h. Что располагается в остальных двадцати одном байте между 04h и 19h – для меня загадка. Да и разбираться особо уже не хотелось, т.к. во всех файлах локализации офиса это смещение одинаковое.

Моя программа для чтения файлов локализации Microsoft Office: Ссылка на Я.Диск

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

4 байта — размер ресурса
21 байт – не известность
4 байта — количество блоков 1 типа * 4 = количество байт, которыми описывается карта блоков 1 типа
*Начало описания карты блоков первого типа*
4 байта — оффсет блока 1 типа от конца описания блоков. Разница между двумя соседними значениями — длина блока 1 типа.
*Конец описания карты блоков первого типа*
4 байта — количество байт, которыми описывается карта блоков 2 типа = количество блоков 2 типа * 17 байт
*Начало описания карты блоков второго типа*
1 байт — тип блока
2 байта — количество элементов в блоке 2 типа
4 байта — не знаю. По-моему всегда 0, может зарезервировано.
2 байта — порядковый номер блока 2
4 байта — длина блока второго типа
4 байта — оффсет блока второго типа от конца описания блоков
*Конец описания карты блоков второго типа*
4 байта — длина данных для блоков 2 типа
*Блоки первого типа*
1 байт — тип элемента — есди FF — этот элемент последний в этом блоке, если 00 — обычный текст в Unicode, если 0A — хз.
4 байта — смещение элемента относительно начала этого блока
Далее элементы
*Конец блоков первого типа*
*Блоки второго типа*
1 байт — первый байт кодировки
1 байт — второй байт кодировки
2 байта — количество элементов в блоке
*Карта элементов блока второго типа*
2 байта — смещение относительно начала элементов блока. Начинается со второго элемента. Если оффсет перелезает за FFFF, то после смещения добавляются ещё два байта = сколько раз по FFFF надо взять.
*Конец карты элементов блока второго типа*
*Конец блоков второго типа*

********************
По кодировкам:
Кодировка определяется так:
если второй байт == 0, то это простой Unicode Little Endian.
если второй байт == 1, то элементы закодированы в UTF8 и смещение можно определить по первому байту.
********************
Блоки второго типа бывают ещё нескольких типов
2, 3, 4 — обычные строки
1 — похоже на таблицу WordBasic, там в начале идёт таблица каких-то индексов (может индексов функций WordBasic)

Источник

Локализация продукта: 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). Тестирование других локалей должно быть гораздо менее ресурсоемким. Создавайте меньше тестовых случаев и делайте тестирование более целенаправленным. На данный момент мы создали множество структур тестирования шаблонов, которые автоматизируют и облегчают тестирование новых локалей.

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

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

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

Источник