- Translating an Application
- Application Translation Methods
- Other Factors to Consider
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Application Translation Methods
Contrary to popular belief, there are multiple methods of creating multilingual applications. The most basic is to create completely separate applications for each language. The most common option is to create a single application that uses translation strings for the various deployment languages. Let's take a look at both options to see which one will work best for you.
Writing Multiple Applications
Some of you are probably squirming in your seat and thinking, "Writing multiple applications is a stupid thing to do." However, you should give it serious thought. Here are some criteria that make this option perfectly acceptable:
The application contains a small number of screens and reports. Why take more than twice as long to create a form or report when it will be much quicker to create it for each deployment language?
One of the deployment languages is a language that reads right-to-left or bottom-to-top. Oracle Developer is capable of handling multilingual applications, but this dramatically changes the application design.
Applications deployed in only two languages. Much more than that, and application administration becomes a nightmare.
Applications that are fully tested before being deployed. You don't want to have to fix a lot of bugs more than once. Therefore, test the application thoroughly before deploying it.
If you decide that this method of creating multilingual applications is right for you, there are some features of Oracle Developer that you should take advantage of. The most useful are database stored procedures and triggers. To minimize application rewrite, you will want as much of the application logic to be stored at the database level as possible. This allows bugs or defects to be fixed once for all of the applications.
Creating a Single Multilingual Application
When you talk about multilingual applications, this is what most developers think about. It is a shame, too, because I have seen many different applications done this way when the previous method would have worked better. The problem with this method of development is that you need to have the infrastructure thought out before application coding begins. Not only are you responsible for translations of strings, but not all translations are the same size. Although the text field prompt may be eight characters in English, it could be 25 in German or French.
If you have followed the proper software development methodology, you have a distinct advantage. You can look at all the static text strings with translations, and can determine how much infrastructure you will need. If all your static text prompts are within several characters, you only need to keep track of the strings and be a bit liberal with spacing between database fields. If there are larger differences, you have to be a bit more creative.
Oracle Developer is tightly coupled with the Oracle database. Therefore, I suggest using it to help build your multilingual application. Table 1 can be used to keep track of your message strings.
Table 1 MASTER_STRING Table
|
Column |
Data Type |
|
STRING_ID |
NUMBER |
|
ENGLISH_STRING |
VARCHAR2(100) |
The STRING_ID serves as a primary key, whereas ENGLISH_STRING is the actual text used in the application. You want to consolidate as many strings as possible. For instance, the prompt "Last name" may be used multiple times throughout the application. However, it needs to appear only once in this table. You also need a TRANSLATION table, as shown in Table 2.
Table 2 TRANSLATION Table
|
Column |
Data Type |
|
LANGUAGE_ID |
CHAR(1) |
|
STRING_ID |
NUMBER |
|
STRING_TEXT |
VARCHAR2(100) |
|
X_OFFSET |
NUMBER |
|
Y_OFFSET |
NUMBER |
The LANGUAGE_ID and STRING_ID columns can be used together to form the primary key. For simplicity, I just used a single character to represent the language in the LANGUAGE_ID field. You could also create a lookup table to spell out the languages. The STRING_TEXT column holds the translated text. X_OFFSET and Y_OFFSET are used to control the spacing for your translated text. In the case of a prompt that is longer in French than in English, you need to subtract the X_OFFSET value from the x position of the prompt text.
When the application is invoked, you could have some sort of mechanism that sets a global language flag for the user. As each form is invoked, you could have a PRE-FORM trigger that selects the correct text for static text and updates the form accordingly.
As you can see, this is a much more complicated method of multilingual application development than creating two forms. However, sometimes you don't have a choice.