Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Babel / Server Tool Specification"
(New page: 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 desig...) |
(→Outputs) |
||
| Line 26: | Line 26: | ||
### If not, replace the value and mark all translations as potentially incorrect. | ### If not, replace the value and mark all translations as potentially incorrect. | ||
## If not, add the key and value to the Babel database. | ## If not, add the key and value to the Babel database. | ||
| + | |||
| + | ===User Input=== | ||
===Outputs=== | ===Outputs=== | ||
Revision as of 17:05, 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
- 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.
User Input
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).