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.
There are two input mechanisms: a manual REST-based one and an automatic pde.build map-based one.
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.
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
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
- 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.
- For each key-value in the input, check if the key exists in the Babel database.
- If so, check if the value is the same.
- If so, no action.
- If not, replace the value and mark all translations as potentially incorrect.
- If not, add the key and value to the Babel database.
- If so, check if the value is the same.
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 choose of a language/project. The current version of the project will be selected by default (with a way to change to previous version).
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 add have a babel user page that will show details of how many strings they have translated, how those string have been rated.
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.
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).