Localizing Alfresco for Arabic – Part 1 ( The easy part )

December 13, 2018 | Posted By Paul Clinton

What is localization

When talking about localization, we need to understand what it really means. Localization is the adaptation of a product or service to meet the needs of a particular language, culture or desired population’s “look-and-feel.” Localization has many elements to it like format of dates, currency symbol, financial configurations etc but the most important element is language localization – viz presenting the user interface in the target language/dialect.

Language Localization

For all languages there are two elements to support this sort of localization.

• Externalization of literals and other displayed texts – so that we can replace them by equivalent text in the target language.
• Ability to capture/display content in the target language.

Localization of content is generally solved by ensuring that the application ( including the way strings are stored ) uses one of the standard Unicode formats . In this case as long as keyboards can generate the Unicode symbols related to the language the characters displayed and captured are the letters of that language.

Localization in Alfresco

Alfresco supports this to a very large degree. All the alfresco literals are externalized and they can be replaced by target language equivalents, by packaging the language specific property files together. Knowing that Arabic is a non-Latin character, it should be encoded in .properties file by using Unicode escape characters (e.g. \uHHHH where HHHH is a hexadecimal index of the character in the Unicode character set).

However there are large number of such literals, there were about 100 property files and files having approximately 1000 words. Adding to this, the product provides upgrades on a continuous basis, which would have to be translated again. Alfresco uses crowdin as a means of collaborative translations and has maintained multiple language translations in this fashion. I did find an Arabic translation pack which was not maintained – so had gone out of sync with the latest release.

My customer wanted to have the translation maintained privately until it had matured sufficiently. So I had to work with scripts to accelerate the process. The language expertise was being provided by the customer, so we devised a 5 step process.

I built a formula that would convert all the literals from Arabic to Unicode format (UTF-16). The image below shows the end result.

I then did build a script that would generate/update the language specific property file from the google sheet. Taking only the changes approved by the customer. After generating these property files, I had to rename them to include the language suffix. After which I had to package them in jar.

At the end we had a language translated page which looked like this

As we all know that Arabic text runs from right to left (RTL). But, numbers and Latin texts are written from left to right (LTR). This leads to a mixed direction of text segments. Translating Share to Arabic solves only a part of the problem. The main challenge here was to convert Share to RTL(Right-to-Left) format. Which I will be talking about in another post.