Многоязычный интерфейс приложений в delphi


Многоязычный интерфейс приложений в delphi

Профиль
Группа: Участник
Сообщений: 12
Регистрация: 11.9.2006

Репутация: нет
Всего: нет

Здраствуйте Ув. коллеги.

Подскажите пожалуйста, как сделать мультиязычный интерфейс в приложении? Например, по умолчанию интерфейс на русском, а при клике на пункт меню English, все компоненты меняют свои кепшины.

Профиль
Группа: Участник Клуба
Сообщений: 1458
Регистрация: 5.3.2005
Где: Riga, Latvia

Репутация: 23
Всего: 51

Бесплатно и просто.

Bose
Дата 24.8.2007, 18:41 (ссылка) | (голосов:1) Загрузка .

Профиль
Группа: Участник
Сообщений: 342
Регистрация: 31.1.2007
Где: Санкт-Петербург

Репутация: 3
Всего: 6

ALeXandrK
Дата 24.8.2007, 22:05 (ссылка) | (нет голосов) Загрузка .
Цитата(Bose @ 24.8.2007, 18:41)
Посмотри The Kryvich’s Delphi Localizer

Бесплатно и просто.

А это чудо позволяет пользователям программ локализовать твое приложение
(создать свой INI со своим переводом) или это может только разработчик?

Переформулирую: локализация происходит при загрузке исполняемого файла или во время компиляции?

Как понял, на сайте написано, что все записывается в INI, а значит любой может создать свою локализацию.

Это сообщение отредактировал(а) ALeXandrK — 24.8.2007, 22:06

Профиль
Группа: Участник Клуба
Сообщений: 1458
Регистрация: 5.3.2005
Где: Riga, Latvia

Репутация: 23
Всего: 51

Bose
Дата 25.8.2007, 01:25 (ссылка) | (нет голосов) Загрузка .
Цитата(ALeXandrK @ 24.8.2007, 22:05 )
Как понял, на сайте написано, что все записывается в INI, а значит любой может создать свою локализацию.

Там на сайте есть HowTo в котором приведён весь код необходимый для загрузки:

Код
Application.Initialize;

FreeLocalizer.AutoTranslate := True;
FreeLocalizer.LoadLanguageFile := ‘myapp.english.lng’;

=) Т.е. получается, что локализация произходит при загрузке.

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

Профиль
Группа: Участник
Сообщений: 771
Регистрация: 23.2.2007

Репутация: 3
Всего: 15

я делал так локализацию.

Пробегаюсь по всем формам с помощью Screen, на каждой форме пробегаюсь по Контролам, и записываю все примерно так, в ини файл

Где c — Caption, а H — hint

Каждую форму записываю в файл название которого. .lng
В таком же духе читаю эту информацию.

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

Можно также применить модуль TypInfo, тогда вообще все сделается очень быстро и для любых контролов.

Присоединённый файл ( Кол-во скачиваний: 11 )
LocalLng.pas 12,05 Kb

lukas
Дата 25.8.2007, 09:11 (ссылка) | (нет голосов) Загрузка .

Профиль
Группа: Завсегдатай
Сообщений: 1019
Регистрация: 14.7.2007
Где: Железнодорожный, МО, Россия

Репутация: 3
Всего: 9

