1. дома
  2. Вопрос и ответ
  3. Интернационализация в MFC

Интернационализация в MFC

2010-12-09 3 views
10

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

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

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

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

Любые советы приветствуются.

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

источник

2010-12-09 Cosmin

ответ

7

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

Причина:

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

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

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

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

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

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

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

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

источник

2010-12-09 13:47:37

1

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

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

источник

2010-12-09 13:16:34

+1

Хотя в этом варианте осуществления, вы должны реализовать каждую строку? – Sunscreen 2010-12-09 13:20:12

+1

Вам нужно перевести каждую строку в любом случае. Опция XML позволяет быстро редактировать файл с помощью строк в них, но вам нужно загрузить строки в пользовательскую структуру данных, чтобы получить доступ. Опция DLL позволяет использовать встроенные функции загрузки ресурсов, поэтому единственное, что изменяется, это то, какую DLL вы загружаете для языковых строк.Каждая DLL должна иметь одинаковые идентификаторы, присвоенные переведенным строкам, поэтому в примере, если бы я был изменен на text_de.dll, IDS_MYSTRING был бы переводом Данниша для того, что было на этом ресурсе. – 2010-12-09 13:24:46

+0

Прохладный, спасибо за разъяснение. Я думаю, что это правильный путь, хотя самый сложный (более код);) – Sunscreen 2010-12-09 13:36:22

0

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

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

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

источник

2010-12-09 13:17:38

2

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

источник

2010-12-09 13:18:58 Sunscreen

4

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

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

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

источник

2010-12-09 13:49:47

5

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

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

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

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

Дальнейшее чтение: http://cppcms.sourceforge.net/boost_locale/html/tutorial.html

источник

2010-12-09 13:52:07 Artyom

Смежные вопросы

 Смежные вопросы