Revision as of 05:15, 12 July 2018

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 Git: Babel LAMP-based translation server project Babel messages editor and plugins

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 source files used to build your project. If you don’t know what they are, please ask your Release Engineer or Build team.

[Major update of this section July 2018 - please correct it as required]

The fields with example values are:

• Project:
  • mylyn
  • (Select the name of your project here)
• Release Version:
  • dev
  • * 3.9
  • 3.8
  • * 3.23
  • (Select a version of your project here - the versions are defined in your project page e.g. Mylyn project page. The asterisk * means that a source location has been defined for this release.
• Release Train:
  • Photon
  • Oxygen
  • Neon
  • (For Simultaneous release projects - select the release train to which that version was incorporated. This field is used for the Babel builds where all the translated message files for a particular release train are collected together. The current release seems to be built nightly, and another 2 or 3 are built weekly. See Babel downloads. The result of translating your release version will be made available in the release train build.)
• Project Source Locations: (Git repository snapshot URLs, example: http://git.eclipse.org/c/platform/.../snapshot/R4_2.zip)
  • Find the Git repository location for your source which has been labelled with a tag. E.g. for the Mylyn project go to the refs page for Mylyn and find the 'Tag' 'Download' section and identify the tagged release download zip for the source code for your project. For example org.eclipse.mylyn.builds-R_3_23_3.zip. If you do not have a tag, then in Git or EGit define a tag for the appropriate commit for your project that was used to build the simultaneous release version. You can define multiple source locations if your project is made from multiple source locations. Check that the download links works for you and that the zip file is complete and can be unzipped without errors. The Gerrit links rather than direct Git links to your project do not seem to work as well - sometimes the zip is truncated. Beware of scrolling through the Git links - the Gerrit links appear as a section.
• Plugin Exclude Patterns: (regular expressions, example: /^org\.junit\..*$/)
  • Some parts of the source may have properties files which do not need to be translated, such as test cases. Exclude those files here so that your translators do not waste time translating parts that end users never see.

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.