In this blog, we will learn about the Internationalization and Localization support in Progress Rollbase. These are basic enterprise features required by any software application aspiring to make a mark in the Global Market. We have come a long way in the past year and have tremendously improved these aspects in the platform. Let’s have a look at our achievements.
What is Internationalization & Localization?
Internationalization, commonly known as I18N, is the process of making code ready so that it can be localized to a specific region and language.
Localization, commonly known as L10N, is the process of adapting the application content to meet the language, cultural and other requirements of a specific target market.
Basically, Internationalization is what coders do to have an application ready for the content changes that localizers need to implement. Some of the implementation aspects are translation, style changes etc.
What makes an Application I18N & L10N compliant?
There are many articles out there that talk about the best practices an application developer should follow to ensure I18N and L10N compliance. One of my favorites on the subject is the I18N checklist article that details out pretty much everything.
Let’s now have a look at what all we improved in the platform to make it I18N and L10N compliant.
Externalize all translatable content
In other words, this means “Take the text out of the code and place in resource files”. This is an essential requirement for a properly I18N application. Separating the translatable text from the code will avoid code duplication, will let localizers and developers work on updates simultaneously and remove the possibility of damaging code during translation. It also means that you are keeping the presentation and business logic separate so that the translatable items are separate from the view. It is our recommendation to use String Tokens whenever necessary instead of static texts in your templates as they provide localization advantage as well.
Avoid String concatenation
Concatenation only works when your content is written or a specific language. Avoid constructing strings through concatenation as this makes translation hard – even impossible in certain cases. To avoid this problem, we use named variables which can be moved around based on the translation. Linguists will be able to move the variable as necessary.
Avoid using a variable in more than one context
As much as possible, we do not use a noun as a parameter in a sentence and void reusing strings in more than one context as it makes translators job very difficult.
Unicode String handling
An I18N application uses Unicode for all strings and text handling. This applies to static as well as dynamic text. Dynamic text can be the ones that are used in communication between application and database. We also ensure that the characters don’t get corrupt during any of these routes.
Externalize all styles and formatting
We always use external style sheets to define the styles for the web application. This helps in having different styles for different languages. Any emphasis on the styles such as “strong’, “bold”, “italic” of the text are externalized so that the linguists can decide to translate them appropriately.
Use system functions for date/time, numeric & currency formatting
Date/time and numeric formatting differ even between the regions that speak the same language. So, these formatting should always use the system locale formatting. When it comes to currency we realized that we only had a limited set of currency formats supported in the platform. We then decided to expand and offer a richer set of currency formats that could cater to Global Markets. More on the currency format support is covered later in this blog.
We have moved on to a New user interface based on Kendo UI that solves overflow and text wrap issues. We also use relative’s sizes wherever appropriate. This interface offers in-built localization support for widgets such as date picker, calendar etc.
These changes improved the platform’s capability to be Localized easily. But, we decided to take it further by packing the platform with some more exciting features.
Out of the box language packs
The platform comes in packed with language support for some of the major European languages i.e. German, Dutch, Spanish, Portuguese, French. We are adding support for Arabic and Greek in our upcoming releases in addition to other prospective language packs such as Hebrew in the pipeline. These language packs are certified by external and internal linguistic experts and come with the product.
The platform also provides configuring your own language pack. This is only possible in the Private Cloud version of the product. Refer the official documentation on Adding support for other languages in Private Cloud & Translating applications.
Date/Time, Number Formats – Localization Settings
We now offer exhaustive list of Date/Time & Number formats per locale for the selected language. The platform internally uses the famous ICU4J library that conforms to ICU standards. ICU abbreviates to International Components for Unicode, is a mature, widely used set of C/C++ and Java libraries providing Unicode and Globalization support for software applications.
The localization settings can be configured at a tenant level and would be immediately applicable across the tenant for all its users. The platform also lets users configure their own localization settings for their language that then overrides the tenant level settings.
Some references to our online documentation on the localization settings:
- Configuring Date and Date/Time field formats
- Configuring Integer and Decimal field formats
- My Localization Settings page
As mentioned earlier, we vastly enhanced the currency formats support in the platform. The platform has out of the box support for 80+ currency formats. These formats cover the major currency formats such as dollar, euro, pound, rupee, peso, won, yen, ruble, dinar etc. Please refer to our online documentation for everything on Currency formats.
Right to Left (RTL) Support
One of the major milestones we have achieved recently is complete support for Right to Left (RTL) rendering of the UI components. This gives us a major advantage over other players and gain a foothold in the Arabic, Hebrew and other RTL markets. With this support, we also added out of the box Arabic support in v4.3. This setting can be configured on a per Application basis giving the administrator a better control over things.
We have other blogs covering various aspects of RTL support such as RTL support in Rollbase – Templates and Reports.
Adding new language packs is easier than before
Over time the language resource entries have grown to a huge number. This is primarily because the application is growing in terms of the feature set. But, we need to translate all these resources whenever we plan to add a new language pack and it takes a tremendous effort and time to do so. In most cases, the end user experience is all that matters and we needed a way to quickly identify the resources that fall under this area. Once identified, these resources are a smaller subset of the lot and can be easily and quickly translated to enable new language packs. So, we took a major initiative in v4.3 and did the clear segregation. To know more, please go through our community post on Rollbase v4.3 – Language Resource File Changes.
Language support for API
In our upcoming releases, we plan to add language support for all our API’s. More on this soon.
To conclude, we looked at major reforms we brought in into the platform to enable complete I18N and L10N compliant system. We also looked at the out of the box language packs that come for FREE. Hope, you enjoyed reading this article.