Guide to Globalizing Windows Applications 43
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."
"Globalize?" (Score:5, Informative)
Re:"Globalize?" (Score:5, Insightful)
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!
Re:"Globalize?" (Score:1)
For those interested enough to care, localization is where you produce multiple versions of your software for different languages. Internationalization is where the same version of software can select between different languages. Multilingualization means you can display multiple languages at the same time if you want. Globalization is where multinational fast food chains force the same crap down the throats of the whole world.
Re:"Globalize?" (Score:2)
Languages and locales are two subtly different things. There is also liver pudding, where is something else again.
For those interested enough to care, language is a medium of communication. Locale indicates language as well as many other socioeconomic and geographic differences, including curreny, date/time representation and timezone.
Then again, you clearly know what you're talking about already, so this is mostly for the benefit of everyone else ;) Thanks for the clarification.
By the way, do you know what they call a quarter pounder with cheese in Paris...?
Not so -- globalization is real (Score:5, Informative)
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.)
The biggest issue is printf and cousins (Score:2, Interesting)
Even careful use of resource files can miss this problem.
And that's all I have to say about that.
Re:The biggest issue is printf and cousins (Score:2)
Yep, serious programs need to be storing all strings in some sort of resource of the form "blah blah {1} blah {2} blah blah blah {3} blah", where the {n} are ordered replaceable parameters such as numbers or dates. A translation agency can deal with this, adjusting the word order and idioms as appropriate and giving you back a string in the same format, with the same markers for replaceables (though not necessarily in the same order).
This is kinda what printf should have been, but you can't change that order straightforwardly in a printf format string. This is also the single biggest reason that C++ IOStreams suck for real world applications aimed at multiple markets. The idea of extensibility via chaining things together with << was nice, but they forgot that the chaining has to be soft-coded so you can translate without changing the code, not hard-coded in the app.
Why bother with Win32/MFC now ? (Score:5, Insightful)
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
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
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
________________
Re:Why bother with Win32/MFC now ? (Score:2, Insightful)
And yes, this is the time old decision of when to move, but it's not like you'll even have a quarter of the audience you would programming for the older method.
Most of the problems you speak of don't exist if you choose the right dev library (open source or not)
Qt (Score:3, Interesting)
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.
Re:Qt (Score:2, Insightful)
Re:Qt (Score:2)
"Qt 3 is not free for Windows."
Nope. And neither is Windows.
Re:Qt (Score:2, Insightful)
Re:Qt (Score:2)
1. Free as in freedom, i.e. access to the source.
2. Free as in very little extra work.
Also, Qt is free for GPL use, and many (if not most) /. readers are GPL users. Also, coming to think about it, Qt 2.3 is free (as in no money spent) for Win32.
Re:Qt (Score:1)
I think it's sad that you cannot use Qt/Windows v3 for free (as in beer at least) as well. It would make porting KDE stuff to Windows much easier. Yeah, this might sound ridiculous, but applications like Mozilla, Open Office and the Gimp (and Apache, MySQL, Perl, PHP...) make Linux feel more common when I try to switch (because I already know them). If I could get used to KDE applications in an environment that I'm familiar with (Windows), a transition to Linux would be much easier. But it's just not possible (with KDE 3) because no Open Source Developer would pay 1,550$ to port KDE to Windows, right?
Second, I want to learn C++. I already heard about the hassles of Win32 and MFC, so I want to skip that experience and start directly with a better API. Easy is good and cross platform would be even better. I once wrote an addressbook in Perl/Tk and it worked nearly unmodified under Linux. That's pretty cool! But if I develop applications in C++, I want that, too! So there are Qt and wxWindows. For some reason I think that Qt is a bit better (though I can only tell what I read in reviews). Even if it is not, I would like to find out. And I will not switch to Linux just for hacking C++.
Re:Qt (Score:2)
"Do you know the differences between 2.3 and 3.x? I'd really like to know them, because right know it feels more like they are giving away their old junk for free."
I'd say that the main difference is that 3.x holds alot more cross platform stuff than only GUI components (for example SQL access, Sockets and such). Most applications can quite easily be written using 2.3.
My personal experience is that 2.3 is a damn good toolkit making MFC look stupid. So if you are into win32 programming, I'd recommend Qt2.3 in front of anything else. Also, the Qt documentation is one of the best references I've ever used.
"I think it's sad that you cannot use Qt/Windows v3 for free (as in beer at least) as well."
The sad truth is that it is far more easy to make money from win32 developers. They usually pay for the compiler, IDE and OS. Also, TrollTech is a company trying to make profits, so, instead of crying over not getting 3.x for win32 for free, be thankful for the 2.3 for win32 and 3.x for X11!
If you want to learn C++ and do GUI applications. I cannot recommend anything other than Qt. It is the best toolkit I've ever used!
Re:Qt (Score:1)
I *think* it would be better if there was Qt 3 for free for Windows with the same limitations the Linux version has: that your product has to be GPL, too. Most companies that want to use Qt will still pay because they don't like the GPL. So money can't be the motivation, right? Plus, guys like me who might actually have such a company some time, or work for such a company could influence the decisions the company makes based on our experiences. But we cannot make experience with Qt 3 - which is of course what a company would use. Oh, of course there are the evaluation versions... but how much are 30 days? And we could switch to Linux... yeah... right. You know, I just don't really get the "why" part. Do they want to help to convert people to Linux? Wrong way IMO. Do you know?
Re:Qt (Score:2)
"In how far is this sad?"
It is sad since these developers miss out on the whole open source movement as they are forced in paying and/or scared off by loads of FUD.
"Most companies that want to use Qt will still pay because they don't like the GPL. So money can't be the motivation, right?"
I do not have any direct insight into TrollTech, nor their business decisions. I do, however, believe that many of Qt's smaller customers develop software to be used in-house (i.e. not to be sold to a third part). For these customers a GPL would just mean free software and nothing else.
As for the open source movement just standing there being thankful and shutting up. I must disagree. Most software developed by the open source movement is protected by licenses and competes with commercial software. This is not what I call being thankful and shutting up. However, when a company (such as TrollTech) chooses to give away a GPL version of their flagship product, I suggest that we are thankful and shut up about licensing issues or develop an equivalent package with a better licensing scheme.
Re:Qt (Score:1)
When will people understand... (Score:5, Interesting)
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.
- 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...
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".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..."
My machine is set up with an english interface, a swiss-french keyboard, and swiss french date display and sorting rules.
Re:When will people understand... (Score:5, Interesting)
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... (Score:3, Interesting)
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... (Score:5, Interesting)
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... (Score:3, Interesting)
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.
Thanks. God, I'm having a reasonable discussion on slashdot, I must have taken the wrong pill this morning.Re:When will people understand... (Score:3, Interesting)
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!
Re:When will people understand... (Score:1)
If you're having problems with French, then you're going to have absolute nightmares when you translate it to German (but then, you'd know that already being Swiss).
A long time ago, I remember reading that Microsoft develops the English, German and Japanese versions of their software first, as the German version flushes out bugs where there is not enough space on dialogs etc, and Japanese tests that there is no confusion between bytes and characters in the code. Dutch and Chinese would have done just as well, but the German market is bigger than the Dutch and at the time the Japanese market was bigger than Chinese (this may have changed, or will soon), so it made sense to get those languages to market first.
It's just a plain mess in Windows (Score:4, Interesting)
GNUstep (Score:2, Interesting)
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
Re:GNUstep (Score:1)
Re:GNUstep (Score:1)
The entire system (file system hierarchy, having a mach kernel, bsd userland, dock, services, etc) is pretty much similar to OPENSTEP/NEXTSTEP.
The only thing really missing is the cross platform ability. But here, GNUstep comes into the game, again. It's just lovely to see GNUstep apps run on UNIX and Win32 (although Win32 gui support is alpha stage currently), as well as OS X.
What Defines A Windows Application? (Score:1)
Great i8n support and runs anywhere (even on Windows XP)
Re:What Defines A Windows Application? (Score:1)
Cut'n'Paste (Score:1)
Most of this information seems cut-and-pasted from MSDN or from one of the reference books the author cites at the end of the article.
I have read too many of these types of articles, and they frustrate me for several reasons.
All of the MSDN documentation would have you believe that making "portable" code (the author's word, not mine) is as simple as using TCHAR and _T macros. Reality is much different from this.
Nearly all of the localization facilities provided by MSVC are only interesting if you are willing to produce a different executable for WinNT/2K/XP than from Win95/98/ME.
In my line of work (game development) it has not been acceptable for us to have different versions of the game that try to play together on-line running on different versions of Windows, especially when they are exchanging chat traffic.
This solution to localization also presupposed that you want to use UTF-16 for Unicode encoding, and also use the UTF-16-savvy versions of the standard C-library functions to operate on UTF-16 strings.
On my most recent project, I did extensive work with Unicode, but did not use UTF-16! The only time my text was UTF-16 was in a temporary buffer because windows only provides certain APIs for converting from MBCS strings into UTF-16, which I then converted to UTF-8.
For our purposes, the TCHAR macros were completely useless: we always wanted char strings, unless we were explicitly using a UTF-16 buffer. In either case, the "size" of the characters was determined a priori, and it was never considered to "flip the switch" and compile with UNICODE defined.
If you are looking to build a single executable for all versions of Windows, I strongly recommend that you investigate using UTF-8 encoding, and throw all of the TCHAR/_T/_tcs* stuff overboard. With some careful work, you can build a single version that works on all Windows OSes, and avoid the confusion of having multiple versions of the program to support "normal" strings and "wide" strings.