Guide to Globalizing Windows Applications

JimCricket writes "Does your application need to be usable in multiple countries? Art & Logic has posted a handbook for developers who want to globalize their applications. The handbook gives design and implementation tips, plus code samples for globalization on Windows applications."

Comments

"Globalize?"

[Twirlip of the Mists]

Since when did the term become "globalize?" I was under the impression that the word was still "internationalize."

Re:"Globalize?"

[Twylite]

Where's my moderator points when I need them sigh. One of the reasons good information is becoming hard to find on the 'Net is that everyone wants to invent their own name for something, often because they haven't bothered to research the topic first.

Internationalization, i18n, and occasionally localization are the accepted terms. Globalization is used in economics, not CS. Mod this guy up!

Why bother with Win32/MFC now ?

[Bazouel]

I mean, that's the whole point of .NET !

MFC is a f*cking mess : no respect of standard, need to discover "hidden" interfaces, break of OO concepts, overuse of macros, bloated, etc. etc. etc. And if you add COM/ATL to that ... well, welcome to hell :)

And don't even get me started on Win32 API ! That might be fine for some cases where optimization is a top priority (and even then ...), but do you really want to spend at least 50 % of programming time digging for some informations about an obscure function call or simply reinventing the wheel all over again ?

So while this guide can really be useful for what it's meant for (mostly C++ with MFC), I say, just take a look at C# and .NET and I can guarantee you will not want to go back to those "good old days" where you needed to hand code unicode conversions !

________________

It's just a plain mess in Windows

[fille]

Don't do it like Microsoft Office. Excel for instance derives the use of commas from the Windows settings. This is just lame. If you open an Excel file written in an English version, it's all fucked up in a Dutch Excel. Writing a paper in Dutch and English is therefore not that easy if you want to include Excel-files. Centralising these settings and imposing them on all applications is the worst option, I suppose. Saving the settings in the file may be a better idea..

When will people understand...

[Matthias Wiesmann]

That localising an application does not simply mean changing the text strings and using an automated translator?

Making truly localisable applications is hard, a good toolkit helps as does unicode support, but many issues are simply a question of design and of understanding. While some points are raised in the linked article, others are not.

• The first thing to understand is that you do not localise text, you localise resources. Window and dialog layout change depending of the language, so do icons (certain symbols have not the same meaning in different cultures). This is why layout should be described in resource files, not hard coded.
  French texts are longuer than in English. If you fail to take this into consideration, your text will spill out of the text zone. I had a Redhat installer with this problem, french labels were always incomplete the end was always chopped off - and no, those text field did not become scrolling. This was very annoying has help messages only contained text in the style of "this button does..."
• Do not assume that certain data will always be printed in the same way, traditionnal (postal) address format changes from country to country.
• Do not assume anything about the keyboard layout. Don't use shortcuts with keys that may no exist directly on some keyboards, like say control-].
• Do not assume that text layout rules are the same in all the languages. French spacing conventions are different from English spacing conventions. No doubt that texts in other writing systems with ideograms or that read right to left have also different text layout rules.
• Be very carefull when comparing strings. For instance in german, the umlaut can be changed into an 'e' that follows the letter. E.g Zürich can be written Zuerich. As people who don't understand umlauts simply strip them, Zürich can be written in three ways: Zürich, Zuerich and Zurich. Of course every language has its own specifics.
• Do not assume that there is a correlation between interface language, sorting rules, date display rules, the keyboard layout and country specific settings like monetary units, the ways addresses are printed etc...
  My machine is set up with an english interface, a swiss-french keyboard, and swiss french date display and sorting rules.

By the way, "My string in my native language" automatically translated into French gives you "Ma ficelle dans ma langue natale", which roughtly means "My small rope in my native language".

Re:When will people understand...

[e8johan]

I do not disagree with you, but I would like to bring forward some points:

"The first thing to understand is that you do not localise text, you localise resources. Window and dialog layout change depending of the language, so do icons (certain symbols have not the same meaning in different cultures). This is why layout should be described in resource files, not hard coded."
Qt's flexible dialog layout algorithms ensure that the text is always visible. As for changing symbols. This can be avoided if the symbols are picked with care and cultural dependencies are avoided (i.e. do not draw a wooden log for the log-viewing-function).