sergio_1982, Я покажу свой путь, как я сделал много-языковость ;)))
Первое: Я умел немного работать с XML-Data Binding`ом и поэтому пришел к выводу, что файлы настроек языка будут построены на XML
Второе: Я понял, что может быть и не быть, файла с языком, поэтому я сделал все не обходимое в дизайн-тайме и ран-тайме, т.е задал язык по умолчанию — выбрал англ. — т.к. пусть с горем-пополам но юзер разберется
Третье: Я понял что юзер может быть и не русским и англичанином, потому я сделал на юникоде )

Пришел к выводу, что все будет выглядеть так:
1. Прога ищет в папке запуска другую папку «language» и названия всех файлов с расширением lng выводит в окно настроек языка
2. в общем файле настроек задан файл языка к примеру «english» при заданном языке прога ищет в папке языков, если не нашла, то язык по дефолту
3. файл языка подчиняется стандарту к примеру:

EvilsInterrupt
Дата 25.8.2007, 12:34 (ссылка) | (нет голосов) Загрузка .
Код

Exit=»Exit»
/>

4. Дальше File->New->XML и жму XML Data Binding — формируется инклуд позваляющий очень просто работать с файлом настроек языка

ну а дальше дело техники ;)

Профиль
Группа: Участник
Сообщений: 628
Регистрация: 15.2.2006
Где: Москва

Репутация: 6
Всего: 6

ZBugz
Дата 26.8.2007, 13:46 (ссылка) | (нет голосов) Загрузка .

Профиль
Группа: Комодератор
Сообщений: 3815
Регистрация: 2.10.2006
Где: Moscow

Репутация: 62
Всего: 128

MetalFan
Дата 26.8.2007, 15:41 (ссылка) | (нет голосов) Загрузка .
Цитата(lukas @ 25.8.2007, 09:11 )
Пробегаюсь по всем формам с помощью Screen

Профиль
Группа: Участник Клуба
Сообщений: 1458
Регистрация: 5.3.2005
Где: Riga, Latvia

Репутация: 23
Всего: 51

ZBugz, в DKLang все константы приходится заключать в функцию-обёртку?

А как там дело обстоит с resourcestring? Обращения к ним тоже нужно «оборачивать»?

The Kryvich’s Delphi Localizer, насколько я понял сам выдаёт нужную «resourcestring» в зависимости от выбранного языка. Кстати, интересно, как у них это реализовано

Bose
Дата 26.8.2007, 17:39 (ссылка) | (нет голосов) Загрузка .

Профиль
Группа: Участник
Сообщений: 771
Регистрация: 23.2.2007

Репутация: 3
Всего: 15

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

lukas
Дата 26.8.2007, 21:50 (ссылка) | (нет голосов) Загрузка .

Профиль
Группа: Участник
Сообщений: 628
Регистрация: 15.2.2006
Где: Москва

Репутация: 6
Всего: 6

ZBugz
Дата 27.8.2007, 08:03 (ссылка) | (нет голосов) Загрузка .
Цитата(Bose @ 26.8.2007, 17:39)
ZBugz, в DKLang все константы приходится заключать в функцию-обёртку?

А как там дело обстоит с resourcestring? Обращения к ним тоже нужно «оборачивать»?

The Kryvich’s Delphi Localizer, насколько я понял сам выдаёт нужную «resourcestring» в зависимости от выбранного языка. Кстати, интересно, как у них это реализовано

Профиль
Группа: Участник
Сообщений: 209
Регистрация: 9.5.2006
Где: Ташкент

Репутация: 3
Всего: 3

Lence
Дата 28.8.2007, 00:21 (ссылка) | (нет голосов) Загрузка .
Код
procedure LoadingLang (AAppPath: String; ALogoLang, AMainLang, AContactLang : boolean) ;

а внутри проверял — если тру значит каждому компоненту на такойто форме присваивал значению caption стринг из ини .
примерно так

Код
if ALogoLang then
begin
with frmLogo do
begin
lbLogin.Caption := IniFiles.ReadString(cLogoForm,’1′,»);
lbPass.Caption := IniFiles.ReadString(cLogoForm,’2′,»);
actLogin.Caption := IniFiles.ReadString(cLogoForm,’3′,»);
actClose.Caption := IniFiles.ReadString(cLogoForm,’4′,»);
.
Код
const
cLogoForm = ‘LogoForm’;
.

Профиль
Группа: Участник
Сообщений: 628
Регистрация: 15.2.2006
Где: Москва

Репутация: 6
Всего: 6

ZBugz
Дата 28.8.2007, 07:44 (ссылка) | (нет голосов) Загрузка .
Цитата(Lence @ 28.8.2007, 00:21)
Если выбор языка зависит от языка ОС, то лучший вариант через resourcestring. Очень удобно когда много мессаг с одним текстом выпрыгивают. Один раз вбил и юзаешь его на протяжении все простыни проекта.

Профиль
Группа: Участник
Сообщений: 425
Регистрация: 16.1.2005
Где: Киев

Репутация: 9
Всего: 16

А почему про Integrated Translation Environment никто не вспоминает? Самый лучший способ, потому что не трубует никаких добавлений в код.

Еще есть трансляция GnuGetText для Delphi.

s-mike
Дата 31.8.2007, 09:29 (ссылка) | (нет голосов) Загрузка .

Профиль
Группа: Участник
Сообщений: 771
Регистрация: 23.2.2007

Репутация: 3
Всего: 15

lukas
Дата 31.8.2007, 18:15 (ссылка) | (нет голосов) Загрузка .
Google
Дата 12.11.2020, 20:35 (ссылка)

1. Публиковать ссылки на вскрытые компоненты

2. Обсуждать взлом компонентов и делиться вскрытыми компонентами

  • Литературу по Дельфи обсуждаем здесь
  • Действия модераторов можно обсудить здесь
  • С просьбами о написании курсовой, реферата и т.п. обращаться сюда
  • Вопросы по реализации алгоритмов рассматриваются здесь
  • 90% ответов на свои вопросы можно найти в DRKB (Delphi Russian Knowledge Base) — крупнейшем в рунете сборнике материалов по Дельфи

Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, Snowy, MetalFan, bems, Poseidon, Rrader.

многоязычный интерфейс

для таких вопросов

Правила форума «Delphi: Общие вопросы»

Цитата (namra @ 17.11.2008, 21:16 )
как мне его записать в отдельный unit
Цитата (namra @ 17.11.2008, 21:16 )
подключать к каждой форме через uses

есть раздел Delphi для новичков

Добавлено позднее:
:biggrin О и ещё, заметил вот что. Название темы

Цитата
многоязычный интерфейс

ну никак не относиться к твое1 проблеме

Добавлено позднее:
namra, в IDE же есть команда: File->New, выбери там новый unit и вставишь свой код в него.

А в остальных модулях проекта просто в uses добавишь имя нового модуля.

Создал Unit запихал код выдал: Очень нужно может кто опишет где это описать и что исправить

замени текст на такой:

При вызове передавай в процедуру ещё и экземпляр формы. Например

А разве в самой IDE нет возможности реализовать многоязычный интерфейс, я когда-то читал, что можно, только не занимался этим.

Добавлено позднее:
namra, смотри, помоему тебе неплохой пример, тоже перевод с использованием текстовых файлов:
http://www.codenet.ru/progr/delphi/stat/multilang.php

ecspertiza, я не понял, как с ним работать, :wacko

Добавлено позднее:
честно говоря я и не шибко вдавался в изучение сей программы

Там всё просто, включаешь прогу, зате File->new, выбираешь *.exe своей программы, она подгружает всё что может перевести, затем идёт процесс перевода(руками правда) на требуемый язык, затем Save and Compile (в папку с проектом), в программе подключаем модуль LcUnit.pas(идёт вместе с программой), потом в программе пишем

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

зрите в аттаче, сама прога, небольшой HELP, Demka и модуль :biggrin

ecspertiza, а она умеет дополнять существующий перевод?

И исходники закрыты.

На самом деле решений для перевода полным полно. Вот только многие из них не умеют переводить все как надо. Некоторые не умеют переводить ресурсы, другие не умеют переводить свойства нестандартных компонент. Третьи уvt.n переводить всё, но для переключения языка приходится перезапускать программу.
И чем их все рассматривать, проще написать своё, или модифицировать готовое опен-сорсное. Хотя бы тот же JvTranslator. Хотя JvTranslator насколько я помню тоже не умеет переводить resourcestrings.

Многоязычный интерфейс приложений в delphi

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

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

Для поддержки нескольких языков предлагается следующий простой подход. Интерфейс оформляется на родном языке — русском. Для всех остальных языков составляется словарь в виде:

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

Далее, нам необходимо для каждого текстового свойства любого компонента приложения поискать перевод в нашем словаре. Здесь не обойтись без Delphi RTTI. Через Component.ClassInfo получим ссылку на информацию типа, а затем GetTypeData(TypeInf) даст нам указатель на структуру с его описанием.

Далее проходимся по всем свойствам данного (классового) типа:

Отдельный случай — списки TStrings и коллекции типа TTReeNodes и TListItems. Их придется обработать персонально.

Объединяя все написанное, получим компонент для перевода строковых ресурсов.

Многоязычный интерфейс приложений в delphi

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

Иностранные пользователи замучили Вас просьбами перевести ваше приложение на английский язык? Как же осуществить такой перевод? В Дельфи есть собственная система локализации приложений — Integrated Translation Environment (ITE), создающая отдельные файлы переводов в виде динамически подключаемых библиотек (DLL), неявно вызываемых из основного файла программы и имеющих расширение, идентифицирующее язык перевода (т.е. не DLL а, например, ENG). После локализации приложение будет определять язык интерфейса операционной системы, и пытаться найти соответствующий языковый файл (библиотеку) в своей папке. Если не найдёт — запустится с языком, определённым по умолчанию. Если язык по умолчанию находится в отсутствующем файле, приложение запустится с базовым языком, вписанным в ресурсы самого приложения.

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

Итак, для осуществления перевода средствами Дельфи, выполним следующие шаги:

1. Вначале просмотрим код всех форм и модулей на предмет оформления строк. Все строки, подлежащие переводу, следует оформить в виде строковых переменных, записав их как строковые ресурсы (resourcestring). Например, процедуру: следует заменить на:

Теперь, при компиляции программы, эти строки будут выносится в ресурсы программы, вместо того, чтобы быть обычными переменными в теле её кода. Имя строки, предназначенной для ресурса, обычно начинают с букв «rs». Блоки resourcestring можно располагать в тех же местах, что и блоки переменных (var) и констант (const).

2. Откроем Project > Languages > Add. Запускается мастер добавления языка. На первом шаге он просит выбрать проекты, для которых нужно добавить язык. Обычно это только один проект, если только у вас в менеджере проектов не организована группа проектов. Для проекта указывается базовый язык. На втором шаге мастер просит выбрать языки, для которых требуется создать переводы. На третьем шаге можно изменить местоположение папки проектов каждого из выбранных языков. По умолчанию папки языковых проектов располагаются в папке основного проекта. На четвёртом шаге задаётся режим обновления языка, но он уже установлен в положение «Создать новый», и других вариантов нет. На пятом, последнем шаге предлагается проверить и подтвердить введённую на предыдущих шагах информацию.

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

3. Теперь откроем любой созданный языковый файл, и с помощью открывшегося редактора осуществим перевод содержащихся в нём строк. В файлах модулей форм помимо строк также содержатся некоторые другие свойства компонентов. С их помощью можно, например, корректировать размеры компонента, если строка перевода в него не помещается. Редактор переводов содержит также функции просмотра исходной формы и просмотра а также визуального редактирования переведённой формы.

После сохранения и компиляции основного и языкового проектов, в папку основного проекта добавляется файл перевода с расширением, соответствующем новому языку. Его необходимо распространять вместе с самим приложением. Если необходимо размножить один перевод (например, английский США) на все страны, говорящие на этом языке, но различающиеся только последней буквой расширения языкового файла, то следует просто удалить эту последнюю букву из расширения (например, расширение ENG превратить в EN).

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

Умеете ли вы писать приложения для всего мира? Не так давно мой начальник в предвкушении скорого выхода нашей фирмы на международный рынок попросил рассмотреть возможность перевода многомодульного программного комплекса среднего уровня сложности с русского языка на английский с целью использования его в Латинской Америке! Конечно, я не знаю, насколько оправдано это решение с практической точки зрения и сколько языков знает среднестатистический индеец, но передо мной встала серьезная и новая для меня задача.

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

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

Чтобы понять важность этапа проектирования самого решения с точки зрения последующей его адаптации для конкретного региона, можно дословно привести цитату из Википедии (http://ru.wikipedia.org): «Есть важное различие между интернационализацией и локализацией. Интернационализация — это адаптация продукта для потенциального использования практически в любом месте, в то время как локализация — это добавление специальных функций для использования в некотором определенном регионе».

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

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

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

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

Мы рассмотрим только средства для локализации проектов в среде Delphi для Win32. Кстати, стоит заметить, что в этой IDE уже реализован один из способов локализации приложения.

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

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

Возможные сравнительные характеристики сторонних продуктов

При выборе рассматриваемых решений мы руководствовались прежде всего такими критериями, как совместимость с Delphi 2006 (Win32), внятное указание на тип лицензии, наличие в пакете готовых примеров по локализации проектов. Наличие исходных текстов и возможность работы непосредственно с готовыми exe-модулями можно в общем случае считать дополнительными, но не обязательными характеристиками.

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

Программный пакет «ДеЛок» («Дельфийный локализатор» — так расшифровывают название сами разработчики продукта) распространяется свободно, т.е. его можно использовать в любых проектах, включая условно бесплатные (shareware) и коммерческие.

Далее надо включить в проект локализуемого приложения файл LcUnit.pas, который входит в пакет вместе с «локализатором».

Во время создания формы, подлежащей локализации, необходимо вызвать для нее функцию TranslateComponent(). Вызов функции можно поместить в перегруженный конструктор формы (сразу после inherited) или в обработчик события OnCreate. В случае, если формы наследуются от одной базовой формы, можно поставить вызов функции TranslateComponent() только в ней.

В пакет входит файл русской справки и успешно запускаемый под Delphi 2006 демопроект, показывающий возможность переключения «на лету» русского и английского языков для основных элементов управления. Более подробно о работе модуля LcUnit.pas можно узнать из справочного файла или из файла readme_ru.txt.

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

Helicon Translator

На сайте http://www.helicon.co.at/translator/ имеется 30-дневная ознакомительная версия Helicon Translator.

Важная особенность пакета заключается в том, что он позволяет работать как с файлом проекта, так и с бинарными модулями .exe, .bpl и .dll.

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

Недостаток исследуемой версии — отсутствие у нее явных признаков, свидетельствующих о возможности корректной работы с проектами Delphi 2006.

Advanced Localizer

Весьма серьезная фирма — разработчик ПО EMS, славящаяся своими мощными, универсализированными средствами администрирования для различных СУБД, предлагает набор компонентов для локализации под названием EMS Advansed Localizer Component Suite 1.51 (http://sqlmanager.net/products/tools/quicklocalizer).

Продукт поддерживает все версии Delphi с 5-й до Delphi 2006.

Готовые наборы строк, соответствующие одному конкретному языку, хранятся отдельно в виде INI-файла. Однако при всем удобстве решения в процессе работы со встроенными редакторами этих замечательных компонентов в режиме дизайна неоднократно выдавались сообщения с загадочными программными исключениями и дважды «сваливалась» сама среда Delphi. С пакетом поставляется help-файл и три демопроекта, из которых, в частности, можно понять, что данные с языковыми переводами можно держать не только в виде обычного текстового файла, но и в базе данных.

TsiLang

Как сказано в статье, «пользователи смогут переводить ваше приложение без вашего участия и перекомпиляции».


Теперь по поводу поддержки Delphi 2007. В апреле 2007 г., когда писалась эта статья, на сайте разработчиков можно было прочитать следующее (перевод с англ. автора): «Мы много работаем над завершением версии 6.1 и ее инсталлятора, которые будут поддерживаться в Delphi 2007. В данный момент на нашем сайте доступна новейшая версия, уже поддерживаемая в Delphi 2007. Для ее применения необходимо во время инсталляции использовать опции Turbo Delphi и вручную установить TsiLang в IDE».

Фрагмент внутреннего представления компонента класса siLang из демопроекта RicheditDemo представлен в листинге 2.

Когда в бассейне нет воды, или Про бойцов из стройбата

Задача немного усложняется, если у вас нет ни исходных текстов, ни магического map-файла программы, но вам во что бы то ни стало надо заменить какие-то строковые ресурсы графического интерфейса программы. Как раз в таких случаях можно попробовать воспользоваться поистине замечательной программой Restorator.

Особенности применения интерфейсов в Delphi

Интерфейсы в Delphi появились не сразу, а когда появилась необходимость поддержать работу с COM и на мой взгляд они не очень стройно вписались в язык.

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

Фактически, интерфейсы полезны в двух случаях:

  1. Когда необходимо использовать множественное наследование;
  2. Когда ARC (автоматический подсчет ссылок) серьезно облегчает управление памятью.

В Delphi исторически нет и не было множественного наследования в той форме, как это принято в некоторых других языках программирования (например, С++). И это хорошо.

В Delphi проблемы множественного наследования решаются интерфейсами. Интерфейс — это полностью абстрактный класс, все методы которого виртуальны и абстрактны. (GunSmoker)

И это практически так, но не совсем так! Интерфейсы очень похожи на абстрактные классы. Очень похожи, но в конечном итоге классы и интерфейсы ведут себя очень по-разному.

В связи с грядущими изменениями, то есть по мере появления ARC в новом компиляторе, тема управления жизнью Delphi-объектов получает новую актуальность, так как прогнозируемо будут новые «священные войны». Мне бы не хотелось именно сейчас резко вставать на ту или иную сторону, хочется лишь поисследовать существующие области пересечения «классического» подхода и «ссылочных» механизмов управления жизнью объекта как программисту-практику.

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

Часто программисты «интерфейсных морд» к БД игнорируют вопросы управления памятью объектов, что не умаляет важность темы. По моему мнению, смешивать в работе классы и интерфейсы следует крайне осторожно. Всему виной счетчик ссылок. Для понимания этого давайте проделаем простое упражнение.

В качестве примера – форма с одной кнопкой. Сугубо тестовый пример. Не повторяйте это дома.

Запускаем, нажимаем кнопку и в Memo1 появляется следующий текст:

Destroy вызывается два раза и как результат – «Invalid pointer operation». Почему?

Один раз – это понятно. В обработчике Button1Click вызывается MyClass.Free. А второй раз откуда? Суть проблемы кроется в процедуре Kill. Разберем ход ее выполнения.

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

Кто виноват и что делать?

Думаю, никто не виноват. Не нужно так делать. Врядли в языке без сборщика мусора можно было бы реализовать интерфейсы с управляемым временем жизни более удобно. Разве что принудить программиста явно вызывать _AddRef и _Release. Сомневаюсь, что это было бы удобнее.

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

Следует понимать, что счетчик ссылок принадлежит не интерфейсам, а объекту. Интерфейсы этим счетчиком лишь управляют. Если в Delphi будет два типа интерфейсов, то как в такой ситуации вести себя объекту, который реализует два интерфейса разных типов? Здесь большой простор для поиска потенциальных подводных камней.

От счетчика ссылок объекта можно избавиться самостоятельно переопределив методы _AddRef и _Release таким образом, чтобы обнуление счетчика ссылок не вызывало освобождение объекта. Например, изменив класс из примера таким образом (чтобы класс мог наследовать интерфейс он должен реализовать три метода: _AddRef, _Release и QueryInterface):

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

Тем не менее, в VCL переопределение счетчика ссылок используется. У наследников TComponent счетчик ссылок работает весьма замысловато.

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

Теперь результат будет таким, то есть абсолютно ожидаемым:

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

И если раньше при работе с VCL многие могли вообще никогда не сталкиваться по-настоящему с необходимостью использовать интерфейсы, то в свете новой библиотеки FireMonkey, дающей вроде-как кроссплатформенность, нужно очень внимательно следить за использованием интерфейсов внутри неё самой, не полагаясь на «идеологическую стройность» языковых возможностей, предлагаемых Embarcadero.

23 решения для локализации и интернационализации приложений.

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

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

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

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

Содержание

TSILang components suite

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

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

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

Мой тест.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это приведет к тому, что TsiLang подгрузит из sil-файла строки на необходимом языке.
Что касается работы со словарем переводов, то TsiLang может передавать в словарь (предварительно созданные) только уже переведенные строки. Для этого можно воспользоваться все тем же редактором переводов — жмем в редакторе кнопку «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. Небольшие проблемы с окнами TsiLang. Они, конечно, жить не мешают, но тем не менее, не хорошо, когда ты вызываешь словарь, а он какого-то лешего сворачивается в панели управления.

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

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. С этой вкладки бросам на форму компоненты:

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

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

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

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

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

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

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

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

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

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

  1. Загрузка переводов из базы данных
  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’а:

Также, сразу же после информационного сообщения о том, что мой проект локализован запустился 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»:

Мелочь, конечно, но не приятная. Далее мне необходимо было проверить то, как Korzh Localizer умеет вытаскивать из исходников жестко закодированные строки. Для этого в главном меню была выбрана опция:

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

Kryvich’s Delphi Localizer

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

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

  1. Очень простая в использовании библиотека
  2. Компактная
  1. Нет словарей
  2. Сканер не определяет жестко закодированные строки и константы

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

JVCL (JEDI Visual Component Library)

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

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. Пишем в любом удобном месте программы одну строку:

Программирование Delphi

Все о программировании.

Главное меню

Локализация приложений Delphi, используя StringTable

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

Ресурсы StringTable

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

  1. Символьные строки, содержащиеся в StringTable не занимают память, пока они не будут определенно загружены приложением.
  2. При использовании ресурсов StringTable при создании многоязычных приложений, добавления нового языка является хорошим тоном, так как StringTable могут быть легко отредактированы. Более того, если StringTable хранится в ресурсном DLL, Вам даже не нужно будет повторно компилировать приложение.

Как и любой другой тип ресурсов, ресурсы StringTable компилируются в .RES файл, который прилагается к EXE файлу Вашего приложения во время компиляции.

Создание StringTable ресурсов

Для создания ресурса StringTable приложения для двух языков:

1. Создайте текстовый .RC файл, который содержит Ваши строковые ресурсы в директории Вашего проекта. Назовите файл StringTableLanguage.rc. Вообще-то Вы можете назвать его по-любому, главное, чтобы расширение файла было .RC

2. Компилируйте этот RC файл в RES файл при помощи компилятора ресурсов BRCC32.

Обратите внимание: Файл StringTableLanguage.rc может содержать любое дополнительное количество ресурсов другого типа (иконки, изображения, данные и т.д.)

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

Использование таблиц строк

Чтобы загрузить определенную строку из StringTable нужно использовать функцию LoadString. Один из параметров в вызове LoadString — индекс строки в таблице строк.

Связывание в приложении

Как и любой .RES файл, Вы можете связать файл ресурсов с Вашим приложением просто добавив следующую инструкцию в код Вашего приложения (после implementation).

Как только файл ресурсов будет связан с Вашей программой, Вы сможете загружать ресурс из любого модуля, даже если Вы определили директиву $R в другум модуле.

LoadString

Вот пример, как использовать функцию LoadString для загрузки строки из StringTable:

Многоязычный интерфейс приложений в delphi

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

Многоязычные приложения. Создание библиотек ресурсов

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

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

Точный смысл термина локализация (locale) вовсе не идентичен понятию «страна». Он складывается из двух частей: настроек на особенности конкретной страны и на используемые в ней языки. Для некоторых стран при локализации Windows используются по два языка или разновидности, например, в Сербии и Норвегии. Также верно и обратное — один язык (в частности, английский, испанский, арабский) применяется во многих странах. При этом национальные особенности (система мер, терминология, способ сортировки, форматы представления денежных единиц и даты/времени) в этих странах отличаются. Поэтому название локализации состоит из трех букв: две обозначают язык и одна — страну. В программах для Windows вы можете встретить разновидности английского: ENLJ (США), ENG (Великобритания) и еще с десяток. Для России (локализация RUS) эта двойственность отсутствует.

Традиционный способ разделить программный код и элементы пользовательского интерфейса — это использование ресурсов. Со средствами разработки от Inprise, начиная еще с Borland Pascal for Windows, поставляются инструменты для работы с ресурсами, такие, как Resource Workshop. В Delphi сама форма, по сути дела, является ресурсом, с которым можно работать прямо в визуальной среде; для специализированных графических ресурсов предназначена утилита Image Editor.

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

В Delphi 5 специально для решения задач локализации появился целый комплекс средств под общим названием Integrated Translation Environment (ITE). Он состоит из трех составных частей: Мастера создания динамических библиотек ресурсов (Resource DLL Wizard), Менеджера переводов (Translation Manager) и Репозитория переводов (Translation Repository). Им, в основном, и посвящена данная глава.

Мастер создания динамических библиотек ресурсов

В Delphi процесс интернационализации легче всего автоматизировать путем создания так называемых динамических библиотек ресурсов. На это есть специальный мастер, вызываемый через пункт New. меню File (рис. 10.1). Можно вызвать его и другим путем — через пункт меню Project\Languages\Add.

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

Первым выводимым Мастером окном будет приветствие и краткое описание возможностей. Далее мастер показывает диалоговое окно, в котором следует выбрать проекты, подлежащие интернационализации (рис. 10.2). Термин базовый язык (Base Language, третий столбец) означает код языка, который будет присвоен основным файлам проекта; по умолчанию базовый язык берется из текущих настроек операционной системы.

Рис. 10.1. Вызов мастера создания библиотек ресурсов

Рис. 10.2. Мастер создания библиотек ресурсов. Диалоговое окно выбора проектов

Рис. 10.3. Выбор языков, на которые будет осуществлен перевод

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

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

Мастер автоматически выносит в библиотеку два вида ресурсов — формы приложения и текстовые строки. При этом он создает следующие файлы:

  • в папке проекта создается файл с именем проекта и расширением drc, который представляет собой совокупность всех используемых строковых ресурсов. Формат этого файла — обычный исходный текстовый формат хранения ресурсов (rc);
  • проект с тем же именем, что и исходный; он будет лежать во вложенной папке с именем, соответствующим выбранной стране локализации. В него входят все файлы, которые обычно встречаются в проектах, плюс специальные файлы ite. Первая разновидность файлов носит название имя формы, dfn, вторая — имя проекта_орс.рс. Это наши «старые знакомые» — два вида ресурсов, дополненных специальными комментариями для работы ite. Хотя они имеют текстовый формат, но редактировать их вручную не следует — методика работы с ними описана ниже, в описании утилиты Translation Manager.
  • файл группы проектов с расширением bpg. Действительно, наш проект дополнился еще одним, и теперь они составляют группу. Единственный недостаток мастера — он предлагает сохранить файл bpg в той же папке, где и созданная локализация. Целесообразнее сделать это в корневом каталоге исходного проекта.

Результатом компиляции станет динамическая библиотека с именем имя проекта имя локализации, в данном случае PROJECT 1 . UKR. Эту библиотеку

нужно поместить и распространять вместе с ЕХЕ-файлом проекта. При запуске приложения, написанного на Delphi 5, библиотека времени выполнения производит попытку настройки. Если на целевом компьютере установлен тот национальный интерфейс, который соответствует расширению динамической библиотеки ресурсов (в данном случае ukr), то все локализованные вами ресурсы будут загружены из нее.

После создания проекта библиотеки (*.dpr) перед глазами открывается такой весьма скупой код, содержащийся в нем:

// Do not edit. This file is machine generated by the Resource DLL Wizard.

($R ‘Unitl.dfm’ Forml:TForm)

Две директивы $r указывают на те ресурсы, ради которых все и «затевалось». Директива $е указывает на расширение файла, которое будет присвоено динамической библиотеке после компиляции.

Для ресурсов-текстовых строк в язык Object Pascal введено новое ключевое слово — resourcestring. Строки-константы, описанные с его помощью, будут собраны вместе в таблицу ресурсов. Если вы хотите упростить проблему локализации вашего приложения, замените везде выражения вида

ShowMessage( ‘ Ошибка открытия файла’ );

resourcestring sOpenError = ‘ Ошибка открытия файла ‘;

Целесообразно собрать все ресурсные строки вашей программы в одном месте; лучше всего для этого выделить отдельный модуль. Так поступили и разработчики VCL — найдите модули consts.pas, dbconsts.pas, BDECONST.PAS, OLECONST.PAS, MIDCONST.PAS, MXCONSTS.РА S , WEBCONST.РА S в прилагаемых к Delphi исходных текстах. Кроме строковых констант, описанных через ключевое слово resourcestring, там ничего нет. Для того чтобы перевести все сообщения среды выполнения Delphi на русский, вам достаточно перевести эти модули с помощью ite и затем включить их национальную версию в состав вашего проекта.

Использование Менеджера переводов

В версии 5 среды Delphi значительно усовершенствованы инструменты для автоматизации подготовки многоязычных версий. После выполнения мастеpa создания динамических библиотек ресурсов управление автоматически передается Менеджеру переводов (рис. 10.4). Специально для его вызова предназначен также пункт Translation manager меню View.

Рис. 10.4. Внешний вид Менеджера переводов (Translation Manager)

Окно Менеджера переводов состоит из двух частей. В левой части приводится список всех проектов на разных языках и сосредоточены административные функции. Для каждого проекта предусмотрены две папки, соответствующие разновидностям локализуемых ресурсов: Формы (Forms) и Скрипты ресурсов (Resource scripts).

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

Если в левой части выделен конкретный ресурс, в правой появляется таблица с теми свойствами и значениями, которые подлежат интернационализации. Такая таблица показана на рисунке 10.4.

В эту таблицу Менеджера переводов попадают не все свойства визуальных компонентов, а только те, которые собственно и поддаются локализации. Что это за свойства? Их легко увидеть в Инспекторе объектов, если переключить его в режим отображения свойств по категориям. Нужные нам свойства находятся в категории LocalizabIe (рис. 10.5).

На рисунке видно, что помимо шрифта и надписей, в состав свойств, меняющихся в зависимости от языка, входят также размеры, значки, файл справки и т. п. У многих компонентов в’Delphi 5 есть свойства RiniModp и ParentBiDiMode, описывающие начертание текста. Они позволяют располагать его справа налево, как это принято в ряде ближневосточных языков.

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

При разработке пользовательского интерфейса имейте в виду, что длина надписей (в буквах) на национальных языках может сильно отличаться от их длины на английском, вплоть до двукратного удлинения. Учтите это при расположении компонентов типа TLabel, TEdit и т. п. Где возможно, позвольте компонентам автоматически масштабироваться.

Рис. 10.5. Локализуемые свойства компонента TForm

Серым цветом в таблице Менеджера переводов отображаются нередактируемые столбцы, белым — редактируемые. Если вы хотите управлять составом и сортировкой столбцов, в меню Actions можно настроить параметры их отображения. Назначение столбцов таково.

В столбце ID указывается идентификатор ресурса. Для строковых констант в этой колонке отображается имя константы. Например, если вы увидели идентификатор sysConst_szeroDivide, то в файле с расширением drc можно найти соответствующую этой константе строку «Floating point division by zero». Это имя образуется из имени модуля, где описана константа, и имени самой константы, разделенных символом подчеркивания. Для компонентов на формах ID образуется по другому правилу. Если вы видите > начинающийся с о — это свойство объекта (см. рис. 10.4). Буква i будет означать, что объект унаследован с другой формы, a l — с кадра (Frame). Таким образом, идентификатор o:Formi.Font.Name соответствует имени шрифта формы Formi.

Следующая колонка показывает значения всех свойств для базового языка проекта. В проекте RichEdit этот язык — английский, а если вы создаете новый проект в русскоязычной версии Windows, то этот язык будет русским. Новые (переведенные на тот или иной язык) значения содержатся в столбце с именем этого языка.

Столбец Status показывает состояние свойства; значение Translated означает, что перевод осуществлен. У него есть три возможных значения: Translated, Untranslated и Auto Translated. Любое изменение свойства устанавливает этот флаг в Translated. Если вы не хотите реально изменять строку, можно просто переустановить свойство щелчком в данной колонке. Значение Auto Translated устанавливается, если перевод осуществлен при помощи Репозитория переводов (см. следующий раздел).

Столбцы Created и Modifie d создаются и автоматически поддерживаются системой. Наконец, если вы хотите прокомментировать значение свойства, в вашем распоряжении столбец Comment.

В таблице Менеджера переводов достаточно удобно редактировать текстовые строки, тем более что для этого есть специальный двухоконный редактор (он вызывается из панели инструментов Менеджера переводов, рис. 10.6). Но вот другие виды свойств — перечислимые (как например Font.charset), числовые — редактировать не очень удобно. А свойство icon (значки) редактировать практически невозможно — значок представлен в двоичном виде. В этом случае редактировать формы нужно при помощи стандартных возможностей среды Delphi и Инспектора объектов, а затем сохранить изменения и вернуться в Менеджер переводов. При этом свойство получит флаг Translated.

Рис. 10.6. Такой редактор встроен в Менеджер переводов

Что делать, если вы отлаживаете ресурсы сразу для нескольких стран, а требуемая локализация не установлена у вас на компьютере? В пятой версии Delphi упрощен процесс переключения между языками при отладке. Теперь для этого предусмотрен пункт главного меню Delphi Project\ Languages\SetActive. Если все библиотеки DLL скомпилированы, то простым переключением в этом пункте меню вы можете просмотреть работу каждой из них. Если выбрано значение none, то приложение запускается с тем видом ресурсов, который соответствует текущим настройкам Windows. Разработчиками Inprise предусмотрен и другой выход из этой ситуации. Вы должны внести в ключ системного реестра hkey_current_user\

Software\Borland\Locales элемент данных вида «имя_приложения»=»имя_локализации». Например, если вы хотите испытать интерфейс описываемого приложения на украинском языке, элемент данных должен выглядеть так:

[HKEY_CURRENT_USER\Software\Borland\Locales] «d:\\Program Files\\Borland\\Delphi5\\Project5

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

Можно переключать национальные интерфейсы и «на ходу», во время работы приложения. Пример этого приведен в приложении RICHEDIT, поставляемом среди примеров с Delphi (папка d emo s\richedit). В нем при помощи меню вы можете выбрать один из трех языков, и тут же подгрузится необходимая динамическая библиотека ресурсов. Если вы всерьез занимаетесь проблемами интернационализации, советуем обратить на этот пример самое пристальное внимание. Функции, которые осуществляют это (модуль reinit.pas). можно без изменений позаимствовать и внести в свой проект.

Использование Репозитория переводов

Для централизованного хранения переведенных на другие языки ресурсов в Delphi 5 есть специальное средство — Репозиторий переводов (Translation Repository, рис. 10.7). Эта утилита позволяет собирать переведенные строковые ресурсы из проектов и в дальнейшем использовать их во вновь создаваемых проектах.

Репозиторий создает специальный файл с расширением drs, который хранится в папке исполняемых файлов Delphi (Delphi \Bin). Вы можете создавать и редактировать свои собственные DRS-файлы, использовать и распространять их, а также пользоваться файлами, созданными другими разработчиками.

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

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

ется в ваш проект, напротив этой строки в Менеджере переводов в поле Status поднимается флажок AutoTranslated.

Рис. 10.7. Внешний вид Репозитория переводов

Вы можете один раз перевести константы из часто используемых файлов констант (consts.pas, sysconst.раз, DBCONSTs.раз и др.) или найти уже готовые файлы переводов в Интернете.

Строки в Репозиторий попадают из проекта так: в Менеджере переводов вы выделяете одну или несколько строк (со строковыми ресурсами!), нажимаете правую кнопку мыши и во всплывающем меню выбираете пункт «Repository\Add strings to Repository». В ряде случаев пункт Repository недоступен. Это может быть по двум причинам: среди выбранных вами ресурсов есть не только строки, и в случае совпадения исходного и целевого языков. Если вы хотите иметь англоязычную и русскую версии вашего приложения, нужно в Мастере создания библиотек ресурсов выбрать в качестве базового языка английский, а потом добавить к нему русскую DLL. В противном случае при работе в русской версии Windows строки на английском будут трактоваться как русские.

В проекте Richedit есть строки из модулей SysConst, Consts, ComStrs, уже переведенные на французский и немецкий. Если загрузить их в Репозиторий переводов, то это может послужить первым вкладом в вашу коллекцию ресурсов.

Импорт и экспорт данных предусмотрен в формате xml. Этот быстро набирающий популярность формат имеет хорошую перспективу стать стандартом де-факто для обмена данными.

Информация о версии вашего продукта

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

Вставить в ваш проект информацию о версии поможет сама Delphi. Вызвав пункт Options меню Project, на странице Version Info вы увидите структуру, которая и будет ее содержать (рис. 10.8). Для того чтобы в ваш проект попала эта структура, нужно поднять флажок Include version information in project.

Рис. 10.8. На странице Version Info вы можете задать информацию о текущей версии продукта

Что это за структура? Информация о версии помещается в особый вид ресурсов и компилируется в исполняемый файл или динамическую библиотеку проекта. Если вы запустите любой редактор ресурсов и загрузите в него какое-то приложение, помимо ресурсов Bitmap, Icon, Cursor, вы можете увидеть и тип Version. Такой тип ресурсов представляет из себя структуру двоичных данных, состоящую из поля фиксированной длины (fixeddfileinfo), поля данных локализации (translation) и набора строк переменной длины. То, что вы видите на рисунке, соответствует полям этой структуры.

Но что необходимо указать в этих полях? Чем FileVersion отличается от ProductVersion? Некоторые поля структуры являются обязательными, некоторые — нет. Обязательные поля приведены в табл. 10.1.

Таблица 10.1. Обязательные поля для информации о версии

Delphi 2005 становится многоязычной

Выпустив в 1983 г. первую версию языка и среды программирования Turbo Pascal, компания Borland Software (www.borland.com) открыла новую страницу в истории развития средств разработки приложений. Через 12 лет, в 1995-м, увидела свет и первая версия Delphi (оказавшаяся в то же время последним 16-разрядным компилятором), в которой была реализована основанная на компонентах методология быстрой разработки приложений (RAD). Однако с появлением среды разработки JBuilder развитие Delphi несколько затормозилось, хотя было выпущено еще семь версий этого мощного инструмента. И вот теперь корпорация Borland объявила о выходе Delphi 2005, связавшего в единой среде поддержку языков Object Pascal для Win32 и .NET и C# для .NET, средства работы с Web и базами данных, а также основанную на моделях разработку приложений и инструменты управления жизненным циклом приложений (ALM).

Интегрированная среда разработки

Delphi 2005 обеспечивает единую интегрированную среду разработки (IDE) для всех типов ПО (например, Win32 на Паскале или .NET на C#), однако при этом автоматически учитываются особенности каждого вида разработки. Так, если создается веб-страница ASP.NET, то прибегают к помощи конструктора HTML (HTML Designer), позволяющего размещать и настраивать веб-компоненты и сразу оценивать полученный результат. Если же проектируется приложение Win32, то применяется конструктор VCL (VCL Designer; VCL — библиотека визуальных компонентов). Естественно, в зависимости от вида проекта используется тот или иной набор инструментов (палитра компонентов, отладчик, средства редактора кода и т. п.).

Некоторые разработчики, имевшие дело с Delphi 8, жаловались на отсутствие традиционного для предыдущих версий «плавающего» конструктора VCL. В новой версии появился выбор: можно использовать либо «плавающий конструктор», либо встроенный конструктор .NET-стиля.

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

В Delphi 2005 усовершенствована палитра компонентов (Component Palette). Если раньше она служила только для выбора и переноса в форму требуемых компонентов, то теперь с ее помощью можно создавать новые проекты, файлы и объекты, а также получать доступ к имеющимся мастерам (Wizards) и использовать стандартные фрагменты кода. Расширены также средства выбора компонентов из палитры: достаточно набрать часть имени объекта, и палитра автоматически откроет список подходящих компонентов. Наконец, теперь реализовано перетаскивание компонентов на форму с помощью технологии drag& drop, ранее же для этого надо было дважды щелкнуть мышью (впрочем, этот способ сохранился и в новой версии).

Расширился набор визуальных компонентов для VCL-приложений. Особенно обогатилась библиотека компонентов для приложений .NET, что облегчает перенос проектов Win32 на новую платформу.

Доработкам подвергся и инспектор объектов (Object Inspector). Помимо своего прямого назначения — редактирования свойств используемых компонентов и назначения обработчиков событий — он теперь позволяет просматривать и изменять характеристики объектов, выбранных в менеджере проектов (Project Manager), например переименовывать файлы, входящие в проект.

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

Среди других дополнений и улучшений можно отметить средства для импорта или экспорта .NET-проектов на языке C# между Delphi 2005 и Visual Studio .NET, полную поддержку кодировки UTF-8 во всех мастерах и компонентах IDE, а также встроенные в оболочку средства передачи в Borland сообщений о возникших ошибках.

Хотя редактор кода (Code Editor) относится к IDE, внесенные в него улучшения и дополнения столь существенны и многочисленны, что целесообразно поговорить о них отдельно.

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

Средства переименования символов, в отличие от обычной операции поиска и замены, учитывают контекст, в котором применяются переименовываемые символы. Такими символами могут быть имена классов и интерфейсов, свойства, методы, процедуры и функции, переменные и константы. Естественно, учитывается область видимости символов; например, локальная переменная будет переименована только в пределах той процедуры, где она определена. Действие переименования символов распространяется также на классы — наследники того класса, символ которого переименовывается, и на файлы ресурсов. Без этого механизма «глобальное» переименование зачастую становилось тяжким трудом, сопряженным с появлением множества ошибок.

Для большего удобства работы в Delphi 2005 введено специальное диалоговое окно для объявления локальной переменной или поля записи. Теперь нет нужды путешествовать туда-сюда по коду каждый раз, когда надо описать новую переменную. Эта возможность поддерживается только для языка Object Pascal.

Еще одним средством «только для Паскаля» является переработка ресурсов (Resource Refactoring), заключающаяся в замене строковых констант, находящихся прямо в исполняемом коде, на блоки строковых ресурсов. Особенно полезен этот механизм при разработке приложений, которые в будущем предполагается локализовать для других стран. В языке C# механизм блоков строковых ресурсов отсутствует.

Средства извлечения методов позволяют, выделив несколько строчек кода Object Pascal, создать на их основе новый метод, а сами строчки заменить вызовом этого метода. Такой механизм весьма интеллектуален: например, он «понимает», какие переменные передавать методу по значению, а какие — по ссылке. Для C# подобного средства пока нет.

Весьма удобен механизм импорта пространства имен для C# или поиска модуля для Object Pascal. Он дает возможность быстро отыскать нужное пространство или модуль для заданного символа и подключить его к проекту.

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

Механизм предупреждения ошибок (Code Insight) основан на непрерывном контроле вводимого в редакторе кода. Ранее подобный контроль применялся только для выделения ключевых слов, имен переменных, констант и т. п., теперь же автоматически осуществляется синтаксический анализ кода и проблемные фрагменты подчеркиваются красной волнистой линией, как это делает Microsoft Word для тех слов, которые ему кажутся неправильными. Наведя курсор мыши на подчеркнутый элемент, можно получить информацию о том, что же именно не понравилось редактору. Кроме того, помимо отображения ошибок в окне редактора кода все проблемы заносятся в окно структур (Structure Pane). Это позволяет программисту быстро переходить от одной ошибки к другой, не прокручивая сам текст программы.

Автоматическая помощь (Help Insight) вызывается, когда курсор мыши задерживается некоторое время на имени какого-либо класса, свойства или метода. Это средство дополняет традиционную систему помощи, однако не заменяет ее полностью, поскольку возможности «автоматики» ограниченны.

Менеджер изменений (History Manager) сохраняет старые версии исходных файлов кода и форм в отдельной папке и позволяет всегда вернуться к предыдущей версии, а также сравнить одну версию с другой, показав внесенные изменения. Он может взаимодействовать также с сервером контроля версий Borland StarTeam, отслеживая изменения, вносимые разными членами команды разработчиков.

Значительно расширились средства навигации по коду. Так, теперь одним нажатием комбинации клавиш можно «перепрыгнуть» от объявления метода к его телу или наоборот. Стали более богатыми и возможности закладок, благодаря чему, например, можно определять постоянные закладки, которые удаляются только явным образом (ранее закладка сохранялась только во время сеанса редактирования).

Появилось средство быстрого «отключения» блока кода путем размещения признака комментария (символов & quot;// «) в начале каждой его строки, а также выполнения обратного процесса.

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

Библиотека визуальных компонентов (VCL) для .NET

VCL для .NET пополнилась помимо новых компонентов и новым механизмом вызова процедур и функций, находящихся в обычных DLL платформы Win32, — интерфейсом виртуальных библиотек (Virtual Library Interface, VLI). Поддерживаемый платформой .NET сервис вызовов PInvoke имел ограниченные возможности и был довольно неудобен в использовании: так, с его помощью нельзя было обратиться к библиотеке, местоположение которой становилось известным только во время выполнения приложения. VLI и снимает подобные ограничения.

В состав Delphi 2005 входят три компилятора. Один из них, лицензированный у корпорации Microsoft (www.microsoft.com), обеспечивает трансляцию приложений, созданных на языке C#, в промежуточный язык (Intermediate Language, IL) платформы .NET. Порождаемый им код полностью совпадает с тем, который генерируется компилятором C#, входящим в состав Microsoft Visual Studio for .NET. Два других компилятора разработаны корпорацией Borland и обеспечивают трансляцию программ на языке Object Pascal в машинный код для исполнения на платформе Win32 или в IL-код для использования на платформе .NET.

По сравнению с предыдущими версиями синтаксис языка Object Pascal был несколько расширен. Например, был введен новый цикл for. in, который обеспечивает последовательный перебор элементов коллекции и по своим функциям аналогичен циклу foreach языка C#.

Новые компиляторы способны транслировать исходные файлы в кодировке UTF-8 или Unicode. Предшествующие версии могли работать только с файлами в кодировке ANSI.

Важнейшим изменением в компиляторе для .NET стала возможность образовывать единое пространство имен для группы модулей или даже группы приложений (в Delphi 8 каждый модуль имел свое собственное пространство имен, что казалось неудобным разработчикам, привыкшим к языку C#).

В компиляторе для Win32 появилась возможность встраивания (inlining) процедур и функций. Когда функция объявлена как встраиваемая, компилятор при обращении к ней не генерирует инструкцию вызова подпрограммы, а размещает в точке вызова сам код функции. Поскольку инструкции вызова и возврата из подпрограмм относятся к одним из самых медленных, подобное средство в определенных случаях помогает существенно поднять производительность приложения.

Еще одним нововведением для платформы Win32 стала поддержка вложенных типов, т. е. определения одного типа внутри определения другого. Кроме того, теперь можно объявлять константы внутри объявлений классов. На платформе .NET эти средства имелись еще в прошлой версии.

На основе исходного кода Win32 сегодня можно генерировать файлы документации в формате XML. Эта возможность также позаимствована у компилятора для платформы .NET.

Наконец, компилятор для Win32 способен генерировать код, оптимизированный для инструкций наборов SSE2 и SSE3, имеющихся в процессорах Pentium 4. При выполнении некоторых специфических задач это средство способно многократно повысить производительность приложения.

Delphi 2005 имеет два отладчика: один для платформы Win32, другой — для платформы .NET. Возможности обоих инструментов достаточно близки и различаются лишь в той части, которая зависит от платформы. Так, отладчик для Win32 позволяет устанавливать точки останова на попытку записи в память по определенному адресу, а отладчик для .NET такой возможности не имеет, поскольку на этой платформе нельзя заранее предсказать, где именно будут храниться данные.

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

Отладчик для .NET «научился» показывать исходный текст программы, сгенерированный IL-код и соответствующий ему машинный код*.

Традиционные точки останова теперь могут в момент срабатывания записывать в протокол состояние стека вызова. Изменилось и само окно управления точками останова: его сделали более удобным.

Из отладчика для .NET в отладчик для Win32 перекочевала возможность просмотра локальных переменных любой процедуры из стека вызова (ранее обеспечивался просмотр переменных только текущей процедуры).

Управление жизненным циклом приложений

Delphi 2005 предоставляет полный доступ из IDE ко всем возможностям Borland StarTeam — системы управления коллективной работой, обеспечивающей контроль версий, управление требованиями, отслеживание ошибок, поддержку дискуссионных групп и удаленную разработку. Когда задействованы средства коллективной работы, менеджер изменений не сохраняет версии исходных файлов самостоятельно, а пользуется репозиторием StarTeam. Естественно, в этом случае отслеживаются изменения, вносимые любым членом команды разработчиков.

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

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

Enterprise Core Objects (ECO)

ECO — это технология управляемой UML-моделями разработки .NET-приложений. Такой подход к разработке часто называют архитектурой, управляемой моделями (Model Driven Architecture, MDA).

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

ECO является технологией быстрой MDA-разработки, поскольку обеспечивает многократное снижение объема кода, который необходимо написать вручную для реализации заранее созданной модели UML.

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

В дополнение к UML в ECO поддерживается язык OCL (Object Constraint Language), позволяющий определить правила вычисления или управления значениями атрибутов объектов. Использование OCL, как и UML, позволяет свести к минимуму ручное программирование рутинных задач. В Delphi 2005 ECO поддерживается для обоих языков программирования — Object Pascal и C#.

Илон Маск рекомендует:  Псевдокласс only-of-type
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL