by Michael S. Kaplan, published on 2008/12/11 10:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/12/11/9194907.aspx
Looking back at the my blog Ready... set... Reboot Redux, part Deux!, in order tp get the link to help answer someone's question, I realized something very important.
That blog does not give the solution, it really only states the problem.
A problem that, while MUI becomes more and more popular at the same time that it's user interface language can remain so easily out of sync with the default system locale, that localizations can find themselves quite easily broken.
But I did not talk about solutions, or even more directly about the nature of the exact problem that a developer needs to be looking at to be in the frame of mind to think about solutions.
Today that is what I am going to do. :-)
Now there are two common reasons that the problem can be happening in an application that a developer might believe to be quite localizable:
Now the core issue here in both cases is that the attribute has to be kept out of the name.
This all applies to italics as well, but that is a single Boolean parameter (LOGFONT.lfItalic), so it easier to store elsewhere if it it needs to be exposed, which it usually doesn't...
When the name is in a string table, all you really have is the name -- the attribute is most often not stored in a string table as anything but a string with the name.
To make that first case localizable, you have to store the LOGFONT.lfWeight value there too -- 700 (FW_BOLD) or 800 (FW_ULTRABOLD), generally, if you want it to be bold.
And of course make siure there is a comment for the localizer to understand what the numbers are -- because that is very unwieldy and hard to understand, otherwise.
Of course by the time you add four strings to a string table (the face name, the size, the weight, and whether it was italic, you may wish you had put the information in a resource directly.
Which brings us to the other option.
If you have the face name in a DIALOG resource, then get it the hell out of there. The FONT keyword in a DIALOG resource only exposes the size and the name. So it leaves you back where you started. Use a DIALOGEX resource instead.
And then if you are using a DIALOGEX resource, then you can specify the font name, size, weight, and italic settings explicitly in a way that is not subject to localization strangeness -- and all of which is nevertheless exposed to localizers.
In case you are wondering why you can't just do the bold/italic stuff yourself always and just not expose those attributes to localization, this other blog explains it -- these attributes should be localizable.
And there you go -- the solution for the problem that was previously described.
Localizability can be hard and the bugs an be subtle -- especially in cases like this where incorrect localizability work can cause the act of localization to break an application....
This post brought to you by ಬ (U+0cac, KANNADA LETTER BA)
# Pavanaja U B on 15 Dec 2008 12:07 AM:
In Word 2003 and prior, there was an option "not to display the font name in that font". This was very useful while using hacked non-English TTF fonts which were using the ASCII codes meant for English for chars/glyphs other than English. This featture is not found in Word 2007. Is there some way to do that in Word 2007?
TIA.
-Pavanaja
# Michael S. Kaplan on 15 Dec 2008 6:35 AM:
This sounds like one for the Suggestion Box? ;-)
referenced by