"French texts are longuer than in English. If you fail to take this into consideration, your text will spill out of the text zone."
As I pointed out in my last comment, Qt has flexible dialogs ensuring text (and more generic, widgets) visiblity.

"Do not assume that text layout rules are the same in all the languages. French spacing conventions are different from English spacing conventions. No doubt that texts in other writing systems with ideograms or that read right to left have also different text layout rules."
As I understand it (haven't tried myself) Qt can handle right-to-left texts, the rest is really in the text-showing widgets and translations.

As for string comparisons, this is a constant problem. I live in Sweden where , and are sorted differently than in germany. Despite being exactly the same characters.

"By the way, "My string in my native language" automatically translated into French gives you "Ma ficelle dans ma langue natale", which roughtly means "My small rope in my native language"."
By using Qt Linguist the translator gets to work with one string at a time, so when translating the above string to Swedish I'd write it as "Min sträng på svenska".

Most of these problems can be solved by a good object orientated approach. For example the text layout policies and such can be stored in different classes, with the widget showing the text working independently, simply asking the assigned text layout manager class.

Qt does support good OO approaches and the rest is up to the software designer.

Re:When will people understand...

[e8johan]

One of the reasons to icons, imho, is that they are supposed to be universal. For example (your example) a mailbox is a bad symbol, as it is not universal due to cultural differences. However, letters, or rather, envelopes generally look the same, and thus make a better symbol. This is my view on how to use icons.

You claim that right-to-left (RL) layouts require RL ordering of widgets and labels. With the design of Qt, it would be possible to re-implement the layout classes (mainly grid and horizontal layouts, and QHBox) so that they, depending on locality, work in the RL direction when needed.

When you say that translating and application outside the GUI would be like translating a text, sentence by sentence, you are not too far away from reality. However, most texts shown in applications are short commands like "Open File", "Rescan Mailboxes", etc. These are sentences that are to be translated separately after standard templates. Other, more explanatory, texts such as help, wizard guides and such are generally treated as one unit, thus translated several sentences in a chunk.

You claim that sometimes it will be needed to change the layout of a dialog more dramatically than simply altering the LR/RL layout and translate the texts. Of course these situations will occur, as there always are exceptions to all rules. However, I see this need as the symptom from a bad design choice. It should be possible to use the same dialogs everywhere (after having altered the texts and LR/RL order) in 99.9% of all cases.

The Cocoa approach seems good to me. This is a similar approach to the one that the good old GEM/TOS used on the Ataris used. It is possible to do this using Qt too. Simply load and create the dialogs dynamically. Store them on disk as XML (.ui) files and edit them in the Qt Designer. This combined with Qt Linguist (allows translations of in-code texts) are sufficient in 99.9% of the cases. This also allows non-programmers to localize applications quite easily, even though I don't want a non-techie to mess with my dialog definitions.

Please don't take my replies as objections to your points. They are good points and apply to a great part of all software produced. However, I think that the problem is quite easily fixed by a good design (which, in turn, Qt represents in many cases).

Not so -- globalization is real

[GCP]

Globalization = Internationalization + Localization.

Globalization is universal internationalization plus the form of localization that is used when you have a universal foundation.

Some people have claimed internationalization by merely covering major European languages, arguing that since it covers multiple national languages, it is internationalized.

Globalization closes that loophole by aiming for "global" coverage -- a universal foundation capable of handling all languages (for some practical, as opposed to literal, definition of "all").

It also includes the "localization as skins" form of localization. Traditional localization tended to produce different products for different languages. Globalization is an architectural approach that starts by creating a single, universal foundation (the "internationalization" part), then it adds a selection of localized skins (localization, but the new kind, not the old kind) to complete the app for all locales for which skins are available, and making it functional even for languages for which localized skins are not available. (In other words, even if there is no Greek UI, you can still do Greek work thru the English UI, but your menus and manuals will be in English.)