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

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

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

  • Скомпилировать и развернуть локализованные файлы ресурсов как библиотеки DLL
  • Извлеките и замените все строки локализованной версией. Для каждого языка будет файл XML (или простой текст).

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

Приветствуется любое пособие.

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

ОТВЕТЫ

Ответ 1

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

Причины:

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

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

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

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

И теперь по основной причине:

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

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

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

Ответ 2

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

  • Grab GNU Gettext,
  • Отметьте все свои строки как _ ( "Английский" ).
  • Извлеките все строки с помощью инструмента gettext xgettext и выполните компиляцию dictionalries
  • Перевод строки с использованием больших инструментов, таких как poedit.
  • Используйте gettext в своем проекте и упростите свою локализацию!

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

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

Дополнительная литература: http://cppcms.sourceforge.net/boost_locale/html/tutorial.html

Ответ 3

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

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

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

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

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