СОЗДАНИЕ МНОГОЯЗЫЧНЫХ ПРИЛОЖЕНИЙ
(С) Гаузер Э.Г., Баку, 2005г.
website: www.erichware.com
К сожалению, большинство программ снабжены англоязычным интерфейсом. Это связано с почти безграничной экспансией английского языка во все страны и на всех уровнях. Однако, далеко не все население может и хочет пользоваться англоязычными продуктами. И касается это отнюдь не только стран СНГ.
Когда разработчик создает программу, он, естественно, пишет ее интерфейс на своем родном языке. Но если он хочет, чтобы его программа была популярна в разных странах, ему нужно снабдить ее интерфейсом на соответствующих языках.
Программисты из России (и стран СНГ) решают эту проблему обычно просто: создают англоязычную программу (в расчете на то, что свои, родные пользователи - и так обойдутся, все равно не платят ведь). Но, во-первых, хотелось бы все же иметь русский интерфейс, а во-вторых, далеко не весь мир так уж любит английский. Программа в идеале должна разговаривать с человеком на его родном языке. Любом! Но как это сделать с минимальными усилиями?
Речь пойдет именно о создании многоязычного приложения, а не переводе уже созданного кем-то, это отдельный вопрос.
* * *
Итак, программист начал новую программу и заранее хочет сделать ее многоязычной. Какие есть варианты?
1) Можно сделать версию на своем родном языке, забив все сообщения и названия нужным текстом. Потом, после отладки и прочих дел, надо всего лишь заменить все надписи на иноязычные и создать очередной локализованный дистрибутив.
Ясно, что этот метод совершенно неэффективен, чреват большим количеством ошибок и неудобен для распространителя.
2) Многие решают вопрос на уровне ресурсов, компилируя для каждого языка свой вариант, заменяя файл ресурса. В этом файле разработчик хранит все сообщения, названия и прочие языковые элементы, обращаясь к ним из программы просто по номеру.
Такой вариант гораздо удобнее самому разработчику, поскольку фактически гарантирует его от ошибок (в смысле что забыл поменять какое-то сообщение, в варианте 1 это неизбежно).
Однако, для распространителя это все равно сложно, ведь надо иметь экземпляры дистрибутива на всех языках. Для потребителя тоже неприятно, вдруг он захочет поменять язык? Зачем? Ну, всякое бывает, допустим, выучил новый и хочет проверить, насколько. Или гость к нему пришел иноязычный. Или... Ну, просто бзик у него такой. Но он - пользователь и его желания надо исполнять (конечно, не любые бредовые, в рамках разумного). Да и самому разработчику каждый раз заново компилировать и собирать всю программу, создавать дистрибутив - возня!
3) И вот тогда остается последний способ: создание разноязычных файлов сообщений. Способ этот, мне кажется, самый простой и удобный и я не понимаю, почему до сих пор все разработчики не перешли на него. Тем более, что сама идея отнюдь не нова (файлы сообщений были хотя бы у всем известного Нортона).
В чем суть? На стадии написания программы создается текстовый файл со всеми языковыми конструкциями (сообщениями, названиями кнопок и т.д.), аналогично файлу ресурсов (см. п.2). Однако файл этот не имеет никакого отношения к компиляции проекта. Разработчик пишет функцию, которая по заданным имени этого файла (это важно) и номеру сообщения возвращает саму строку. И везде, где в тексте должны быть строки, подставляет вызовы этой функции с соответствующими параметрами.
В чем плюсы данной методики?
1) Не нужно создавать разноязычные дистрибутивы и вообще многократно компилировать программу.
2) Переключение на другой язык может производиться самим пользователем прямо в сеансе работы с приложением. Даже не надо его перезапускать! Ведь имя файла сообщений - глобальная переменная и как только она изменяется в модуле настройки, все последующие вызовы упомянутой функции будут обращаться к новому файлу на нужном языке.
3) Если файл сообщений переведен на другой язык, можно просто разослать новый вариант всем пользователям (или выставить на сайте, или еще как - это детали), при очередном запуске программа просто найдет все файлы сообщений и в блоке настройки выдаст список доступных языков, включая и новоприбывший.
* * *
Разумеется, файлы сообщений должны иметь какое-то фиксированное и известное программе расширение.
Теперь вопрос, почему надо писать специальную функцию? Ведь можно просто при старте загрузить в многомерный строковый массив данные из всех найденных файлов - и все!
Дело в том, что файл сообщений не получится сделать просто текстовым. И причин тут много. Поскольку я давно уже пользуюсь этим методом при создании серьезных программ (на сайте их нет, это программы по моей работе или коммерческие; впрочем, последние на сайте в будущем появятся), напишу об этом подробнее. Кстати, этот же принцип мной использовался еще при создании программ под ДОС.
1) Файл должен хранить информацию о языке, которая будет выводиться в меню для пользователя.
2) файл может быть закодирован, чтобы предотвратить несанкционированные автором переводы (созданный пиратом файл программа не воспримет).
3) В процессе написания программы часто приходится удалять сообщения или добавлять новые. Чтобы не менять во всей программе в вызовах функции порядковые номера сообщений, надо использовать не этот порядковый номер, а свой номер, проще говоря, метку сообщения. И эту метку тоже надо хранить в файле.
4) Несмотря на то, что ресурсы современных компьютеров почти безграничны, хранение в памяти сотен сообщений на десятках языков может оказаться весьма накладным. И уж точно будет очень некрасивым... Кстати, далеко не у всех пользователей компьютеры современные.
5) Файл может хранить и другую служебную информацию о языковой среде (см. далее).
* * *
Впрочем, создание такого бинарного файла сообщений не будет проблемой для программиста: что стоит один раз написать программу перевода из текстового файла в такой формат?
В итоге получается такая технология: вместе со средой разработки перед вами висит "Блокнот" с текстовой версией файла сообщений на вашем родном языке. Перед тем, как в очередной раз запустить создаваемую программу, надо сохранить этот файл и запустить программу преобразования. После чего все изменения в сообщениях будут учтены. Если вы потом что-то меняете в сообщениях, значит снова пускаете кодировщик, если нет, то и не надо.
Потом, когда программа написана, вы включаете в дистрибутив бинарный вариант файла сообщений, а если впоследствие появится перевод на другой язык - пускаете кодировщик - и все, можете отправлять всем пользователям новую локализацию.
Хочу заметить, что ситуация с файлами помощи аналогичная. С той разницей, что не надо писать свою функцию, Windows все сама покажет. А принцип остается. Кстати, в файле сообщений можно хранить и имя файла с текстом помощи на нужном языке, да и любую другую подобную информацию о локализации (о чем и говорилось выше в п.5).
* * *
В результате процесс создания многоязычного приложения будет не труднее создания одноязычного, во-всяком случае, на уровне работы программиста. А вот сам вопрос перевода на другие языки... Но это, как говорится, совсем другая история.