About 10 years ago I attended some vendor training on how to program and extend their particular office automation suite. One of the things that I took away from the training was how they designed their system to adapt to many languages. Recently the method came to mind. As I was thinking about the possibilities of using this method in my own programs, I pondered over it’s limitations and what other methods might be used.
After some thought I have considered three different approaches to allowing a program to support multiple languages:
- Text File (One file per language)
- All languages stored in executable
- One executable per language
Before covering the different approaches, the main thing that each approach hinges on is the storage of all output messages in an array. Instead of having a line like this:
PRINT #3,"File Not Found"
You would have something like this:
PRINT #3,messay_array$(35)
Since the output messages are not hard coded, the array can be changed to suit the language. For every possible output message you would have to put an entry in the array. Granted this will make reading and maintaining the source code more difficult, but it does make supporting different languages so easy.
Now the difference in each approach is how to store the different arrays for each language. Each method has some pluses and minuses and each have to taken into consideration for each programs needs.
The first method mentioned, Text File, is the method that I learned in the training class. The developers created a text file, in each language, of all of the possible messages. Each file would be given a different name. The program would expect a certain file name. The current language would be renamed to that file name. When the program was executed, the program would read the file and load messages from the file into the array.
The problem with this method is the overhead of reading in the file. If you have a program that may be expected many times in a single session, the speed of the program will suffer from reading in the language file each time. If you are writing an application that once executed will run for a while, such as a word processor or spreadsheet.
One advantage of having that messages in a text file is that new languages can be added to the program, with no change to the executable.
One way of getting around the overhead of reading in a text file is to store all of the messages of all the languages in the executable and have a command line option or environment variable determine which langauge is choosen. With SuperBasic the different messages would be stored in DATA statements. When the determination of which language is made, the program would read select which DATA statements to read into the array.
There are two disadvantages to this approach. First, the space needed for each languages may add significantly to the size of the executable. Secondly, if a new language is needed to be added, then the program has to be recompiled.
Another approach is to create the program the same way as the previous approach, but use conditional compilation to create an executable for each language. This will cut down on the amount of space needed for the message data, but it does mean that a different executable would have to be distributed for each language. If you included each language executable on the distribution media, then this approach may work.
Given the wide distribution of QL users and the many different languages, having a localized version of an application may make an application more accepted in the community. The difficult part will be in translating the messages into different languages. If the Text File approach is used, then users could translate the messages and distribute the new language file to other users. I believe something like this has been done with various dictionary files.