Eclipse 3.1.1 translation packs available!
For the Eclipse 3.1.1 release, IBM Rational Software has contributed translations for the Eclipse Project and for several subprojects of the Eclipse Tools Project, the Eclipse Web Tools Platform Project and the Eclipse Test and Performance Tools Platform Project.
Eclipse Platform Project
Translation is comprised of the IDE Platform, SDK, Base Platform, JDT runtime, PDE runtime
http://download.eclipse.org/downloads/drops/L-3.1.1_Language_Packs-200510051300/index.php
Eclipse Tools Project
Translation is comprised of several projects:
Visual Editor (VE)
http://www.eclipse.org/vep/WebContent/docs/translations/translation.html
UML2
http://download.eclipse.org/tools/uml2/scripts/downloads.php
Graphical Editor Framework (GEF)
http://www.eclipse.org/gef/translations/translation.html
EMF / XSD
http://download.eclipse.org/tools/emf/scripts/downloads.php#NLS21
Web Tools Platform Project
Translation is comprised of Web Standard Tools and J2EE Standard Tools
http://download.eclipse.org/webtools/downloads/translations/M-0.7.1-200509270720/translation.html
Eclipse Test and Performance Tools Platform Project
Translation is comprised of TPTP Platform, Monitoring Tools, Testing Tools and Tracing and Profiling Tools
http://www.eclipse.org/tptp/home/downloads/drops/TPTP-4.0.1.html
The language packs are distributed as zips, which you can install by downloading the zip file, unzipping into your Eclipse directory before starting Eclipse. Please read the details below concerning the zip files and their contents before using these translations. For all the projects there are these types of language pack zip files:
NLpack1 – Contains the NL fragments and the NL features1 that contain those fragments for: German, Spanish, French, Italian, Japanese, Korean, Portuguese (Brazil), Traditional Chinese and Simplified Chinese.
NLpack2 – Contains the NL fragments and the NL features1 that contain those fragments for: Czech, Hungarian, Polish and Russian.
NLpackBidi – Contains the NL fragments and the NL features1 that contain those fragments for: Arabic.
NLpack1_FeatureOverlay – Contains the translations for feature.properties files contained by the features2 defined by the Eclipse component being translated. These files contain translations for: German, Spanish, French, Italian, Japanese, Korean, Portuguese (Brazil), Traditional Chinese and Simplified Chinese.
NLpack2_FeatureOverlay – Contains the translations for feature.properties files contained by the features2 defined by the Eclipse component being translated. These files contain translations for: Czech, Hungarian, Polish and Russian.
NLpackBidi_FeatureOverlay – Contains the translations for feature.properties files contained by the features2 defined by the Eclipse component being translated. These files contain translations for: Arabic.
1 NL features are new features that did not exist for the component prior to translation. They parallel the set of features defined by the component and contain the NL fragments that contain the translations for the plugins contained by the corresponding features. They contain the translations for their own feature.properties files, not the translations of the feature.properties files contained by the corresponding features.
2Feature overlays contain the translation for the feature.properties files contained by the corresponding features. Here are the details as to why these files exist.
These are the only translatable values inside an Eclipse environment where the English strings are not in a plugin or plugin fragment. There is no such thing as a feature fragment like there is a plugin fragment. The translations of strings in feature.properties must reside in the feature directory right next to the English feature.properties file in order to be found. The feature directory names include the version number at the end. So do plugin directories but that is not a significant fact in this discussion as the fragment support can handle the plugin and fragment not having the exact same version as long as the fragment.xml file has a proper match clause on its plugin references. So, for the feature.properties translations which are created, managed and ship separately from the component zip files to land in the proper location to work properly when unzipped over an Eclipse install, the directory names in two independently built zip files have to match exactly. There is no such problem for the rest of the translations including our NL features since those are built as a whole. The only way to get this right is to build the overlay files against every release (even all the maintenance ones) that you want them to work with and then re-release them for each one. Prior to 3.1.1 all the translations (the well behaved majority and the overlays) were included in the same zip file and rebuilt everything for each release (even the maintenance releases). This is not required for most of the translation volume, just the overlays so now, starting with 3.1.1, they are separated. Going forward, these NLpack zip files will work with all 3.1.x releases without a rebuild (not 3.1.0 since there were too many NL fixes in 3.1.1). Each component will need to continue to re-release the much smaller NLpack_FeatureOverlay zip files with each maintenance release simply to align the directory names. Alternatively, consumers of a component now have a small number of directory names to fix up as they move from one maintenance release of a component to another. Finally, the various group overlay files must be separated since they should be separately selectable and the contents would collide by definition (identical directory structures) if in the same zip. The three NLpack zip files could have been combined into one since they would not collide with each as they have different NL fragment and NL feature names but it was determined that consistency in packaging the language groups separately would be best.
