Slashdot Mirror
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."
Since when did the term become "globalize?" I was under the impression that the word was still "internationalize."
I write in my journal
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.
I have been pwned because my
I mean, that's the whole point of .NET !
... well, welcome to hell :)
...), 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 ?
.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 !
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
________________
Intelligence shared is intelligence squared.
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.
what are you talking about?
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..
History matters..
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.
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.)
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
Gates: Only if that is what'll sell! We've never done a piece of software unless we thought it would sell. That's why everything we do in software ... it's really amazing: We do it because we think that's what customers want. That's why we do what we do.
Bill Gates and u$oft thought that Microsoft Bob(TM) and that paper clip thingie would sell? And that consumers wanted it? WTF is with that?
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
-- I love the smell of Blue Screens in the morning.
Doesn't the world hate the U.S. enough as it is? Why are we trying to force Windows on more of the third world?
Use Java (with JFC/Swing).
:D
Great i8n support and runs anywhere (even on Windows XP)
I thought it described "goblazing windows"
I was trying to figure out if that was some sort of new windowmanager or a theme... now I see that I'm just retarded.
There are some odd things afoot now, in the Villa Straylight.
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.