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

Кроме национальной мультиязычности, существует понятие алгоритмической мультиязычности. Эти понятия нельзя смешивать, т.к. алгоритмическая мультиязычность достигается одновременной поддержкой нескольких алгоритмических языков программирования (C++, JAVA, PASCAL, BASIC...).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

К достоинствам данного метода можно отнести возможность изменения типа языка как при инсталляции, так и при непосредственной эксплуатации ПО.

Help переводится вручную. При инсталляции ПО осуществляется выбор файла с необходимым языком "подсказки".

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

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

Типовые решения проблемы мультиязычности можно найти на следующих сайтах: sunsite.icm.edu/delphi, www.download.com (раздел Localization), www.belcaf.com (раздел Product), www.torry.ru.

Я отрицательно отношусь к применению free-ware (свободно распространяемым версиям ПО) в коммерческих проектах. Существует лишь очень узкий спектр задач, где оно допустимо. В вопросе сопровождения ПО, а именно этим является национальная адаптация ПО, недопустимы никакие промашки. Это - имидж фирмы. Создатель free-ware перед вами ничем не обязан. Он вам ничего не гарантирует. Он ничем не рискует. Все это создает фактор нестабильности. Главное - он не гарантирует развитие и поддержку своего продукта в будущем...

Сергей СОКОЛОВ,
БГУИР,
sokol@belcaf.minsk.by