Локализация приложения. Создание локализуемых пользовательских интерфейсов

Этот пост - попытка систематизировать всю имеющуюся на данный момент у меня информацию, касающуюся локализации приложений.

Пока мы пишем программы “для себя”, то о локализации, интернационализации и пр. заморочках мы как-то и не задумываемся. А зачем? Врядли кому-то в здравом уме придет в голову мысль “А не перевести ли мне свою утилиту на иврит, чтобы потом с такой программой работать?” Совсем другое дело, когда программа “вырастает из коротких штанишек” и на неё появляется спрос в других странах. Тогда, если спрос достаточно большой, можно (и нужно) взяться за локализацию - найти подходящий инструмент, нанять переводчиков (или переводить самому) и работать, работать, работать. Решение типа “Сделаю INI-файлик” вполне может подойти для небольших программок, но никак не для серьезных проектов с развитым интерфейсом, большим количеством форм, русурсов и т.д. - в этом случае стоит подыскать подходящее готовое решение. Собственно, основные цели поиска решения для локализации, которые были мне поставлены - это найти решение, которое позволит:

1. проводить локализацию руками не-программистов
2. работать с собственными словарями для перевода
3. поддержка XE2

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

TSILang components suite

• Разработчик: SiComponents
• Официальный сайт:
• Цена: от $259 до $399 . Пакет за $259 не содержит исходников (только DCU и OBJ)
• имеется .
• Дата последнего релиза: 05 мая 2012
• Поддержка Delphi XE2: имеется

TsiLang ® Components Suite позволяет добавлять поддержку для неограниченного количества языков , а также, создавать полностью локализованные версии продуктов, основанные на базовой версии проекта. Автоматически находятся и заносятся в список для перевода все необходимые элементы интерфейса пользователя, предоставляются удобные способы сохранения и управления переводами, и конечно, переключение языка интерфейса осуществляется “налету” как во время работы приложения, так и в режиме дизайнера , что позволяет тестировать интерфейс даже без компиляции и запуска приложения.

Мой тест.

Для тестирования я скачал и установил последнюю версию компонентов (6.5.4.7) и создал простенькое приложение на котором разместил Button, Label, OpenDialog, добавил ресурсные строки и константы. Специально на OnClick кнопки был создан такой “кривой” обработчик:

procedure TForm19. Button1Click (Sender: TObject ) ; begin ShowMessage("Привет, мир!" ) ; end ;

Локализация с TsiLang проводится следующим образом:

1. Запускаем TsiLang expert из меню Delphi: Tools ->TsiExpert

Здесь отображаются все формы проекта, а также компоненты , расположенные на этих формах. Теперь выбираем в меню File->Languages и редактируем список языков для нашего приложения. По умолчанию все языки имею названия типа Language1 , Language2 и т.д. я переименовал их так:

После того как была нажата кнопка “Ok” на главной (и единственной) форме приложения появился компонент TsiLang:

Теперь находим в эксперте кнопку “Save Project” и сохраняем наш проект. В TsiLang используется два типа файлов проекта:

1. *.sib - бинарные файл с переводами. Этот тип файла разработчики рекомендуют использовать, т.к. загрузка таких файлов происходит значительно быстрее, чем при использовании второго типа файлов
2. *.sil - текстовые файлы. Преимуществом этого типа файлов является то, что мы можем передать этот файл с утилитой “SIL Editor ” другому человеку для перевода.

Я сохранил свой проект в файл test.sil.

Теперь, находясь в эксперте дважды щелкаем мышкой по названию формы в списке - откроется окно редактора перевода:

В левой части окна (в дереве) редактора содержатся группы переводимых свойств компонентов и строк и, соответственно, справа - таблица для перевода. TsiLang может локализовать не только свойства компонентов типа Caption , Hint , Text и т.д., но также и строки из диалогов, например, на рисунке ниже представлены все строки для перевода из различных диалоговых окон, которые могут использоваться в приложении:

Начинаем переводить все строки с русского на английский. При переводе каждой строки редактор в отдельном окне показывает нам длину строки оригинала (в пикселях) и длину переведенной строки:

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

После того, как все строки переведены снова сохраняем наш проект. Теперь sil-файл должен содержать примерно такой текст:

последовательность символов #$ - это разделитель, который мы сами можем определить при сохранении файла. В процессе перевода строк в редакторе можно заметить, что TsiLang ни коим образом не учёл, что в pas-файле формы есть и секция resourcestring и const и даже строка текста в обработчике OnClick. Чтобы добавить эти строки к переводу необходимо выбрать в меню эксперта TsiLang:

• File -> Source -> With Form - чтобы выбрать строки из секции implementation модуля,
• File -> Source -> With Form - чтобы выбрать все строковые константы и ресурсные строки

В итоге откроется окно с результатами поиска в котором Вы можете добавить строку в список исключений или заменить её на вызов функции TsiLang:

Жмем в этом окне кнопку “Modify Source” и получаем такое сообщение:

Открываем pas-файл и видим следующую странную картину:

Мне показалось странным то, что TsiLang прекрасно определяет строковые константы в pas-файле и даже изменяет самостоятельно исходник, но почему-то “ленится” сам определить var - ну сделали бы доп.опцию в настройках проекта перевода типа “Определять VAR для констант со строками” и “Изменять настройки компилятора”. Но это ладно - окно с сообщением есть и то хлеб. Вот, что мне действительно не понятно, так это откуда TsiLang нашел в моем проекта непонятные иероглифы? Думал, что это может быть по причине того, что pas-файл сохранен в ANSI, но нет - сменил на UTF8, а проблема с иероглифами осталась…В общем странно это.

После того как строки были помещены в перевод можно снова открыть редактор перевода и провести перевод группы Strings (благо в редактор строки попадают без искажений):

После того, как все строки переведены, а sil-файл сохранен, можно организовать переключение языков в своей программе. В TsiLang каждый язык имеет свой идентификатор типа integer. Например, в моем случае идентификаторы были такими:

• Russian = 1
• English = 2

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

siLang_Form19. ActiveLanguage : = 2

Это приведет к тому, что TsiLang подгрузит из sil-файла строки на необходимом языке.
Что касается работы со словарем переводов, то может передавать в словарь (предварительно созданные) только уже переведенные строки. Для этого можно воспользоваться все тем же редактором переводов - жмем в редакторе кнопку “Add All”, которая предназначена для передачи в словарь всех переводов и получаем вот такое окошко для выбора необходимых опций передачи:

выбираем здесь файл словаря, жмем “Ok” и получаем все переведенные строки в свой словарик, который, кстати, выглядит вот так:

Впоследствии этот словарь можно будет использовать для автоматических переводов строк в своих программах. Ну и, как я уже говорил выше, для работы с SIL-файлами имеется отдельная утилита под названием SIL Editor, которая предназначена для переводчиков. Для чистоты эксперимента я скопировал папку с SIL Editor на флэшку и запустил программу с виртуалки “Windows XP Mode”:

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

Другие возможности TsiLang:

1. Импорт словарей из doc-, html-, xls-, csv-, po-файлов
2. Импорт ресурсных строк из исполняемых файлов
3. Наличие собственных компонентов - диалоги открытия файлов, метки, списки и т.д.
4. Ведение статистики по переводам

Довольно большой получился обзор, но инструмент того стоит. Подведем небольшой итог:

Достоинства:

1. Просто подключается к проекту - бросили компонент на форму, вызвали 1 метод и интерфейс переведен
2. Удобный редактор перевода - все строки разложены, что называется “по полочкам”, можно быстро ориентироваться по дереву в поиске нужных строк для перевода
3. Поддерживает как бинарные так и текстовые файлы с переводами. Создали sil-файл, отдали переводчику, потом пересохранили в sib и все готово - и программа быстрее будет работать и никто больше в перевод не залезет.
4. Наличие инструментов для переводчиков (SIL Editor, словари)

Недостатки :

1. “Корежит” русские строки в pas-файле. Пусть они и заключаются в комментарии, но, тем не менее, факт на лицо.
2. В процессе работы обнаружились непонятные ошибки при работе со словарями. Например, при переносе переведенных строк в словарь через раз появлялась ошибка выхода за границы диапазона.
3. Небольшие проблемы с окнами . Они, конечно, жить не мешают, но тем не менее, не хорошо, когда ты вызываешь словарь, а он какого-то лешего сворачивается в панели управления.

В принципе, указанные выше недостатки (за исключением второго) не такие уж и критичные.

DKLang Localization Package

• Разработчик: DKSoftware
• Официальный сайт: www.dk-soft.org
• Цена: бесплатно
• Дата последнего релиза: 25.12.2008
• Поддержка Delphi XE2: нет

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

Во-первых, настораживает дата последнего релиза - 2008 год - не факт, что компоненты заработают в XE2 без проблем.

Во-вторых пакет требует дополнительной установки компонентов Tnt Unicode Controls 2.3.0 , которые в 2012 году уже как бы и лишние - юникод и так поддерживается.

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

UPDATE : про DKLang Localization Package. Кратко и понятно.

UPDATE 2 : DKLang в XE2

EMS Advanced Localizer

• Разработчик: EMS
• Официальный сайт: www.sqlmanager.net
• Цена: 2 900,00 руб.
• Наличие ознакомительной версии: имеется
• Дата последнего релиза: 13 января 2012
• Поддержка Delphi XE2: имеется

Что говорят о своем продукте разработчики:

