Продуманная локализация

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

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

"Люди, есть ли у кого-нибудь Windows 98 Second Edition 4.10.222.A с немецкой локализацией, причем именно с тремя двойками? Очень срочно нужно, наша программа у клиента глючит под ней, а у нас именно такой нет. Не дайте погибнуть сайт-лицензии! (дорогостоящая лицензия на большое число пользователей — С.Ж.)"

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

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

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

Конечно, ради перевода интерфейса известных и популярных программ, например WinZip, Teleport Pro, Opera, многие готовы как следует покопаться в ресурсах DLL. Например, в каталоге SoftList опубликовано довольно большое количество "патчей" для перевода интерфейса многих популярных программ на русский язык. Но, заметьте, в основном переводят именно известные программы, которые являются мировыми бестселлерами.

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

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

Замечание 2
Замечание 2

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

Существуют даже специальные ActiveX- и VCL-компоненты, предназначенные для реализации многоязычного интерфейса программы. Но, я думаю, что пользоваться ими особого смысла нет. Включение таких компонентов в проект лишь неоправданно увеличит его размер, ведь с технической точки зрения реализация интерфейса на разных языках — достаточно тривиальная задача. Стандартные функции, имеющиеся в современных системах программирования, а также их "основа" -- функции API Windows замечательно справляются с чтением секций и ключей INI-файлов, не доставляя разработчику никаких хлопот.

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

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

Содержание раздела