Managing static text through Language files

Static text in a Morfik application can be translated into any number of languages by a simple process. When a Morfik application is compiled, the Morfik compiler outputs a text file with all the static strings in the application that are intended for localization. This file can then be sent by the developer to a specialized translator so that the individual strings can be translated to the desired language.

Localization of Text

Once you have done all the work of ensuring your website can be localized, as described in the "What are the steps involved in internationalization?" topic, it is time to have a look at how the actual translation will be done.

A new option called “Generate Language Data” was introduced to the Options | Compiler dialog to this effect. If the new option 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 is complete and the localized version of your file is available, it can be placed into the same folder under the name lng_<ProjectName>.txt – where “lng” is a language identifier. You must use the ISO 639-1 codes to identify the language of a translation. For example you would provide the French version in fr_WebSite.txt and the Spanish version in es_WebSite.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. Read more...

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 provide a new module – SystemGlobalization – both on the server and on the browser side. It contains 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, so that method is probably best avoided.

Using the URL to Select a Language

To utilize the built-in support for localization, the desired language code needs to be passed as a parameter in the URL. The value for the language code is the same as the lng code used above and the complete parameter should be specified as lng=lng . For example, French would be specified as lng=fr and for Spanish lng=es.

The language code can be automatically sent as a parameter by setting the browser-side global variable currentlanguage to the desired language code. This could be saved using a cookie to preset the code the next time the browser returns to the site.

Related Topics