Babel / Server Tool Specification

The Planning Council liked the idea of the Babel wiki-like system (derived from Aptana's contribution) for the community to enter translations. The PC members suggested the following design for the inputs and outputs.

Inputs

There are two input mechanisms: a manual REST-based one and an automatic pde.build map-based one.

REST Inputs

The projects build scripts will send the properties files to the Babel server on each build. They will do this one file at a time, using a REST web-api. This api should be login protected and require a committer login. The body of the REST POST should be the properties file along with any other fields that are needed (probably the project and the plug-in). The Babel server will perform the merge as defined below.

MAP Inputs

The projects, using either a web form (manually) or a REST web-api (as part of their build scripts), sends the location of their pde.build map files to the Babel server.

Once a day (or at some other convenient interval), the Babel server scans for properties files as specified by the map file. Each properties file found is merged as if it were added by the REST input method above.

• Here is an example map file: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.releng/maps/jdtdebug.map?view=markup
• For example, the org.eclipse.debug.ui entry tells us which repository to find the plug-in
• Scanning that plug-in from that repository, we find, e.g., this properties file: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.debug.ui/plugin.properties?view=markup
• Etc.

Map files appear to be documented here: http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.pde.doc.user/guide/tasks/pde_packager.htm

Input Merge

1. For each key-value in the Babel database, check if the key exists in the input. If not, delete the key-value from the Babel database (saving it in the audit trail and history), of course.
2. For each key-value in the input, check if the key exists in the Babel database.
   1. If so, check if the value is the same.
      1. If so, no action.
      2. If not, replace the value and mark all translations as potentially incorrect.
   2. If not, add the key and value to the Babel database.

User Input

The basic user actions are:

1. Enter translations for strings
2. Rate entered translations
3. Find strings that need to be translated

Other actions that would be nice to support include:

1. From a menu, window, dialog, whatever in Eclipse, jump to the server tool to translate that exact string.

Phase I: Something Live As Soon As Possible

After logging into the Babel server with your Bugzilla account information you will be prompted to pick a language, a project and a version. All the translatable strings are show as a list with the last translation and time stamp. Selecting a string to translate show the English string an area to translate.

At anytime you can select a different language/project or version.

Phase II: Encourage Contributors

Our target user for this server-based tool is the casual language-expert contributor: someone who wants to help Eclipse projects by translating strings on a part-time, volunteer basis.

The UI will be changed to streamline the choice of a language/project. The current version of the project will be selected by default (with a way to change to previous version). The list of translatable strings will have editable text boxes next to them for very quick translation.

Translations will have a rating system as away to get feedback on the quality of both the translations and the translators.

To encourage pride in their work we will have a babel user page that will show details of how many strings they have translated, how those string have been rated. Also included will be their ranking with other translators by project, language, time and overall.

Every project info page will show the current state of translations for that project and link to the babel page for that project. Also we will show the ranking and activity of the project translations.

Outputs

The Planning Council would like the Babel project to build the language packs for all Eclipse projects (or at least all the Eclipse projects that have contributed strings via the inputs). There should be one language pack for each language, i.e., chinese.zip, icelandic.zip, spanish.zip, etc. The language packs should be provided as zips (similar to http://download.eclipse.org/eclipse/downloads/drops/L-3.2.1_Language_Packs-200609210945/index.php but those are multiple languages per pack, whereas we are doing one language per pack). The zips should be available on the Babel download page and can be url linked from the project's pages as they desire.

Additionally, the language packs should be available as features (I think one feature per language) from the Babel update site (also on the download server).

For now, the version ranges in the plug-in fragments that define each language for each plug-in should be as wide as possible (0.0.0 - 9999.9999.9999 or something). In a future feature, we will provide a way for the projects to request that a certain version range be used.

This "outputs" spec assumes that plug-in fragments that extend non-existent plug-ins are ignored on Eclipse start-up. Bjorn has investigated this and it turns out they are not ignored but cause a warning for each plugin that does not exist at startup.

Output will be provided in three different ways

1. One large file that contains all the translated strings for every project.
2. One file per project that the release engineers can grab and use in their language packs.
3. Files grouped by bundle as specified by the packaging project (for example).

Other

In addition, the system must have bugzilla account authentication, an audit trail, and a rollback mechanism. The PC would also like there to be a quality notation system (so that people can vote on strings being "particularly good translations", thereby hinting to others that they should not be changed).