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.

Multi-language app

I have an application which MUST be a single executable, for various reasons. I want to provide multiple language resources for our the various countries using the app, but I am not sure how. Originally I imagined that I can simply add another string table for (e.g.) Chinese and the OS will select the correct string table at run-time, but I have been told this is not always workable. So... how do I do this?

Friday, September 24, 2004
I am straying out of ny comfort zone, however:

Borland Delphi / CBuilder can compile to a single .EXE and a demo shows multilingual capability with resource strings.

I stress I don't know whether this will stretch to Unicode or whatever you have in mind.
Friday, September 24, 2004
There are a few extra issues, particularly around handling dates, decimal symbols and other locale specific things. You should be able to query the operating system for the locale and hand of date validation and so on to the operating system also.
Matthew Lock Send private email
Friday, September 24, 2004
OK, but if i ignore dates and the such (not used in my app), and all i really have is text strings, then is it enough for me to put all the different languages as difference resource strings in my app?

Friday, September 24, 2004
Resources can be loaded by language id. Go here: and read Dr. International FAQ and articles. Book ref: "Developing International Software" by Dr. International.
Friday, September 24, 2004
This is what's called 'internationalization' or 'i18n', and it's a big topic... As Matthew Lock pointed out, there's more than just natural language string data you need to be able to switch by locale; dates, numbers, currency, all have locale specific formatting. Colours signify different things to different cultures. Icons that seem obvious to one culture may be meaningless to another. Internationalizing an application well, so that it can handle all of this correctly when localised, is not trivial.

If your application is sufficiently simple, though, you can get a long way for a little effort. Extracting all national language text into a message catalog and loading message catalogs according to locale is certainly the first step on the i18n path.

Most development environments these days will provide support for locale specific message catalogs and data formatting, at the very least. But really, this is just the starting point if you're going to do internationalization well.
Laurie Harper
Friday, September 24, 2004
Stupid question, but, does it have to be a single exe when it's sitting on the machine, or only when it's deployed.

If the latter, there are any number of .net solutions, but the most obvious would be an msi.
Aaron Send private email
Sunday, September 26, 2004
Pocket Excel uses (used? ...the project hasn't seen any real development since 1999 so far as I know)... ANYway, all internationalizable resources were compiled into a seperate DLL. At startup, the executable would load the "current" language's DLL and store the module handle in a global. From there, all resource loads just used that module handle.

Of course, the technique is Windows-specific, and you have to set up *all* of your resources in Unicode, but it works and doesn't require a whole lot of additional code.
Michael Falcon-Gates Send private email
Wednesday, September 29, 2004

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

Other recent topics Other recent topics
Powered by FogBugz