Advanced Localizer™ - это незаменимый пакет компонентов для Borland® Delphi®, позволяющий добавлять языковую поддержку Вашим Delphi® приложениям. Широкие возможности пакета Advanced Localizer позволяют быстро и просто локализовать свойства компонентов каждой формы, создавать языковые файлы с текущими значениями свойств компонентов, управлять файлами локализаций, а также назначать компоненты и их свойства, подлежащие локализации. Язык приложений, использующих Advanced Localizer , может быть переключен на другой непосредственно во время работы без последующего перезапуска приложения. Advanced Localizer также предусматривает возможность написания приложений-потомков, использующих языковые файлы, заданные пользователем.

Так как “незаменимых” у нас нет, то я провел свой небольшой тест этих компонентов все на том же маленьком приложении в 1 форму.
Мой тест
Скачал и установил пакет компонентов в Delphi XE2, открыл проект. В палитре компонентов Delphi появилась новая вкладка - EMS Advanced Localizer. С этой вкладки бросам на форму компоненты:

1. TQLanguageSource
2. TQFormLocalizer

У TQFormLocalizer в свойстве Source указываем TQLanguageSource и приступаем к работе.

Первым делом создаем файлы для локализованных строк - делаем два пустых файлика с расширениями *.lng (расширение по умолчанию для EMS Localizer) и называем их просто - rus и eng.

Можно и не создавать эти файлы - они создадутся автоматически при переводе

Теперь дважды щелкаем мышкой по компоненту TQLanguageSource для вызова менеджера языковых файлов:

Жмем единственную активную кнопку и добавляем файлы:

Теперь, по идее разработчиков, в списке менеджера должна появиться новая запись…однако её нет. Вот значения, которые содержатся в свойстве Languages компонента:

Однако список визуального редактора девственно чист. Ну да Бог с ним со списком - пробуем перевести наше приложение. Дважды щелкаем по второму компоненту (TQFormLocalizer) для вызова редактора перевода:

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

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

QLanguageSource1. ActiveLanguage : = 1 ;

При этом, если используется язык по-умолчанию (отмечен как “Original”), то у него индекс равен -1, а у остальных - начинается с нуля и наращивается по порядку в списке Languages.

Другие возможности EMS Advanced Localizer:

Подведем итог.

Достоинства:

1. Компоненты просты в использовании - на то, чтобы разобраться что и как работает ушло от силы минут 5.
2. Достаточно дешевые
3. Есть возможность хранить переводы в БД

Недостатки:

1. Нет поддержки словарей и, соответственно, авто-переводов
2. Проблемы в простеньком менеджере языков
3. Не поддерживается перевод констант и ресурсных строк
4. Нет инструментов для сторонних переводчиков

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

Korzh Localizer

• Разработчик: KORZH developers tools
• Официальный сайт: devtools.korzh.com
• Цена: от 149.0 EUR до 649.0 EUR
• Наличие ознакомительной версии: имеется
• Дата последнего релиза: 23 июля 2012
• Поддержка Delphi XE2: имеется .

Что говорят о своем продукте разработчики:

Один EXE-файл может поддерживать несколько языков. Дополнительные языки могут быть добавлены без перекомпиляции. Нет необходимости создавать множество exe-файлов
Строковые данные могут храниться как в стандартных ресурсных DLL, так и в специальных языковых файлах
При локализации код программы либо изменяется очень мало (буквально пару строк), либо не изменяется вообще. Localizer не меняет проект приложения, т.к. не используются какие-либо дополнительные компоненты
Локализованный проект можно запускать на компиляцию без установленного Localizer
Localizer переводит как ресурсы из VCL, так и любые другие ресурсы
Поддерживается хранение переводов в стандартном Хранилище переводов (Translation Repository) и их повторное использование в будущем
Поддерживает все сторонние компоненты и пакеты (например, DevExpress, TurboPower, ElPack, RX и т.д.)
Процесс перевода можно осуществлять с помощью встроенной утилиты Language Manager , свободно доступной для закачки переводчиками
Простой переход из Borland ITE (Integrated Translation Environment — интегрированная среда перевода)

Мой тест

Скачал триал, отличие которого от полной версии заключается в том, что Localizer переводит только первые 30 строк из каждой формы/файла. Установил После чего в главном меню Delphi XE2 появился новый пункт:

Выбрал в меню “Start project localization” в итоге меня попросили выбрать основной язык для проекта и указать папку для хранения языкового файла:

После нажатия “Localize mu project!” была запущена перекомпиляция проекта, а в dpr-файле проекта добавились необходимые модули и вызов методов Korzh Localizer’а:

uses {....} , LocOnFly, {Form18} ; {$R Project16.KLR} {$R *.res} begin LocalizerOnFly. InitReg ; {...} end .

Также, сразу же после информационного сообщения о том, что мой проект локализован запустился Language Manager:

В диалоге выбора нового языка для локализации есть замечательная опция - “Try to automatically translate via Google”. Однако опция эта в настоящий момент не работает:

Связано это не стем, что разработчики там чего-то не так сделали. Причина кроется в том, что Google перевел API Translate на коммерческие рельсы и, если не ошибаюсь, сделали доступ только по OAuth 2.0. Так, что, видимо в следующих редакциях Korzh Localizer’а эта опция пропадет либо будет использоваться для более доступных API, например, для Bing Translator API.

