Difference between revisions of "Babel / Server Tool Specification"

Revision as of 17:45, 2 January 2008

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

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.

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

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. I (Bjorn) have not verified this to be true. If the Planning Council's assumption/belief is false, we will need a different design.

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