What are the steps involved in internationalization?

When looking at different ways of adding support for Internationalization and Localization to Morfik, there were a number of major factors we took into consideration:

  • Localization of a website is an ongoing process, not a single act. The content of a website may be updated frequently, and it should be possible for it to be continually updated in different languages.
  • With a significant number of projects already developed with Morfik, it should be possible to add multiple language support to an existing project without the need to reengineer it.
  • The actual process of translation is not usually carried out by those who have developed the web application itself, thus there should be an easy way to organize the original/translated text exchange.

We have come up with a design method that we believe will make the creation and maintenance of websites supporting multiple languages a straightforward process that can be easily executed. As always, we are going to be the first users of our own technology, so you can expect to see morfik.com in various languages!

Supporting multiple languages on your website consists of two parts:

  1. Internationalization – the process of designing your website in such a way as to make localization possible, and
  2. Localization – the actual process of adapting your site to a specific region or language.

Let’s have a look at what it means in practice, and how you will go about making it happen on your website. There are two main areas that have to be considered: language and culture. Language

Translating the text that appears on your website is the most important part of the localization process. In many cases the bulk of your effort will be spent on this task.

The text that is presented to your users can come from a number of different sources:

  • It can be defined at design-time, e.g. caption in TextLabel control
  • It can be a string constant inside the code. This includes exception messages generated by the Morfik Framework
  • Text can be retrieved from the Database
  • It can be a result of a third party web-method execution

Database internationalization is a major topic in itself and will be reviewed in a separate article.


Design-time text

In this area, we were able to come up with a solution that requires no changes at all to the way you are currently defining the text on your forms. In other words you don’t have to do anything, and that’s always good news!

However one thing you need to be aware of is that when text gets translated into a different language the amount of space it takes up onscreen will most likely change.

This has to be taken into consideration when designing your user interface, to ensure your site looks good when displayed in any language. Morfik’s Plastic Layout is of great help here, but there are a few cases that might require special treatment:

  • When several TextLabel controls are placed one after another - The login bar of the Morfik Security Package is a good example of this. Since the width of the TextLabel depends on the text displayed, fixed width cannot be used in this instance, and reserving a space to allow for longer captions results in gaps between labels when shorter text is used. The solution is to use Flow Layout mode for the container where labels are being placed. In this mode the position and size of controls inside a container is not fixed, but instead depends on the actual content of controls.
  • When using TextLabel and TextEdit in the entry form - Since having entry fields misaligned doesn’t look good, you might want to consider placing TextEdit under the descriptive label rather than next to it.

String constants inside the code

String constants include both browser and server-side constants that are used to generate various messages or to display text at runtime. Once again, our aim was to keep the code looking as ’normal’ as possible while retaining its capability to work with multiple languages.

Overall, there is very little you need to worry about, but here are a few simple rules you should follow to ensure your application can be localized:

  • All text messages that are language-specific should be declared as string constants rather than string literals. So, instead of:
      ShowMessage('Operation successful');

use the following:

      ResourceString
         cOperationSuccessfulMsg = 'Operation successful';
      .
      .
      ShowMessage(cOperationSuccessfulMsg);

You may have noticed ResourceString used in place of Const – this is the new reserved word we have introduced to indicate that string constants are language-specific.

  • Avoid breaking text messages into parts – it makes the job of the translator harder, and sometimes it can even make it impossible to properly translate the message. Instead of:
      ShowMessage('Username ' + S + 'already exists')

use the Format function as per this example:

      ResourceString
         cUserNameAlreadyExistsMsg = 'Username {0} already exists';
      .
      .
      ShowMessage(Format(cUserNameAlreadyExistsMsg, S));

Localization of Text

Now that you have done all the work of ensuring your website can be localized, it is time to have a look at how the actual translation will be done. We have introduced a new option to the Options | Compiler dialog

If the new option “Generate Language Data” is enabled, every time the project is compiled, Morfik will create a subfolder called <ProjectName>Languages in your project folder and will generate the <ProjectName>.txt file within this folder . The file will contain a simple list of strings in a Name=Value format. You can then send it to a translator, who can translate the Value part of each line. Once the translation has been done and you have received the localized version of your file, you then place it into the same folder under the name <ProjectName>_lng.txt – where “lng” is a language identifier. It is recommended that you use ISO 639-1 codes to identify the language. For example you would provide the French version in WebSite_fr.txt and the Spanish version in WebSite_es.txt.

And that’s all you need to do – the localization does not require recompiling of your application – all you have to do is copy your file with the translated text.

There is no limit to the number of language files that can be created; we have made sure that we keep overheads related to multiple language support to the minimum. Also, the client only needs to download the text in the language he is using, so there is no downside to having multiple translations.

Another thing worth mentioning is that you can have multiple files for the same language; they will be merged at runtime. This allows for out of the box packages that support multiple languages, and we are going to make use of this capability in our future package releases.

In one of our future blogs we will discuss the use of online services as a fast and inexpensive way of getting translation done, and will share our experiences in using such services.

Third-party web methods

Since you cannot control the messages returned by third-party code, there may be a need to place a wrapper code around the calls, and provide the translation based on the status code, when possible, or based on the actual message text.

Locale Data

While having the content of your website available in different languages is a major step, there are a few more things to consider. Different regions may have different ways of displaying the same date, or may even use different calendars. All this has to be taken into consideration if you want to have a truly international website. To help you with this task we are going to provide a new module – SystemGlobalization – both on the server and on the browser side. It will contain a comprehensive set of tools needed to localize your application.

Letting users know your website speaks their language

Once you have done all the hard work of supporting different languages on your website, you have to let your users know that they can select another language. To save you time we are going to provide ready-to-use widgets to allow users to select their language, and for their language of choice to be remembered for future visits.

Of course, you can implement your own language or region selector. The most commonly used methods for doing this on the web today are: displaying the name of the language in the language itself, displaying the name of the language in the current language, and using country flags or even the world map. There are a number of valid arguments against using flags as a way to represent language (a good review of the problem can be found in this blog post), so that method is probably best avoided.