После добавления языка для локализации в Language Managere появляется таблица для перевода найденных в проекте строк. Помимо того, что непосредственно находится в проекте, Korzh Localizer также позволяет локализовать и строки, содержащиеся в других модулях Delphi:

После перевода Localizer может показать вам статистику - сколько строк переведено, процент перевода и т.д., однако и тут обнаружилась ошибка при переключении на вкладку “External Items”:

Помощник (назовем его так) предлагает выбрать модули для сканирования на наличие строк, а также, предлагает два варианта хранения строк - в ресурсном файле или в pas-файле:

Я оставил все настройки по умолчанию. В модуле было три строки - одна в секции resourcestring, вторая - в const и третья - в обработчике OnClick кнопки. В итоге Korzh Localizer определил следующее:

После нажатия “Next” IDE выдала сообщение:

После нажатия “Yes” в uses был добавлен новый модуль, содержащий секцию resourcestring в которой находилась одна найденная строка. Также изменился и обработчик OnClick кнопки, который стал выглядеть так:

procedure TForm19. Button1Click (Sender: TObject ) ; begin ShowMessage(SIgeaaoIeg) ; end ;

В Language Manager’е строка не появилась - может предполагается, что такие строки переведутся и без менеджера, а может они как-то хитро добавляются в менеджер - с этим я не разбирался детально. Мне осталось только проверить как происходит локализация. Для того, чтобы проект “заговорил” на другом языке достаточно было выбрать в главном меню необходимый язык:

После чего IDE снова сообщила, что файл был изменен и попросила его перезагрузить. Перезагрузил, собрал проект и получил приложение на английском языке:

Другие возможности Korzh Localizer:

1. Создание/импорт/экспорт репозиториев. Импорт и экспорт осуществляется в XML или TMX-форматах.
2. Поддерживает несколько языков для локализации - на каждый язык создается отдельный файл
3. Умеет работать с EXE- и DLL-файлами.

Достоинства:

1. Не требует наличия на форме каких-либо компонентов - все, что необходимо Korzh Localizer сам подключает в dpr.
2. Есть инструмент для переводчиков
3. Есть возможность создавать/импортировать/экспортировать репозитории

Недостатки:

1. Пока работал с инструментов обнаружил разного рода недочёты типа ошибок (см. скрины выше), недочёты в интерфейсе, наличие неработающих опций (в то время как Google уже давным давно закрыл доступ к API, а релиз локализера был относительно недавно). Все это создает ощущение, какой-то заброшенности проекта.
2. Ресурсные строки не попадают в Language Manager или как-то так хитро, что сразу и не сообразишь куда надо нажать или что куда добавить.

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

GNU gettext for Delphi and C++ Builder toolkit

• Разработчик: dxgettext.po.dk
• Официальный сайт: dxgettext.po.dk
• Цена: бесплатно
• Дата последнего релиза: неизвестно
• Поддержка Delphi XE2: нет

Несмотря на то, что поддержки Delphi XE2 нет, я все-таки решил скачать и попробовать в работе эту библиотеку. К сожалению после подключения dxgettext.pas к проекту посыпались ошибки - где-то вместо ansiString указали string, использовали методы, помеченные как depricated, использовали неверные параметры методов (может в Delphi 2009 такой код компилировался, но в XE2 - нет). В общем много чего повылазило… А жаль. В Lazarus я использовал эту библиотеку пару раз и, надо сказать, она мне понравилась. Конечно, для уже существующих проектов внедрять в работу DXGetText будет довольно проблемно, но для новых - вполне сносная и удобная библиотека. Есть несколько утилит для переводчиков, память переводов и т.д. В общем, если задумаете начинать проект на Delphi версии до 2009 и потребуется бибилотека для локализации и интернационализации проекта - попробуйте DXGetText .

i18n Package

• Разработчик: Kambiz R. Khojasteh
• Официальный сайт: www.delphiarea.com
• Цена: бесплатно
• Дата последнего релиза: 19 августа 2012
• Поддержка Delphi XE2: нет (согласно информации на оф.сайте)

i18n Package v1.10 for Delph i представляет из себя целую библиотеку компонентов, предназначенных для локализации и интернационализации проектов. Несмотря на то, что официально поддержка Delphi XE2 не заявлена эта библиотека без проблем установилась в Delphi XE2, поэтому я решил немного её протестировать.

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

Итак, работа по локализации с помощью i18n Package происходит следующим образом:

1. Бросаем на главную форму компонент TLocalizer
2. На все остальные формы (включая и главную) бросаем компонент для перевода - TTranslator
3. Для локализации диалогов также необходимо уложить на главную форму форму компонент TMessageBox и указать в нем необходимые заголовки, иконки и т.д.

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

