1

This is not a duplicate of VC++ 10 MFC: What is the correct way to do localization since I refer to dialogs, not localization of MFC in general. The guys in the referred question seem to be perfectly fine with duplicating dialogs.

I am used to this approach when it comes to localizing UI:

  1. You draw your dialog once
  2. In the dialog you assign string resources but never hardcode strings
  3. For each new language you just update your string resources

That was fine for Android, iOS, XAML.

Now I have to work with an old MFC project. Here I keep wondering: Why do they hardcode strings in dialog resources? For each new language they draw the dialog again (in a separate DLL though)! Not to mention the effort they have to spend when they alter a dialog. In fact the team is not very eager to update UI on a frequent base ;)

So, my question: How does the industry handle localization of MFC dialogs? Does Microsoft for instance really draw dialogs for 180 languages again and again???

  • Do you guys stick with MFC's primitive approach and overcome those issues by using additional translation software that manages your duplicates dialogs?

  • Do you guys draw your dialogs once and assign Strings at runtime e.g. in OnInitDialog?

Community
  • 1
  • 1
OneWorld
  • 17,512
  • 21
  • 86
  • 136
  • @mpiatek Disagree. I know this question. But I refer to dialogs. Not localization of MFC in general. The guys seem to be perfectly fine with duplicating dialogs in the linked question. Not me ;) – OneWorld Feb 17 '17 at 11:14
  • Possible duplicate of [VC++ 10 MFC: What is the correct way to do localization](http://stackoverflow.com/questions/8737343/vc-10-mfc-what-is-the-correct-way-to-do-localization) – mpiatek Feb 17 '17 at 11:15
  • 2
    Since the [resource-definition statements](https://msdn.microsoft.com/en-us/library/windows/desktop/aa381043.aspx) do not allow to use indirect references to strings, you either have to load localized strings at runtime, or localize your dialogs. The latter is probably what professional software does. If you look at Android or XAML-based UIs, you'll find lots of poor layout, and truncated strings. While convenient, that type of 'localization' is for low-quality UIs. – IInspectable Feb 17 '17 at 11:19
  • @OneWorld [answer](http://stackoverflow.com/a/8781157/7574136) to that question mentions two articles which should solve your problem as well. MSDN has an [article](https://msdn.microsoft.com/en-us/library/x6h91d9w.aspx) about it too – mpiatek Feb 17 '17 at 11:46
  • @mpiatek The MSDN article doesn't mention issues about duplicated dialogs. It seems to be perfectly fine with duplicated dialogs. The answer basically posts both of my suggestions but there is no info about what's the commonly accepted way. One of his articles refers to www.apptranslator.com which is a homepage for sale. – OneWorld Feb 17 '17 at 12:10
  • @IInspectable Thx for clarifiying about indirect references. Android or XAML offers much more flexible layouts that can grow on larger texts developers can use to avoid truncating strings. They just have to do so. – OneWorld Feb 17 '17 at 12:15
  • @OneWorld So to clarify - dialog is a resource type and you have to create localized versions of your resource dlls. Logically these should contain localized resources like strings and **dialogs**. Taking into account things like resizing or possible changes to the layout for some translations, handling localization in OnInitDialog would be painful – mpiatek Feb 17 '17 at 12:22
  • 1
    @OneWorld: That's the theory. And yet, I often find myself looking at ellipses, wondering what the full command text might be (if just to tell it apart from multiple such truncated menu options). Or switching to another language only to find out, that menu shortcuts are assigned multiple times. As arcane and primitive as it may look, going that route has a proven track record of potentially producing commercial grade UI quality. Android or XAML, not so much (don't know about iOS, but Mac OS X suffers from the same, just worse). – IInspectable Feb 17 '17 at 12:25
  • @OneWorld: I use a special software (not free) that directly translates the RC file and outputs a new one in a different language. The software has a database and a automatic glossary. I still use staelite DLLs for the MFC projects. We have multiple components that are all translated into 4 languages. We use English as primary language (even our native tongue is German), than we translate into German, French, Turkish and Hungarian. – xMRi Feb 17 '17 at 13:32
  • 1
    @xMRi What's the name of it? – OneWorld Feb 17 '17 at 14:07
  • 1
    RC-WinTrans. https://www.schaudin.com/web/Home.aspx – xMRi Feb 17 '17 at 15:59
  • Version 7 should be sufficient for MFC rc files... – xMRi Feb 17 '17 at 16:11
  • In my company, we use RCWinTrans – sergiol Feb 17 '17 at 18:06

0 Answers0