Deliver superior customer experiences with an AI-driven platform for creating and deploying cognitive chatbots
Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile development
Automate UI, load and performance testing for web, desktop and mobile
A complete cloud platform for an app or your entire digital business
Detect and predict anomalies by automating machine learning to achieve higher asset uptime and maximized yield
Automate decision processes with a no-code business rules engine
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Personalize and optimize the customer experience across digital touchpoints
Build, protect and deploy apps across any platform and mobile device
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Progress Rollbase has greatly improved its accessibility and user experience with new Internationalization and Localization Support. Take a sneak peak at the enhancements.
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.
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.
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.
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.
Concatenation only works when your content is written for 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.
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.
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.
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 of the text, such as “strong," “bold,” and “italic,” are externalized so that the linguists can decide to translate them appropriately.
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 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.
The platform comes in packed with language support for some of the major European languages, i.e. German, Dutch, Spanish, Portuguese and French. We are adding support for Arabic and Greek in our upcoming releases and have 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.
We now offer an 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.
Some references to our online documentation on the localization settings:
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.
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, to help you enable RTL support in Rollbase for Templates and Reports.
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 learn more, please go through our community post on Rollbase v4.3 - Language Resource File Changes.
In our upcoming releases, we plan to add language support for all our APIs. 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 this article, and feel free to trial Rollbase for free and explore how it can help you rapidly develop and deploy your apps.
Manooj Murali is a Principal Software Engineer at Progress. He has been part of the Rollbase development team in Hyderabad for more than two years and has more than 8 years of experience overall in software development. He has led many feature developments like I18N, Marketplace, White-Labelling, JBOSS support, High Availability and more for Rollbase.
Copyright © 2018 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.