Если необходимо сделать интернационализацию проекта - не трогайте ничего в поле “Property Value”, т.к. добавление новых языков и перевод строк осуществляется в отдельной утилите

После того, как необходимые элементы выбраны преходим на вкладку Export, указываем язык на котором наши строки написаны (т.е. Русский) и экспортируем строки в файл *.i18n:

Файл создан - можно приступать к переводам. В папке Bin библиотеки находится специальная утилита под названием i18n Editor, которая и предназначена для переводов.

Программка довольно простая в использовании и, думаю, Вы с ней очень быстро освоитесь. Скажу только, что i18n Editor способен “обучаться” - для этого программе необходимо указать папку в которой лежат уже готовые файлы *.i18n и программа автоматически их просканирует и вытащит из них новые для себя фразы.

После того, как все необходимые строки переведены возвращаемся в Delphi и указываем в свойстве URI компонента TLocalizer наш файл с локализациями. Теперь добавляем на форму компонент TCultureBox и в его свойстве Localizaer указываем Localiwer1 (если компонент не переименовывался).

Теперь можно запустить программку и убедиться, что перевод интерфейса происходит успешно:

Достоинства:

1. Для своей цены - $0.0 достаточно качественная (в Delphi XE2 работает отлично)

Недостатки:

1. Парсер не обнаруживает resourcestring и строковые константы, а обнаруженные и переведенные строки из кода программы все равно не локализуются.
2. Для каждой формы/модуля необходимо использовать свой TTranslator, что не совсем удобно. Логичнее было бы сделать небольшой сканер всего проекта на наличие строк как это сделано, например, у DXGetText

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

Kryvich’s Delphi Localizer

• Разработчик: Kryvich
• Официальный сайт: sites.google.com/site/kryvich/localizer
• Цена: бесплатно
• Дата последнего релиза: 7 января 2012
• Поддержка Delphi XE2: имеется

Ещё одна бесплатная библиотека для локализации и интернационализации приложений Delphi. По заявлению авторов проекта, с этой библиотекой локализация наших приложений должна пройти без каких либо проблем. Проверим, так ли это на самом деле.

Первым делом нам необходимо изменить опции проекта. Заходим в IDE: Project->Options->Linking и устанавливаем Map File = detalied

Теперь собираем проект и получаем три файла - *.exe, *.drc и *.map. Теперь запускаем консольную утилиту kdlscan.exe, которая находится в папке с библиотекой. Утилита запускается с параметром:

kdlscan

где - имя нашего exe-файла.

Сканер проходит по проекту и вытаскивает ресурсные строки и строки из свойств компонентов и укладывает их в файл с расширением *.lng. Этот файл - обычный ini-файлик, поэтому смело его открываем любым редактором и переводим все строки как нам необходимо.

После перевода сохраняем полученный файл, например, с названием english.lng .

Теперь приступаем к работе над проектом. Для поддержки локализации добавляем в uses главной форму модуль uFreeLocalizer.pas, также бросаем в папку с проектом модуль uStringUtils.pas и в любом удобном месте программы пишем:

FreeLocalizer. AutoTranslate : = True ; FreeLocalizer. LanguageDir : = ExtractFilePath (Application. ExeName ) ; FreeLocalizer. LanguageFile : = "english.lng" ;

Первые две строки можно записать в dpr-файле и там же подключить модуль локализатора. Все. Можно запустить программу и проверить работу.

Достоинства:

1. Очень простая в использовании библиотека
2. Компактная

Недостатки:

1. Нет словарей
2. Сканер не определяет жестко закодированные строки и константы

В целом библиотека вполне подойдет для проектов с небольшим количеством строк для локализации. Всё-таки работа через ini-файл даст о себе знать при большом объеме данных.

JVCL (JEDI Visual Component Library)

• Разработчик: JEDI Project
• Официальный сайт: jvcl.delphi-jedi.org
• Цена: бесплатно
• Дата последнего релиза: 11 апреля 2011
• Поддержка Delphi XE2: имеется

Кто не знает проект JEDI? Эту гигантскую библиотеку знают, наверное, все, кто хоть чуть-чуть работал в Delphi. В состав этой библиотеки входит компонент TjvTranslator , который позволяет локализовывать приложения Delphi. Судя по отзывам на различных форумах и в блогах, компонет довольно удобный и пользуется популярностью, но ставить весь набор JCL+JVCL ради того, чтобы взглянуть на работу одного чудо-компонента мне как-то не улыбнулось. Поэтому достоинства и недостатки искать Вам придётся самостоятельно. А я перейду к другим компонентам.

CnPack Component Package (CnVCL )

• Разработчик: CnPack
• Официальный сайт: www.cnpack.org
• Цена: бесплатно
• Дата последнего релиза: 5 ноябра 2011
• Поддержка Delphi XE2: имеется

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

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

Итак, после установки пакета cnVCL в палитре компонентов появляется сразу несколько новых вкладок:

