I’ve been enamored of the Eclipse Babel project for a while now so I’m very pleased to have a guest post on Babel by Benoit Nachawati. Benoit recently joined the JRules Rule Studio team. We are currently experimenting with using an internal Babel Server to streamline interactions between developers, the localization team, QA and the build team. Benoit discusses how we succeeded in installing Babel on an in-house LAMP server, uploading all the translated strings for Rule Studio and connecting Babel to our Subversion code repository.

You like Babel Fish? You’ll Love Babel!

By Benoit Nachawati

Localization has always been a challenge for software companies — creating costly overhead due to the interactions between different entities of the company: developers, configuration management, QA, documentation and translators.

On the other hand, addressing the local market with a localized version of your software will give you a great advantage, especially when your target is not tech users but business users. Those people just want to use your software in their native language. Hence our current interest in the Eclipse Babel project!

So, what is Babel?

Babel is an Eclipse project dedicated to supporting translation of Eclipse projects into different locales. Babel already offers three tools to help translation of Eclipse projects:

• Babel Message Editor (Eclipse plugin)
  This plugin is developer oriented and it provides an editor to edit Java resources bundles to produce languages files for the program under development.

• Babel Runtime Translation Editor (Eclipse plugin)
  This plugin is end-user oriented and it provides an editor to translate what is visible (context sensitive) on the screen at runtime.
• Babel Translation Server
  It provides a web based interface to enter and edit translations.
  It contains all strings to be translated for a specific project and version. You choose your language and enter the translated value for strings.

  It can then generate the Eclipse language packs required to localize your software.

In this article, I’ll focus on the Babel Translation Server.

Why use Babel?

Babel Translation Server can be seen as a collaborative platform. It provides a unique entry point to allow users to make and share translations. Some of the key features which make Babel very attractive are:

• Simple web based interface
• Maintain project version
• Maintain history of translation
• Easily start a new localized version of your software (you just need to add the locale)
• Build framework to create Eclipse plugin fragments required for localization

Here are a few screenshots of the Babel interface:

Babel Home Page

Babel Translate Page

Babel Map Files Addition Page

If you don’t have a well defined process for localization in your company, Babel could provide a nice starting point for defining the collaboration required to build localized software. Of course, everything is not perfect, Babel is still in its incubation phase. In particular Babel could benefit from some additional GUI to ease its usage and make it more accessible. For example:

• Upload already existing translations for different locales
• Upload a single properties file - whether localized or not
• Generate NL packs for a specific project-version-language

Babel Workflow

The Babel workflow can be divided into three steps:

Scan (Inputs)

The goal of this step is to populate the database with properties files path and its key-value pairs.
Babel uses PDE Build map files to perform this task: they are uploaded into the Babel database and will be parsed to retrieve properties files.

The map file processor will checkout each map file entry to a temporary folder and looks for properties files. It will upload (or update) in the database all properties file paths as well as the key-value pairs for each propert file. Unfortunately, Babel doesn’t currently handle the upload of already existing translations for a specific locale.

Translate

Users just need to login into the Babel server and access the translation page. From this page, one can provide translation for each string. The GUI is divided in three parts:

• The languages, projects, version and files selection area
• The properties file content area (where you select the string to translate)
• The translation area (where you edit / add the translation)

Deploy (Output)

The goal of this step is to generate NL packs per language. Currently, Babel provides a script to generate an Eclipse Update Site: it creates one feature per language which contains all plugin fragments. Only strings that are translated will be included. Afterwards, you’ll just need to publish this Update Site on your web server or into a local directory.

Installing a Babel Server

The installation process is well described from the Babel Project wiki page at
http://wiki.eclipse.org/Babel_/_Server_Tool_Development_Process. I’ll just make three comments about the installation process:

1. Install PHP version >= 5.2.0 as Babel is using JSON functions
2. Install MySQL version >= 5.0.32 or version >= 5.1.14 to be able to use IF EXISTS clause for DROP TRIGGER statement
3. Modify the Babel sql script - namely babel-setup.sql - to prevent an error from occurring for a trigger that does not exist:
   Replace: DROP TRIGGER `ins_version`;
   by: DROP TRIGGER IF EXISTS `ins_version`;

My repository is under SVN, how do I integrate it with Babel?

For now, Babel only works with CVS (SVN support is a planned feature). Luckily enough, the CVS support from the map file processor script is just a matter of calling CVS for a checkout with the right CVS repository location. Here is the corresponding line of code from process_map_files.php file for CVS support:

$command = "cvs -d " . $aStuff['cvsroot'] . " co " . $tagstring . $aElements[1];

One would naturally expect to just change this line by the appropriate SVN support like for example:

$command = "svn co --username " . $svnusername . " --password " . $svnpassword . "  " . $svnURL;

However, Apache does not change its user properly, so svn command cannot be properly run as apache. To overcome this issue, we will use the sudo command to get more privileges. To do so, we first need to update the /etc/sudoers file by:

• Adding the following line: apache ALL=NOPASSWD:/usr/bin/svn
• Commenting the following line (if available): #Defaults requiretty

Ultimately, the SVN checkout will be done by the following line of code:

$command = "sudo svn co --username " . $svnusername . " --password " . $svnpassword . "  " . $svnURL;

SVN support not only means just changing the cvs command by the svn command but also provide a correct SVN location (url) to checkout from.
From the process_map_files.php file this just means providing your own parseLocation($in_string) function to update the way the map file entries are handled to complying with your map file entry format.

Posted by Daniel Selman in Software Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.