Seamonkey Localization and Leveraging Tools

Document History

• 03/29/99: Second pass revision. Post to the groups to collect comments and feedbacks.
• 03/25/99: Move "XUL Localizability dependency" to XUL Localizability issues; start to work on the full spec of L10n Tools.
• 03/18/99: Finishing up the first draft.

Introduction

Seamonkey is our next generation browsing and messaging client whose internal architecture is undergoing drastic restructuring. Most of the components, including user interface, will be rewritten using new technologies such as AOM, XUL, and XPCOM style modularization. Subsequently, the tools for earlier client release become practically insufficient and potentially inefficient. To solve this problem, we need to review our existing tools and revamp them to fulfill the requirements of the new generation client products.

In this document, the author will analyze the requirements of the new tools and examine our existing tools for their capacity. Then come up with a outline of how to develop localization and leveraging tools for our next generation client product, Seamonkey.

Finally, as many other documents, this document is to be updated as we collect more information and the client modules evolve.

Design Principles

• Portability. Seamonkey is designed toward the direction of platform independence. There is no reason to develop platform dependent tools for a platform independent product.
• Consistency. It would be a localization nightmare if we need a different set of tools for each individual component of the client product. Needing different sets of tools for different components of the client indicates our client localizability solutions are not consistent nor developers friendly. For localizers, multiple file formats reduces their productivity, too. Therefore, we shall advocate a singular localizability solution across all client modules and components wherever feasible.
• Validability. Normally, localization work is performed at a remote site. The translators need to be able to validate the results in their local environment. Sending translations back and forth between we and localizers is time consuming and inclined to misplace or lose data.
• Leveragibility. Localization is costly. The ability to leverage is essential to bring down the cost. In addition, it will make the translation consistency among releases.
• Flat file.  Ideally, we want to developers to put localizable resources in flat file; if not feasible, we shall convert them to flat files.

Strategies

• Centralized. We shall eliminate the number of different file formats need to process and localize. In client development, we want to adopt the same localizability solution whenever applicable. For client localization , we want to reduce the variety of file format the translators need to deal with. Therefore, we need to adopt a singular file format as the center of localization. Other file formats need to be converted to this format before sending to localization vendors.
• Incremental. In consideration of time constraint, we want to develop the tools incrementally: begin with basic features, then gradually migrate to the full blown version. This strategy also fits the nature of software development cycle: incremental evolution and iterative refinement.
• Componentized. A good software system shall be be highly componentized. The concept of Data abstraction and information hiding shall be applied to identify our problem domain and system functionality. Properties and behaviors of each component will be analyzed and identified so that they are highly cohered. Relationships and interfaces between components will be clearly defined so that there are loosely coupled.
• Pluggable. If our system is highly componentized, individual modules shall be pluggable. This will give us a great advantage of leveraging existing tool components while keeping the flexibility of adapting to new technology.

Localization work in Seamonkey

XUL-based User Interfaces. The adopted localizability solution for XUL based UI is the language-specific DTD approach. All localizable resources needed in XUL will be declared as general entities in the external DTD and substituted by the XUL parser before the XUL is converted into DOM tree. Resource strings in this type of DTD files need to be extracted into intermediate file format, say L10n file,  that the localization vendors can easily deal with.

Base component modules and non-XUL describable UI such as native widgets. The "nsIStringBundle" is our 5.0 equivalent of XP_GetString(). It provides a COMified  interface to retrieve resource strings from Java-property-like files. Resource strings in such files need to extracted into the so called L10n file for the vendors as well.

Legacy code. Seamonkey contains some 4.x modules which use XP_GetString() to get resource strings from resource files. To localize the legacy code, we can either create a set of C wrappers around nsStringBundle() or use the 4.x XP_GetString() approach directly. The former is preferred.

Plan

1. Define the intermediate file format, say L10n, as the center of the localization and leveraging work.
2. Write tools to convert files between the L10n format and all existing file formats such as the property file and DTD file in Seamonkey or the DOG file in legacy code. These tools shall be highly modularized and pluggable so that they can be built into either command line tools or graphical user interface based tools.
3. Write tools to collect resource strings from all L10n files, organize them into a sortable data structure. The purpose of this is to compare translations between modules or UI components so that we can leverage them among different components,  different releases and even different products. The ability of collecting and comparing also allows us to increase the consistency and quality of translations.
4. Build graphic user interface based tools on top of the command line tools. Since modularization and pluggability has been the design and implementation strategies, we shall be able to reuse developed functions in the command line tools and  construct user interface on top of them.

Tasks breakdown and estimated resources allocation

• Prerequisite. Define a flat file format which will be used to store translation. So far, there are two file formats, the Java property file format and the 4.x DOG file format, under discussion. The final decision is pending on the inputs from our localization vendors and OEM customers.

  Java property file

  Pros

  • Industry standard. The Java property file format is the center file format of localization for Java applications. It's more likely that localization vendors are more comfortable with this file format.
  • It's the file format being used by the nsStringBundle interface in Seamonkey. Another standalone module also uses a similar file format.

  Cons

  • Some feedbacks suggest that translators might accidentally damage the keys in the property file.

  DOG file

  Pros

  • It's the central file format for 4.x localization. All 4.x localization and leveraging tools work with DOG files. We can save lots of implementation efforts by adopting DOG format.

  Cons

  • It's a proprietary file format; we might be the only company uses this format.
  • The property file used by nsStringBundle and other modules needs to be converted into DOG format. Although, this shall not be a significant effort.

• Phase 1 (entry level). Command line localization tools needed for each of the first two categories:
1. DTD files (for XUL)
• DTD files-> L10n files. A DTD parser to extract entity names and values pairs into L10n files which will be sent to vendors to localization. Entity values containing markup or URLs can be dealt separately.
• L10n files-> DTD files. A flat file parser to extract result strings and replace English strings in DTD with localized ones.
2. Property files (for nsStringBundle)
• Property file-> L10n files.
• L10n files ->  property files.
3. Legacy code. Create a set of C wrappers around nsStringBundle() or use the 4.x XP_GetString() approach. The former is preferred.
• Phase 2 (intermediate level).
• A localization tool (and a potential leveraging tool) to
• Collect all localization results from the L10n files generated from phase 1.
• Sort localization results by different attributes such as
• by English text
• by UI components (menu item...)
• by application component (navigator window, mail/news windows)
• Dump collected translations by sorted attributed (mostly ID) to a single L10n file.
• Leveraging tool
• Match/find a localized resource by a given "English string".
• Automated batch job to leverage existing translations.
• Phase 3 (advanced level)
• GUI based cross platform tool (might be a browser-based) to give WYSWYG affect. The translators can verify the result as they progress.
• The translators can leverage/import existing results from other components.
• Leveraging 4.x results.
• Dump 4.x result to L01n files for 5.0 use.

Tasks breakdown & Estimated Time Table *