на влкадке cnMultiLang расположены 4 компонента для локализации. Три из них: TCnLangManager , TCnLangTranslator и TChHashLangFileStorage или TChIniLangFileStorage должны быть размещены в приложении.

Надо сказать, что Alpha-версия дает о себе знать. Чтобы по-быстрее разобраться с работой этих компонентов я решил запустить небольшую демку, которая идет в комплекте с исходниками компонентов…она, конечно, открылась в Delphi XE2, но что-то уж как-то совсем странно:

Ну да это, в принципе, терпимо - исходник-то, вроде бы не сильно “покорежин” и разобраться с тем, что и как работает более-менее удалось. Суть работы такова:

1. Бросаем на форму приложения три вышеобозначенных компонента (я выбрал TCnLangManager , TCnLangTranslator и TChIniLangFileStorage )

2. Теперь выбираем TChIniLangFileStorage и добавляем в коллекцию Languages новые языки. Выглядеть это должно примерно так:

3. У TCnLangManager в свойстве LanguageStorage указываем наш компонент CnIniLangFileStorage1

4. Делаем двойной клик по TCnLangTranslator - откроется редактор для перевода строк:

5. Выбираем в дереве необходимый язык и жмем “Gen All” - должна собраться таблица со строками для перевода. У меня она оказалась вот такой:

6. Переводим необходимые строки, ненужные строки - удаляем, сохраняем полученную таблицу в файл. Получаем в итоге ini-файл, который надо бросить рядом с exe-файлом нашего проекта.

7. Пишем в любом удобном месте программы одну строку:

CnLangManager1. CurrentLanguageIndex : = 0 ;

В итоге это действие приведет к тому, что программа будет “переведена” на язык, который в LangugeStorage имеет индекс 0, т.е. в моем случае - на английский язык. Скрин приводить не буду, просто скажу, что компонент сработал.

Что можно сказать по поводу достоинств и недостатков этих компонентов? Думаю, что пока какие-либо выводы делать не стоит - всё-таки Alpha-версия и тут неизбежны всякого рода баги, странности поведения и т.д. и т.п. Если работа над компонентами продолжится, то скорее всего мы должны получить в свое распоряжение простенькие и легкие в использовании компоненты для локализации и интернационализации проектов. Пока же использовать эти компоненты в серьезных приложениях очень и очень рано.

TLang для FireMonkey

• Разработчик: Embarcadero
• Официальный сайт: embarcadero.com
• Цена: входит в стоимость Delphi
• Дата последнего релиза: 03 сентября 2012
• Поддержка Delphi XE2: имеется

Про этот компонент и работу с ним я рассказывать подробно не буду, т.к. в блоге уже есть статья, касающаяся работы именно с TLang в FireMonkey. Статья называется “ ” - в ней же Вы найдете достоинства и недостатки этого компонента. В Delphi XE3 работу компонента не проверял.

Multilizer

• Разработчик: Finnish technology company
• Официальный сайт: www2.multilizer.com
• Цена: 299 - 2900 EUR
• Дата последнего релиза: неизвестно
• Поддержка Delphi XE2: имеется

Несмотря на довольно не маленькую цену продукта я все же решил посмотреть, что из себя представляет данных продукт. Multilizer - это специализированный продукт, позволяющий локализовать различные типы приложений, файлов, dll и т.д. Также в комплект поставки входит набор компонентов для Delphi 5 - XE2. Компоненты я устанавливать не стал, а вот само приложение Multilizer решил испробовать на своем приложении.

Все начинается с тог, что мы создаем новый проект для локализации:

Выбираем первый вариант. Следующий шаг - выбор парсера:

На третьем шаге Multilizer просит нас указать ему файл для парсинга (указал exe), проводит парсинг и выводит результат сканирования:

Следующий шаг - это определение нативного языка приложения и добавление новых языков для локализации:

Multilizer позволяет также определять язык автоматически, но при этом почему-то просит логин и пароль к аккаунту Google 0_O (хоть не ключи от квартиры где деньги лежат). Эту функцию программы я проверять не стал.

После того, как проект создан, открывается окно редактора переводов, которые выглядит вот так:

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

К счастью в Android существует достаточно эффективный встроенный механизм для решения этой задачи.

Описание процесса локализации приложений приведено на примере Android Studio 2.3

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

Для этого нужно щёлкнуть правой кнопкой мыши на папке app в дереве проекта и в выпадающем меню выбрать New – Android Resource File. В открывшемся окне следует выбрать пункт Locale с помощью кнопки «>>» или двойного клика мышью.

В результате откроется список доступных языков. При выборе языка к имени папки с ресурсами в поле «Directory name» будет автоматически добавлен соответствующий суффикс.

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

В этом случае в названии папки появится дополнительный суффикс, начинающийся с буквы «r» (регион).

Имя файла локализации (поле «File name») необходимо задавать вручную. Настоятельно рекомендуется следовать стандартам Android и называть файлы локализаций strings. Конфликта имён это не вызовет, так как вновь созданные файлы будут находиться в отдельных папках, вложенных в папку Values.

