Previewing Morfik’s support for internationalization

“They don’t call it the World Wide Web for nothing.  A single click can take you to a site on another continent and a business can attract customers from hundreds of countries.” Jakob Nielsen

In this blog we are going to have a look at the practical aspects of implementing multiple language support on the website you have developed with Morfik. We will preview some of the new features currently in development which are designed to make the process of localization easier.

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 blog post.

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 anotherThe 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 formSince 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.

Seeing is believing

While support for multiple languages in Morfik is still a work in progress, we have put together a little demonstration which shows how the Security Package can work with different languages. You can log in using the following credentials:

user: admin
password: admin

We hope it gives you a useful insight into how Morfik supports internationalization and localization.

7 Responses to “Previewing Morfik’s support for internationalization”

October 23rd, 2017

Grant,

Morfik applications use UTF-8 by default which is capable of displaying any language. That means you don’t have to worry about different encodings no matter what language you are using.

I think in some cases it is only worth while setting your content up for the bigger languages like Chinese. You also need to be aware of the fact that you will need a different encoding for your pages for some languages.

Tassos says:

Very welcome additions, but for me they seem like putting the coach before the horse… The most needed capability that keeps me and many other from using Morfik for 2 years now, is the incapability to create pdf reports in most of charsets except English one.
What is the use for multi language sites if nobody can take a print in Cyrillic, Greek, Hebrew, Arabic, Chinese etc. This is much needed in multination Europe.

Please, put some effort in closing this very import hole: Creating Unicode PDF. ****** Internationalization = Full Unicode Capability ******

Regards

Marius says:

@Sergey Kostinsky:

Hi,

Yes, the load speed is much much better that when I checked it the first time.

Still not 2 seconds as with Mauricio, but much faster than what it was.

Regards

@Marius:

From my place it takes less the 2 seconds to change languages. I’ll admit I’m using an 8Mbps cable connection, though.

Sergey Kostinsky Sergey Kostinsky says:

Marius,

In general, you should not see any difference between the current version of the website and the one with multiple languages support enabled. There is little processing involved, and only the data relevant to the current language is getting transmitted. And if you don’t provide any additional languages, there is literally zero overhead.

I feel the speed issue is most likely due to the demo app running on an Amazon EC2 server which can be occassionaly not as responsive. I have moved the demo to our main server farm which should run faster. Could you please give it another try and let us know if it’s any better?

UPD: looks like it wasn’t EC2, it was me! I have deployed it without gzip compression enabled.

Marius says:

Hi,

Very interesting, and I’m sure this will be used by a lot of people. I just wonder if this wont increase the time it takes Morfik Web Sites to load, even more. I went to the demo page, and to switch from English to another language took nearly a minute to load the site again.

I am using a 4Meg ADSL line, which currently in my part of the world is basically the top DSL line you can get. Somewhere I read that if you’re site is not loaded within 7 seconds, the person browsing it will be gone, and I tend to agree with that. (This obviously excludes the people that have to use your site anyway Intranet applications). [NB: I realize that this is just a demo, and I cant really form an opinion as there are just to many variables in play. ]

So, if the Morfik site is a public facing site, and you plan to attract people in this area of the world, then good luck to us. Maybe in the rest of the world the speed of the internet is way faster than over here, but on a 4Meg line a load speed of 1 minute is just not good enough.

Be that as it may, congrats on this development, I know from the forums that a lot people will be made happy with this.

Regards
Marius

Leave a Reply

Fields marked by an asterisk (*) are required.