The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Internationalize the app!

I must internationalize my application, to... languages other than English. I am a bit unclear about this all. My app currently targets Win98 (no unicows.dll, no unicode). How does everything actually work? Do I simply go to the dialog editor in VC6 and create new dialogs and text listed under each of the languages I desire? How does all this work in tricky situations, for example where I use French for the language, but still need to write minor things, such as the company name, in English on some dialogs? In essence, I am curious about some more details on how Unicode languages in the resources are managed together with English.
Monday, January 03, 2005
Monday, January 03, 2005
I think internationalization is one of those things that tends to be dismissed as a simple string-replacement exercise but in reality can be a huge project with endless little ins and outs.

In our case I think to perfectly internationalize our app would be a gigantic project. When I say 'perfectly' I mean things like putting the correct accent characters over the 'e', etc. I am told companies like MasterCard do NOT go to those lengths though. To some French users though not doing so is a slap in the face. (I am really tempted to make a snotty joke here but I was so badly flamed last time I did that... I think not today).

These comments apply to Frenchifying an English app. If you're talking about different alphabets and so on, heaven help you.
NetFreak Send private email
Tuesday, January 04, 2005
or the older version

Plan on spending *several* days to weeks reading those books. There is no shortcut.
Tuesday, January 04, 2005
Oops!  I read VB6 not VC6...  My mistake.
Tuesday, January 04, 2005
Then there's the result of not internationalising.

Decimal bloody points. If you use decimal strings watch out for your libraries paying attention to the locality and helpfully breaking code that worked at home. (Text based data files do get passed around the world).

Hint: Test your app with your PC's location set to Germany.

You may want to fix (or allow the user to fix) the decimal point global e.g:

  DecimalSeparator = '.' ;  // Let them eat points!
Tuesday, January 04, 2005
Thanks for the info. Now what if I ask for more concrete details on how to do this, but this time easing the requirement:
* Easy languages only. Italian, Spanish & French.
* No currencies or other funny stuff in my app.
* Only 6 screens of text in my app. The only requirement I have is to stick my company name & details, in English, mixed with the foreign language text.
Tuesday, January 04, 2005
JD, the books I referred to will point you to API calls that will get the local settings.

Control Panel, Regional Settings. First tab. What API calls get that sort of thing? Read the book.

>Easy languages only. Italian, Spanish & French.
Find someone *fluent* in those languages. Or else your screens will be full of passages that come across as "bubbly makes to the several direction" (which was actually found on some dark-room (photographic) equipment in the late 70s.

Then read up on "what is a resource DLL" followed by "how do I use a resource DLL." The proceeding sentence is the key to internationalization. Everything you want to know about dealing with European languages is in that sentence.

In this case, RTFM is the appropriate response. There are too many "gotchas" to wing it alone.

Do you actually have PCs running in those languages? How does your installer handle different code pages and languages? If you really want to be surprised, you will install your code, only to realize that half the menu is in English and the rest in the native language.

>Easy languages...
They are ALL easy. Children everywhere learn them every day.
Tuesday, January 04, 2005
To properly internationalise, regardless of platform, one must separate textual elements from their actual textual value.  Instead of having a label on a form with a fixed text you have a code which you pick up at runtime.

The problem then comes down to two main things, relative word length and word order.  Some languages have a greater average word length than English, German for example, others have entirely different word orders and text direction, Arabic say.

Having the text separate means you can send out your strings for translation by someone else, you can safely outsource it without breaking the application.  However there are always limitations because of available space and sometimes you have to refashion a dialog just to make it comprehensible to the user.

The other elements of internationalisation, decimal character, thousands separator, currency symbols, data entry and so on should be inherited correctly by the widgets you're using already, if they aren't you need a better widget set.
Simon Lucy Send private email
Wednesday, January 05, 2005
I am experiencing similar stuff with my application right now. Could I get this clear... why use a satellite resource DLL intead of just have different resources with different languages inside the existing application? I was told using satellite dlls for other languages is the way to do it, but it is not suitable for us as our executable must be a single file with no external dependencies.

Wednesday, January 05, 2005
"The other elements of internationalisation..."

One of the many other huge elements in OUR case anyway is places where data contains language-specific values. This is particularly a problem if the code relies on those values. For example our Orders table contains a status field that says things like 'Posted', 'Approved', etc. and programs look for those values. Of course fixing this in isolation is no big deal, but changing everywhere that our databases contain something translatable is another matter.
NetFreak Send private email
Wednesday, January 05, 2005
Does anyone have recommendation on how we can test our internationalized app? For a test I made some of the resources in French, but I can't find where (in XP) I can change Windows to be French based such that it defaults to these resources.

Thursday, January 06, 2005
Get VMWare and install Windows. During the install, choose French.
Wayne Send private email
Thursday, January 06, 2005
You don't mention currencies, only 'Easy languages only. Italian, Spanish & French.'

Just remember that some currencies are 10,000 : 1US$ so you must deal with / store these differences.  For example, one app I worked with stored values as decimal(11, 2), plenty until we went to Vietnamese Dong.

Thursday, January 06, 2005
It definitely simplifies things for testing if you have a known set of languages that must be supported rather than proclaiming that it must support all languages.

This is a great resource, especially for Windows development.

And has an excellent collection of resources.
Jeremy Send private email
Monday, January 10, 2005
You can use specialize tools to do localization job. We use Lingobit Localizer ( for that and it perfectly suit our needs. With it you don't need to hassle with resource files or source code, it directly translate binary executable file. We found this solution very robust and did not have any problem with it. Lingobit also has additional tools that help translate application such as support for glossary, validation (find inconsistency in translation such as incorrectly translated format string) and so on.

Also similar tool is produced by Alchemy (, but it is a bit pricey and user interface is awkward.
Kumar Send private email
Tuesday, January 11, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz