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 IIa: Make Deployment Simple

For Babel to be a successful project all the committers on the project need to be able to release code to the staging and live server. As of version 0 we are able to deploy changes in code to the live server only after someone manually goes through the process of checking the code and checking that the database structures sync up.

• Add mechanizing to handle changes to the database structure without losing data (portal code?)
• Have a deploy script that any committer can run to release code/database changes to the live server
• Instructions on how to checkout code, install locally, push to staging, tag, release.

Phase IIb: 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).

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. Thus the one-pack-per-language translation will causes dozens and dozens of warnings to appear in the error log for any user who uses them. This is marginally acceptable. A better solution will be to have the projects themselves take the Babel-produced plug-in fragments and build project-specific language packs.

Output will be provided in three different ways:

1. A Babel update site with one feature per language. That feature will contain all the fragments for all the plug-ins of all the versions of all the projects. The fragments will have version constraints as described below. The features will be named "NLpack-French", "NLpack-Swedish", etc.
2. One zip file per language that contains all the fragments for all the plug-ins of all the version of all the projects. This is the same as the update site, but as a zip file. The zip files will be named "NLpack-French.zip", "NLpack-Swedish.zip", etc.
3. A download directory containing all the plug-in fragments, one per language x plugin x version. These fragments are not in a directly user consumable form (neither a zip nor an update site), but instead are intended for project releng and distro producers to use to create project-specific and distro-specific language packs. For ease of distribution, each plug-in will be contained in a zip file named "NL-plugin-version-languagecode.zip" e.g. org.eclipse.mylyn.ui-2.2-fr.zip

The Babel download site layout will be:

/updates/ ... update site with features as per 1
/zips/ ... zip files as per 2
/plugins/ ... plug-in fragments as per 3

Version constraints. In order for all the versions of a language to exist in the same zip or feature, the plug-in fragments for outputs 1 and 2 will have version constraints as follows. Consider a plug-in X that has versions 2.0, 2.2, 3.0, and 3.1 in Babel. Babel will produce four plug-in fragments for X for each language and will combine all four of the fragments together into one feature. The four fragments will have version constraints to prevent them from colliding: [2.0.0,2.2.0), [2.2.0,3.0.0), [3.0.0,3.1.0), and [3.1.0,*). Plug-in fragments for output 3 will contain version constraints with no upper bound as per the standard practice for the Eclipse Platform project in the past.

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).