Интернационализация в МФЦ

Question

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

Первая задача - разработать интеграцию в мое приложение C ++ / MFC, содержащее десятки диалогов и бесчисленное множество строк. Я столкнулся с двумя возможными альтернативными реализациями:

1. Компиляция и развертывание локализованных файлов ресурсов в виде библиотек DLL
2. Извлеките и замените все строки локализованной версией. Для каждого язык будет XML (или простой текстовый) файл.

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

Любой совет с благодарностью.

С уважением,
Космин Унгуру
http://www.batchphoto.com/

Answer 1

Я сделал несколько долгоживущих проектов MFC на разных языках. Я настоятельно рекомендую первый подход с DLL-библиотеками только для ресурсов.

Причины:

(1) Если пользователь устанавливает XCOPY, у него всегда есть язык по умолчанию (английский) в основных исполняемых файлах.

(2) Если вы не переводите все (например, опоздали с выпуском или забыли некоторые строки), функции ресурсов Windows при правильном использовании возвращают ресурс на языке по умолчанию автоматически - вам не нужно реализовать это самостоятельно.

(3) Мое личное мнение: (a) Разрывы строк, табуляции, пробелы в XML-файлах - боль в вашем а **. (б) Слияние файлов XML еще хуже ...

(4) Не забудьте кодировку. Это нормально в XML, но ваши переводчики могут использовать неподходящий редактор и повредить файл.

А теперь по главной причине:

(5) Вам придется переставить многие из ваших диалогов, потому что многие строки длиннее, например, Французский или немецкий, чем на английском. И сделать всю статику, кнопки, ... больше "на всякий случай" выглядит паршиво.

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

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

Answer 2

Мое доброе и дружеское предложение от кого-то, кто много работал с локализацией:

1. Grab GNU Gettext,
2. Пометить все ваши строки как _ ("английский").
3. Извлечение всех строк с помощью инструмента gettext xgettext и компиляция словарей
4. Переведите строку, используя такие замечательные инструменты, как poedit.
5. Используйте gettext в своем проекте и упростите свою локализацию!

Вы также можете использовать boost::locale для той же цели - он использует словари и подходы GNU Gettext, но предоставляет другое и более мощное время выполнения, а для разработчика Windows - очень хорошее дополнение - он поддерживает широкие строки, которые MFC требуется использовать для обычного Unicode поддержка.

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

Дополнительное чтение: http://cppcms.sourceforge.net/boost_locale/html/tutorial.html

Answer 3

Использование библиотеки ресурсов DLL является относительно простой операцией и позволяет вам управлять не только строками, но и другими ресурсами. И это его главное преимущество, потому что i18n - это не только перевод строки .

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

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

Answer 4

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

Answer 5

Для этого обычно используется опция DLL, так как процедура загрузки ресурса (например, LoadLibrary) уже написана, то есть вам не нужно писать какой-либо код синтаксического анализа / загрузки.Хотя XML проще редактировать, библиотеки DLL немного более безопасны (пользователи не смогут легко их редактировать) и дадут разработчику (то есть вам) больше времени для работы над логикой приложения вместо написания системы загрузки языка.

HMODULE hLangDLL = LoadLibrary("text_en.dll");
// more stuff
TCHAR mybuffer[1024] = {0};
LoadString(hLangDLL, IDS_MYSTRING, mybuffer, 1023);

Answer 6

Если меняются только строки, то я согласен, что XML - это путь вперед по точным причинам, которые вы обрисовали. Легко редактировать другим людям, легко менять язык во время выполнения и т. Д.

Единственная причина (на мой взгляд), что вы выбрали бы вариант 1, заключается в том, что локализуются другие вещи, кроме строк, например, требуются другие значки.

Если это просто текст? Я говорю иди с XML.