Что касается файла strings.xml, который присутствует в папке Values изначально. После добавления локализаций, строковые значения из него будут использоваться по умолчанию, если для текущего языка, установленного в системе локализация отсутствует.

Само описание локализации абсолютно аналогично «обычному» strings.xml. Единственное отличие в том, что значения строковых ресурсов указываются на соответствующем языке.

Ниже приведён простейший пример.

Содержимое файлов strings.xml используемого по умолчанию и для английской американской локализации:

Multilanguage Application Hello World!

< resources > < string name = "app_name" > Multilanguage Application < / string > < string name = "hello_world" > Hello World ! < / string > < / resources >

Скриншот приложения:

Содержимое файла strings.xml для русской локализации:

Мультиязычное приложение Здравствуй мир!

< resources > Важно отметить, что установка необходимой локализации в приложении происходит полностью автоматически и не требует дополнительных действий. Со стороны разработчика нужно только создать необходимые файлы и заполнить их соответствующими данными. Единственными недостатками стандартного механизма локализации Android является невозможность задать язык приложения независимо от системы в целом и необходимость хранить ресурсы в текстовых файлах в формате XML. Но, в большинстве случаев его возможностей всё же хватает для того чтобы удовлетворить потребности разра

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

Теги

• Публикация
• Мировой рынок
• Разработка
• Тестирование

Примечание. Подробную информацию о том, как выводить свои приложения на новые рынки, вы найдете в руководстве Going Global Playbook .

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

Контрольный список

• Определите страны с благоприятными условиями для выхода на рынок.
• Используйте данные Google Play для поиска новых возможностей. Если ваше приложение опубликовано, вы можете просмотреть в Developer Console. В нем вы найдете страны, жители которых активно посещают страницу вашего приложения в Google Play. Локализовав приложение, вы точно увеличите число установок в этих странах.
• Используйте универсальный набор макетов с небольшими вариациями. Включите в приложение весь набор ресурсов по умолчанию, предусмотрите поддержку написания текста справа налево, используйте системный формат даты, времени, чисел и валюты.
• Учитывайте особенности развивающихся рынков. Ознакомьтесь с по оптимизации приложений Android для недорогих устройств и сетей с минимальной пропускной способностью.
• Включите все строки в файл strings.xml, сопроводите их полной и достоверной информацией, следуйте инструкциям Material Design по стилю и укажите контент, который не нужно переводить.
• Выполните перевод приложения, данных для Google Play и других ресурсов. Для этой цели вы можете обратиться к пользователям вашего приложения, в бюро переводов или воспользоваться сервисом перевода приложений в Google Play Developer Console или Android Studio.
• Обязательно проверьте работу приложения на стандартных устройствах для ваших целевых рынков. Проверьте ошибки в интерфейсе и при необходимости обратитесь за помощью к носителям языка.
• Выпустите бета-версию в основных странах, чтобы получить отзывы от реальных пользователей.
• Подготовьтесь к продвижению в мировом масштабе. Запланируйте кампании, ориентированные на установку приложения , и другие похожие мероприятия для разных стран. Используйте генератор значков Google Play для создания локализованных значков, которые можно будет размещать на сайтах и в маркетинговых материалах. Добавьте в рекламные материалы скриншоты локализованного приложения с помощью инструмента .
• Воспользуйтесь советами по оптимизации. Проверьте полноту данных для Google Play и получите другие полезные напоминания в Developer Console , которые позволят успешно опубликовать приложение.
• Проведите итоговую проверку и опубликуйте приложение. Вы выполнили все действия из этого списка? Тогда все готово к публикации и продвижению вашего приложения в целевой стране.
• Оказывайте пользователям поддержку после публикации приложения. Обязательно следите за оценками и отзывами, скачивайте статистику, чтобы вовремя узнавать о возникающих проблемах. Если это возможно, создайте отдельные сообщества или форумы для разных языков.

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

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

На некоторых платформах локализация осуществляется путем предоставления множества копий таких элементов пользовательского интерфейса, как таблицы строк и изображения. В WPF локализация не является столь же детальной. Здесь единицей локализации является XAML-файл (формально это скомпилированный BAML-pecypc, который встраивается в приложение). При желании поддерживать три различных языка, потребуется включить три BAML-pecypca. WPF будет выбирать из них подходящий на основании текущих настроек культуры на компьютере, на котором выполняется приложение. (Точнее - WPF будет использовать для принятия решения значение свойства CurrentUICulture в обслуживающем пользовательский интерфейс потоке.)

Разумеется, в таком процессе не было бы особого смысла, если бы нужно было создавать (и развертывать) универсальную сборку со всеми локализованными ресурсами. Это было бы не лучше создания отдельных версий приложения для каждого языка, поскольку приложение приходилось бы полностью компоновать заново при каждой необходимости добавить поддержку для новой культуры (или необходимости настроить текст в одном из существующих ресурсов). К счастью, в.NET эта проблема решается с помощью подчиненных сборок (satellite assemblies) , которые работают с приложением, но хранятся в отдельных подпапках.

