Not every bit of the printer dialogs support MUI 100% of the time

by Michael S. Kaplan, published on 2005/10/27 03:31 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/10/27/485478.aspx

You can use the PrintDlg and PrintDlgEx functions to show the Print Dialog Box and Print Property Sheet, respectively. And these dialogs have full support for MUI in that they will do the right thing for your UI language in Windows (though not for the .NET Framework UI culture settings, as I just pointed out here).

This is not due to lack of work of people on the development or localization teams in Windows; it is due to the fact that there is are Advanced and Properties dialogs that are in many cases are printer-specific and provided within the printer drivers, and not all printer drivers support all of the MUI languages (since the drivers are mostly provided by the companies who make the printers, Microsoft obviously cannot force them to support all languages).

Furthermore, since these are external companies, some may support localized dialogs but ones that do not support MUI; in this case you would install the driver for a particular language and if you wanted to have a different language you would have to run another install progream (possibly even removing the original one first).

There are folks at Microsoft who work with these companies and help to provide info and on how to support MUI, but obviously not every single one of them will necessarily do this.

Don't blame Microsoft (in this case, that is; I am sure there are other problems you can blame us for!). Instead send feedback to the maker of the printer and its drivers. Point out the problem. How MUI support might be in their best interest. They hear it from us, but obviously the people who buy the hardware really do have an important voice here (the people who provide the money obviously do!)....

This post brought to you by "Њ" (U+040a, a.k.a. CYRILLIC CAPITAL LETTER NJE)

Hmmm. This looks like 90%+ of the problem is just translated strings. A whole bunch of users will happily, even preferably run in English UI anyway, because they understand English technical terms better or they've been bitten by too many poor translations. A bunch more will be content so long as the text is lucidly translated into their preferred language.

Then I'd guess to get to 99% you're going to need LTR layout switches in the GUI, which is still cheap enough for common widgets, but obviously puts an extra burden on developers of custom widgets.

Presumably the reason why this actually needs replacement dialogs in Windows, rather than just a translation catalog (as would be provided in Unix) is the pixel-oriented design process Petzold describes in his lecture ? Or is there some other reason (in the common case I mean, of course one can invent scenarios where a complete re-design is essential) ?

Nick brings up an interesting point that we have to deal with in the game industry.

A portion of the non-English population want to play RPGs (role playing games, usually with significant dialog) in English due to low quality translations.

This isn't the fault of the game producers or the translators from a desire to accept poor translations. It is often the case that the dialog systems and the translation process does not meet the needs of other languages.

For example, in English it isn't hard to create genderless dialog. Two males, two females or mixed couples can be talking and the dialog is the same. But once you get into other languages such as French, it because much hard (if not impossible) to create genderless dialog. At this point the game engine developers hack in gender system. Writers are told to try and still avoid gender specific dialog due to the translation costs. Translators are often not given enough contextual information to properly translate a genderless or gendered line of dialog.

The end result is that the dialog flows great in English but in other languages, even if the translations are ok, the feel of the dialog isn't natural.

You also have problems when languages have to consider station (i.e. a nobleman talking to a commoner.) In other languages, text has to be shorted due to screen space. German is a killer language when it comes to dialog length bloat and UI size issues.

Hi Tim,

Sounds like games have the same sort of translation vs. localization problems as other kinds of software....

The problem in this case comes up beacuse someone has bought MUI and deployed it, and when they see English they consider it a bug and blame Microsoft. I am just pointing out a particular case that people have sometimes reported as a bug that Microsoft is not able to actually address.

Obviously I wasn't clear enough.

Yes, the US English printer driver adds UI to control the extra features of that particular driver. But, on systems I'm familiar with all that's usually needed (in addition to the US English software) for the Dutch, or British, or Japanese localisation is a translation catalog, effectively an indexed text file. It seems (and perhaps I didn't understand you) that the solution in Windows is, or has been, rather more complicated even for a little printer driver.

"We can't provide UI for those custom cases!" is a funny comment, of course you /could/ handle this, but it's not part of the Windows philosophy. See also GINA, VSTi, TWAIN etc. and contrast PAM, DSSI or SANE. No-one expects Microsoft to change their philosophy, the comment was just about the overhead of internationalisation.

Anyway, I went off and read some of the introductory material on MUI and it's apparent that it's a lot more involved than just generating a catalog, so that mostly answers my question.