What are the steps involved in internationalization

When Morfik decided to implement support for Internationalization and localization into the Morfik development environment and Framework, a number of major factors were taken 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 re-engineer 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.

Internationalization with Morfik

Morfik has implemented 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 in the future!

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 is discussed here.

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 control 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 controls 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));

What Happens With Resource Strings

Resource strings will be included in the language specific files in the _<Project>Languages subdirectory when Generate Language Data is checked on the Compiler tab of Project Options. Additional language files can then be created to perform the internationalization. For a discussion of how to implement static text localization using external files, refer to this article.

Related Topics