by Michael S. Kaplan, published on 2007/12/10 10:16 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/12/10/6715776.aspx
In response to the blog post from guest blogger Erik Fortune entitled There is no E in MUI, even if you pronounce it MOO-EE, regular reader Cristian Secară commented:
To whom is addressed that tutorial ? The sense of the above post is like "we, Microsoft, are recommending to you (?) that MUI files should be build like this and like that".
Who else is building MUI files other than Microsoft itself for the own software ? I never encountered a non-Microsoft product that uses the "MUI" model Microsoft is using. Most other translations are either simple .ini files or .lng files (plain text, usually ANSI, sometimes UTF-8 with explicit header), or GNU gettext compiled files (UTF-8), only rarely C++ distinctly compiled files (either locked to a single language, or user selectable).
What about LIPs ? (an unfortunate user restricted language translation concept, in my opinion)
Cristi
I thought that Erik's reply to this and the issue in general was deserving of a separate post....
First, Erik's response:
The tutorial is primarily addressed at anyone developing applications for Vista and beyond.
It’s true that few outside of Microsoft use MUI as such, but that’s largely due to the fact that we didn’t provide any way to do so prior to MUI. There are certainly plenty of applications out there that use resources, and the application MUI support in Vista is designed to make it relatively straightforward to migrate from “normal” use of resources to the MUI satellite model.
But “MUI” itself is only one piece of the tutorial. All developers, regardless of resource technology need to understand the changes in the operating system, the effects they’ve already had on the way that Windows itself is deployed, and the changes that are probably still to come as multilingual systems become more common.
There’s also some specific guidance for folks who are already doing certain things that will cause problems on multilingual systems or images (e.g. putting strings in the registry). Those slides can safely be ignored by anybody who isn’t doing one of those things.
The bottom line is that applications need to install and run well on multilingual systems. From a resource technology point of view, that pretty much means:
1) If you aren’t already using some kind of satellite model for resources, you should probably switch over to one. MUI is a fine choice if you already use .rc files, but it certainly isn’t the only one.
2) If you are already using a satellite model for resources, you should probably modify it to take the full OS fallback list into account so that users end up with a consistent experience.
The other place where the changes in Vista really impact developers is in deployment, particularly deployment of anything that is preinstalled into an OEM or corporate image. Basically, you can’t really assume any particular relationship between the language used at install time and the languages that might be used at runtime.
As a minimum, you should install resources for every installed system language, but there’s a whole continuum of things you can do (e.g. install everything or download languages on demand).
I’m not sure I understand your question about LIP languages. Partial/LIP languages does affect applications because the parent/base languages end up in the fallback list (e.g. Catalan shows up as either “ca-ES es-ES” or “ca-ES fr-FR” depending on user preferences), but otherwise it shouldn’t be a big deal.
And now I will say a few words. :-)
Now this is a point that really is not discussed often enough, I figure it is probably worth more than just a post but we'll start with this one and go from there....
To start, it is important to care about MUI if you care about either resources or localization in either managed or unmanaged code.
Because MUI is what controls and owns the resource loader.
And it is now the framework by which localization is supported.
Beyond that, people have been using resource models for years before MUI was one of those clever ideas one thinks up -- in frameworks like MFC (the Microsoft Foundation Classes). In fact, to talk about MFC for a bit, there are only two essential differences between the Win32 MUI model and MFC:
The sample which will be showing up here soon provides the small bit of code you can add to an MFC project which changes the first point so that MFC can follow the OS resource fallback model within its own loader, and the second point doesn't have to change at all since how one names the resources is not important to the model itself -- being able to find them is, and that does not have to be consolidated in any way at all.
(At the same time, one can consider supporting changes that make sense if they want to -- by evaluating what is there one has the option to do this, at least!)
Even if you look within products at Microsoft you will see the amount of variability here -- the decimal LCID based directories and .RLL files used by SQL Server, the hexadecimal LCID directories used by Windows <= Server 2003, the decimal LCIDs used by Office, the SABBREVLANGNAME-based DLL suffixes used by any project with an MFC heritage, the named resource assemblies used by .NET, and so on.
None of those have to change to take advantage of the parts of MUI and the resource loader provided by Windows, if people want to.
Now I myself have often railed about limitations in the MUI model on Windows that block people from working beyond what Windows does for itself, and the folks on the MUI team have gotten that feedback not just from unimportant people like me but from important people like ISVs and OEMs on behalf of IHVs and the IHVs themselves and from Office. And they are looking into how to address those concerns going forward.
But in the meantime what is there does work and the ability to work beyond MUI when/if you need to is there completely, using the same old resource loader one always has been able to use (which is owned by the same team -- MUI -- anyway!).
As to Cristi's other point about the people who use resources completely outside of the traditional Win32 resource model, those people can actually consider whether they want to provide a loading solution that makes use of the MUI functionality in Windows so that the user's language choices for the OS can properly influence applications. That is behavior that makes the application defaults look more sophisticated, as well, so there is very little to lose in understanding the model even in a case where one is not going to be using every single feature within it....
Once again every visible character in Unicode supports MUI in general and this post in particular; the invisible ones continue to evaluate the technology
# jmdesp on 10 Dec 2007 2:08 PM:
About MUI, I got involved recently in a quite heated debate about the localization of Firefox, that made apparent one need for internationalization that I don't know if even MUI solves.
It's the need in some cases to localize the OS provided GUI fonts.
Fx 3 will use in it's menus the unicode ellipsis character, U+2026, as should be according to the official Microsoft GUI guides (BTW it also now uses uniscribe so you should find out it support i18n significantly better now)
But as a result an english localized Fx will not look perfectly right when running under a japanese OS, because the OS will provide a japanese font for the menus, and the U+2026 character will look significantly different.
There seem to be no good solution for that, except that ideally there should be a way for the GUI font provided by the OS to adapt to the localization of the app. And AFAIK even MUI cannot do that.
# Jeroen Ruigrok van der Werven on 11 Dec 2007 5:45 AM:
Such things are indeed necessary.
Perhaps it should be a bit like CSS offers with the :lang(..) constructs, that allows you to specific a font-family preference per language. With all the respect for Tahoma or Arial Unicode (assuming it is even installed next to Arial!) but they're hardly adequate nowadays with Unicode 5.1 around the corner.
referenced by