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

The biggest issue is printf and cousins

[ObviousGuy]

Once you start trying to dynamically generate strings using printf you are bound to run into problems, especially with languages that have a reversed order from SVO.

Even careful use of resource files can miss this problem.

And that's all I have to say about that.

Qt

[e8johan]

tr( "My string in my native language" )

Use Qt from Trolltech, give your translator access to Qt Linguist and have it all for free!

Seriously, Qt's i18n capabilities makes it easy and works.

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...

[Matthias Wiesmann]

A few more points:

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).

Why not change the symbol depending on the localisation then? A letterbox might be a good icon for a mail program, but different countries have different letterboxes. Why not change icons in the localisation process? Finding truly multi-cultural symbols is hard.

Qt's flexible dialog layout algorithms ensure that the text is always visible.

While I agree that this is first step, the fact that all widgets are visible does not guarantee a nice layout or even a comprehensible one.

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 far as I know the problem is that you also need to reverse label and data fields if you are in some form-like interface. (Label first, field after wards). You might also need to swap the position of the default button of a dialog.

I simply think that doing the localisation outside of the context of the GUI is not the best way. It would be like translating a text sentence-after-sentence, without the ability of changing paragraph boundaries and such.

This approach is particularly annoying for complex dialog boxes where the text label should not be ambigous and the layout clear and precise. Smart layout managers and nice object oriented design can do a lot, but except if you manage to program culturally aware layout managers, there is a limit at what they can do. In the end, only a human eye can judge if an interface element makes sense or not. Sometimes, it makes sense, to add a tab/pane to a dialog instead of simply making it grow...

Personnally I like the way things are done in Cocoa. Localised version of each file are stored in different directories. Strings are stored in separated files, but also the layout of all GUI elements. Those can be edited with the Interface Builder and changed as needed and the applications does not need to be recompiled, nor does the editor need access to the source code.

This makes it possible for a non-programmer to localise a program very easily and in a graphic fashion. In fact you can even test the behaviour of the layout manager (resizing etc...) in the graphical editor. This also means you can easily customise the interface of an existing application or even add you own localisations.

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).

Re:When will people understand...

[Matthias Wiesmann]

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.

MMh, the problem, I think, is that icons should be at the same time powerful and clear symbols, and at the same time multi-cultural, this is in essence contradictory. A letter is a relatively good icon because it is very internationnal. The problem is, you often need more complicated/subtle symbols for instance to reprsent verbs (thanks to all those toolbars). In this case, it might make sense to replace an icon, or even to replace an icon by text (or ideograms).

Consider for instance a graphical program with a button on a toolbar to center stuff. A western icon for such an action would probably be some icon with a centered object with some arrows comming from all directions. Maybe put a C on the objet to make it clearer. In a chinese or japanese, it would make sense to replace the whole thing with the Kanji representing center.

I'm not sure this example is a valid one, but the idea is simply in a different localisation, different symbols and layout can be more efficient.

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.

Thanks. God, I'm having a reasonable discussion on slashdot, I must have taken the wrong pill this morning. :-)

However, I think that the problem is quite easily fixed by a good design (which, in turn, Qt represents in many cases).

Actually, I have no doubt about the quality of Qt. The root question is more philosophical, i.e to what extent goes localisation - my belief is that it goes behond text, but you are probably right in 99% of the case, translating text is enough.

Re:When will people understand...

[e8johan]

Just to repeat what I was (trying) to say earlier: I believe that most culturally dependant icons can be replaced by a better, more univeral equivalent. As a developer I'd rather pick a slightly more diffuse but universal symbol and let the user turn text on the buttons on and off. This way the users can learn what the icons means.

I believe that icons usually are leared rather than understood right away. This is why I understand that a white sheet means "new document". This way a set of metaphors have been developed. These symbols are, as many symbol based languages, becoming more and more abstract and applied to a wider and wider field of applications.

As for putting text in icons (such as the C in your example). This is actually done in Word (and the other Office applications) for the text formatting buttons (bold, italic, underlined). The swedish word for bold is fet, thus the icon is a bold F in the swedish version (as opposed to the bold B in the english version). So I guess that this is one of 0.1% of the cases where it is necessary to internationalize icons too.

Yet another problem with language specific versions of software is the delivery dates. Here (at work in Sweden) we prefer to use US-English software because of three reasons: 1) They are usually released earlier, 2) They are usually patched quicker and 3) We all speak English, at least the computerized version of English :).

As for having interesting discussions on /. This is perhaps my third sane discussion in a year, so they are pretty rare. But when I run into one (such as this) I really enjoy them, so they are worth the wait!

GNUstep

[root 66]

One nice thing about GNUstep [http://www.gnustep.org] is its scope of localization possibilities.

Basically (i.e. following the OpenStep standard) the system has localization files which contain formats for dates, monetary strings, whether and when to use dots or commas (3,000.50 would be 3.000,50 in German), etc.

Unicode usage is built-in and was supported since the early days of the project. (Klingon characters do display very well.)

Applications can have localized strings, of course. It is possible to automatically create the [Lanaguage].lprof/Localizable.strings files from the source, only adding strings which haven't been translated, marking obsolete ones, etc.

Additionally it is easily possible to have hand crafted/adjusted user interfaces for different languages. Either using Gorm (the Interface Builder) files for every language, or using Renaissance (the xml based user interface format) which can both: lookup localized strings and have custom interface files for specific languages.

I guess that possibly outstanding issues (read direction and text layout maybe) will be addressed, too.

Of course, GNUstep (and to some point Apple's Cocoa) has a lot of other great features. Just check it out ;-)