Revision as of 15:33, 4 March 2012

Translation FAQ

What are the rules in dealing with mnemonic characters (words using the ampersand)

You don't have to use the original mnemonic character in the string. But, before you change it to another mnemonic character, you have to know where the string is being used and check if there are any conflicts.

For example, "&File" is translated to "&Datei" in German. But, before we choose "D" as the mnemonic character, we have to check if it's conflicting the mnemonic characters for "Edit", "Source", "Window", "Help", etc.

Keeping the original mnemonic character wherever possible will minimize the possibility of conflicts because we know (supposedly tested) that we do not have conflicts in English.

Note: even if there are conflicts (2 of the same mnemonics in the same pulldown menu), it's still okay. Most OS will cycle through the choices and highlight the selection when you press the mnemonic again. Of course, it's better not to have any conflicts to avoid confusion.

How good are the Babel community translations

From what the Babel team has seen so far, the quality of the Babel community's translations is quite high. Many translated strings were done by professional translators, and their work has been donated to the Babel project. Babel also has Language Champions which help oversee the translation efforts.

Project FAQ

There are plenty of translation tools. Why did Babel reinvent the wheel?

Although some may assume Babel has reinvented tools like gettext, we haven't. Babel starts with strings that have already been externalized. When Eclipse projects haven't properly externalized their English strings, they cannot use the Babel community for translations… See https://bugs.eclipse.org/bugs/show_bug.cgi?id=241848 as an example.

The scope of Babel is to leverage the community to translate those externalized strings. The web UI translation tool (at http://babel.eclipse.org/) started with a code contribution from a company called Aptana, so again, we're not inventing any tools here. We have taken the tools that have been donated and we’re evolving them.

Have you considered sharing your work for other translation attempts?

Others are free to consume our translations by downloading the NL fragments, and others are free to download and use the web-based translation tool we’re working on, as it is in CVS: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.babel/server/?root=Technology_Project

Committers FAQ

How do I add my project to Babel?

As a committer, simply log into the Babel translation server with your Bugzilla account, and use the FOR COMMITTERS link. Then define the MAP files used to build your project. If you don’t know what they are, please ask your Release Engineer or Build team.

How do I choose the correct MAP file URL and version to add to Babel?

MAP files are entered into Babel using the 'checkout' view of the file in ViewCVS.

When entering map file URLs in Babel, you want to avoid linking to current development streams, such as an active branch, or HEAD. If we link to HEAD for an upcoming release (say, WTP 4.0), we need to update all the map files for that version as soon as it's tagged R4_0 (or whatever the project convention uses) otherwise our maps processor will continue fetching new strings from HEAD.

To see the list of tags and branches, simply remove any pathrev and view parameters from a map file in ViewCVS to reveal the file's log, like this: http://dev.eclipse.org/viewcvs/index.cgi/webtools.maps/releng.common/maps/jst-common.map?root=WebTools_Project

It can be quite a mess to figure out (hence asking the project release engineers is a good idea), but most projects tag a release as Rx_x_x, where a release 3.4.1 would be tagged as R3_4_1

Do I need to maintain all my maintenance releases in Babel?

No, please don't. If you have a release 2.0, 2.0.1 and 2.0.2, simply define the 2.0 map files and update them to the latest maintenance release tag. It is usually safe to assume that maintenance releases do not contain many new or changed strings.