При создании локализованного WPF-приложения каждый локализованный BAML-pecypc помещается в отдельную подчиненную сборку. Для того чтобы приложение могло использовать эту сборку, она размещается в подпапке под основной папкой приложения вроде подпапки fr-FR, предназначенной для французского языка. После этого приложение может связываться с этой подчиненной сборкой автоматически путем использования технологии зондирования (probing) , которая является частью.NET Framework, начиная с версии 1.0.

Самая большая трудность в локализации приложения заключается в рабочем процессе - другими словами в том, как извлечь XAML-файлы из проекта, сделать их локализованными, скомпилировать в подчиненные сборки и затем вернуть обратно в приложение. Это самая запутанная часть "истории" локализации в WPF, поскольку никаких средств (включая Visual Studio), обладающих поддержкой локализации на этапе проектирования, пока не существует. Вероятнее всего такие средства появятся в будущем, а пока WPF все равно позволяет выполнять все, что необходимо для локализации приложения, просто с применением чуть большего количества усилий.

Создание локализуемых пользовательских интерфейсов

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

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

Устанавливайте для свойства Window.SizeToContent значение Width, Height или WidthAndHeight, так чтобы размер окна мог увеличиваться по мере необходимости. (Опять-таки, это является обязательным не всегда; все зависит от структуры окна, но в некоторых случаях это очень полезно.)

Используйте для просмотра текста большого объема элемент ScrollViewer .

При желании локализовать приложение на язык, имеющий значительно отличающийся набор символов, понадобится использовать другой шрифт. Сделать это можно путем локализации в пользовательском интерфейсе свойства FontFamily или применения сложного шрифта вроде Global User Interface, Global Sans Serif или Global Serif, каждый из которых поддерживает все языки.

Может также потребоваться обдумать, каким образом компоновка будет работать при раскладке "справа налево" (вместо стандартной английской раскладки "слева направо"). Например, в арабском и иврите используется раскладка "справа налево". Этим поведением можно управлять посредством установки на каждой странице или в каждом окне приложения свойства FlowDirection. Более подробную информацию о раскладках "справа налево" можно найти в справке Visual Studio, в разделе Bidirectional Features (Средства двунаправленности).

Локализация - сложная тема. WPF предлагает работоспособное, но еще недостаточно зрелое решение. После того, как вы познакомитесь с основами, стоит заглянуть в документ Microsoft, посвященный локализации WPF, который доступен по адресу http://wpflocalization.codeplex.com вместе с кодом примеров. Можно ожидать, что в будущем поддержку локализации будет улучшена в инструментах проектирования, таких как Visual Studio и Expression Blend.

Подготовка приложения для локализации

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

en-US

Это укажет компилятору, что языком (культурой) по умолчанию для приложения должен быть английский (США) (очевидно, что при необходимости можно выбрать другой язык). После внесения этой корректировки процесс компоновки изменится. При следующей компиляции приложения будет создана подпапка по имени en-US. Внутри этой папки будет находиться подчиненная сборка с таким же именем, как и у приложения, и расширением.resources.dll (например, LocalizableApplication.resources.dll).

В этой сборке будут содержаться все скомпилированные BAML-ресурсы для приложения, которые раньше хранились в основной сборке приложения.

Формально приложение локализуется не для какого-то конкретного языка, а для культуры, в которой учитываются региональные отличия. Культуры обозначаются с помощью двух разделенных дефисом идентификаторов. Первый указывает язык, а второй - страну. Следовательно, fr-CA означает французский язык, на котором разговаривают в Канаде, a fr-FR - французский, на котором общаются во Франции. Полный список имен культур и их идентификаторов можно найти в справке Visual Studio, в разделе, посвященном классу System.Globalization.Culturelnfo .

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

Теперь при запуске данного приложения среда CLR будет автоматически искать подчиненные сборки в соответствующем каталоге на основании региональных параметров компьютера, и загружать подходящий локализованный ресурс. Например, при запуске приложения на компьютере с культурой fr-FR среда CLR будет искать подпапку fr-FR и использовать подчиненные сборки, которые обнаружит там. Это означает, что для добавления в локализованное приложение поддержки дополнительных культур, потребуется просто добавить соответствующие дополнительные подпапки и подчиненные сборки, не беспокоясь об исходном исполняемом файле приложения.

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

Сначала она проверяет самый специфический из всех доступных каталог. Это означает, что CLR ищет подчиненную сборку, предназначенную для текущего языка и региона (вроде fr-FR).

Если CLR не удается обнаружить такой каталог, она начинает искать подчиненную сборку, предназначенную для текущего языка (такого как fr).

Если ей не удается найти и такой каталог, тогда генерируется исключение IOException.