Difference between revisions of "EiffelStudio Internationalization"

Revision as of 17:19, 26 November 2006

Overview

Since i18n have been mostly implemented in Eiffel, Eiffel Studio is coming into the new era of internationalization. The goal of i18n integration is to provide multiple language support in Eiffel Studio and let users switch languages of the interface easily at runtime.

Steps to integrate i18n

Non-editor part

The first step concentrates on the interface of Eiffel Studio. All buttons, labels, tool tips and grids that are directly used by Eiffel Studio project.

1. Collect all static interface strings in the system., including some context depend strings.
   1. This is not necessary, but doing this give us better management and code quality. Only INTERFACE_NAMES knows i18n.
   2. Change all types in INTERFACE_NAMES, EB_METRIC_NAMES, CONF_INTERFACE_NAMES, WARNING_MESSAGES to be STRING_GENERAL. Caller should be adapted correspondingly.

  For some stings, two versions maybe needed. One for internal use, the other one for the interface,
  especially for strings saved as preferences and strings constants used in configure XML files.

1. 1. Rewrite bodies of those strings using i18n translation routines, STRING_32 instances are actually produced.
2. Build language menus to switch language.
   1. Make interface classes locale observers so that all tools know when interface names should be reread.
3. Solve the problems in vision2.
   1. In Chinese, menu chars are conventionally parenthesized and under scored following the menu text. This can be done by the translator.
   2. Handle "&" as both char and wchar for menu items.
   3. Fix "tab" issue for menu items.
4. Integrate i18n .po generation tool. It has been done in i18n branch.
5. using .po generation tool integrated ec to compile an ec in which interface names have been adapted.
6. Use .po generation tool to generate estudio.pot file. The .po generation tool generally extracts strings that are taken as parameters of `translated' and `translated_plural' and produce .pot file.
7. Since strings used in EiffelStudio not only come from the source code. Write scripts to extract them and merge them into estudio.pot

 Strings should be extracted from:
 default.xml → descriptions of preferences

1. Duplicate estudio.pot file to .po files with names of locale ids. Each .po file represents a locale. i18n library read .mo files with correct names of id. Though .po files are not necessary to have names of locale id, .mo files are one-to-one produced from .po files. So using locale ids as names of .po files is reasonable.
2. Translators using .po editor open .po files and translate interface names to all kinds of languages.
3. Generate .mo files using .mo generation script.

Editor part

1. This step might be more complicated. And will be done later after the first step. Probably after 6.0 release. This step concentrates on extending the editor library to accept wide characters. Internationalization of any output directed to the editor is done in the step. Many existing tools might be affected, search tool, formatting tools etc.
2. Encoding conversion facility is needed.

File structure

Repository

All files are stored in %EIFFEL_SRC%\Delivery\studio\lang

%EIFFEL_SRC%\Delivery\studio\lang\script

Place where scripts for generating .mo files are put. The scripts are invoked when building a delivery.

%EIFFEL_SRC%\Delivery\studio\lang\mo_files

Place to put .mo files. Those files are actually used at runtime.
Only .mo files need to be included in a delivery.

%EIFFEL_SRC%\Delivery\studio\lang\po_files

Place to put .pot file and .po files. 

Delivery

 Windows:
 %ISE_EIFFEL%\studio\lang\mo_files\*.mo
 Unix:
 /usr/share/locale/(product_version_name)/*.mo

Maintenance

• .pot file is PO template file which is generated by .po generation tool that will be integrated in Eiffel Studio. In my point, .pot file is simply untranslated file with only source entries and blank target entries.
• .po files are the files translators actually work on. Whenever translators get a new version of .pot file, they should merge .pot file and the .po file they are working on. When merging, tools like poEdit give lists of new strings and obsolete strings. And in the full list new strings and fuzzy strings are marked in different colors by poEdit.
• Fuzzy strings are applied when merging. msgmerge of Gettext make slightly changed strings fuzzy. When the checking of fuzzy strings is done, translators should remove fuzzy marks.
• Obsolete strings are commented out at the end of .po files when merging. Those comments can be removed at anytime if we wish.
• When the translation or modification is done, translators only need to commit .po file(s) that they are working on.
• New .po file can be added directly in %EIFFEL_SRC%\Delivery\studio\lang\po_files. Eiffel Studio should have the ability to detect at runtime what languages are available.