Using a Multilingual Software Package?

In today’s economy, eventually a U.S. based company will be required to expand its reach and enter into global markets.  This is especially true now that the dollar is weak.  Foreign companies can afford to purchase U.S. goods and services now more than ever.

Running a multilingual database software package where users from different countries need to access the same database presents unique challenges.  First off, the users of the database have to get used to the idea that data entered into the database will be in different languages.  Users could be using Spanish, French and German keyboards to input data.

When looking at multiple language support for a software product, the areas can be broken down into 4 broad categories:
1. Labels and phrases
2. Code or masterfile type data
3. Error messages and system messages
4. Formatting, input and output of dates & currency

Labels and phrases are typically extracted out of the software and placed into what is called a “resource” file.  This is a special file that, when compiled into a DLL, provides for very fast lookup of the labels.  This results in faster screen painting than, say, reading the labels from a data table on the database.  The resource file contains all of the translations for the languages that the software product supports.

Code, or masterfile type data, presents a difficult challenge.  A common code table in most software products is a Group table of some sort.  In our own product, we group work orders by what we call an “Equipment Group”.  When users from various languages use the system, they expect to see a group description in their own language so they can read it.  But, we don’t want to create multiple records for the same group number, we just want to show the description of the group in different languages.  For our product, we solved this problem by creating Views of the data.  The View is a database object that allows the developer to add logic to the results.  Hence, we use code in our View object for the Equipment Group so that we know which language translation to pull and display for the connected user.  This works because the MS SQL database connection string contains an identifier named @@Language, and we can use that data to know which description to return to the client.

Error messages can come from the software application itself, or from the PC operating system, or from the SQL database.  The operating system handles itself.  Users can specify their language of choice via their Regional Settings.  Or, a specific language version of the operating system (Windows) can be loaded.  The SQL database also handles itself via the same @@Language setting that was discussed in the previous paragraph.  As for the software application, error messages are really treated no differently than labels.  They are compiled into a resource DLL for fast lookup and display to the user.

Date formatting becomes a challenge if the software application was not originally designed for international dates.  In our own product, we had to search the entire product source code and find all instances where dates were being used in the code.  We then changed the code so that it uses whatever the user has specified in the Regional Settings control panel applet.  And, we had to make sure that the date could be entered in that format as well as displayed in that format.  We also did the same transformation for currency fields.  The currency symbol, thousands separator and fractional separator (decimal point) are now pulled from the Regional Settings on the user’s profile.

There is quite a bit to consider when preparing a software package for multilingual usage.  I’ve really only scratched the surface in this article.  Before you consider taking your business into a multilingual environment, be sure your critical software packages and databases are up to the task. 

Contact us for more details about this article or our CrossForm Multilingual solution.