Visit Mozilla.org

L10n:Tool

From MozillaWiki

This page is a scratch pad for notes about L10n:Tool.

It'll be a XulRunner based tool. It will allow to:

  • Edit locale package (in .jar file or in directory)
  • Synchronize/translate taking source locale and result locale
  • Update localization - taking source-old, source-new, result-old and creating result-new
  • Work with CVS/SVN based sources
  • Allow groupwork (by network synchronize?)

Contents

Who is working on it? [edit]

We need people who know XUL/JS and are willing to help.

UI talk [edit]

Img1

  • You can open it from jar, directory or CVS/SVN
  • You can change file type between dtd/prototype without a problem
  • You can export to po file
  • You can write as a jar or as a directory structure
  • You can upload to CVS/SVN
  • You can mark entities as Fuzzy, add notes to them etc.

Img2

  • You can open it by selecting two jar files, directories or two CVS/SVN dirs.
  • One of them is a source, second is a translation.
  • L10n tool will show the missing entities, files, fuzzy files etc.
  • It will allow to set up a list of people you cooperate with and somehow block some parts of the translation for you
  • You'll be able to search via strings
  • The system will warn you if you miss some external entity in yours

Img3

  • You selects source-old, source-new, result-old and builds result-new
  • New files and entities are greyed out until you start fileing them


Some very first tarball with mockups

How to launch it? [edit]

It will launch Xul chooser.

Usefull links [edit]

Additional ideas [edit]

  • Repackaging stuff/building packages

A (partial) functional spec [edit]

The following will cater for the Synchronize/Translate and the Update localization use cases.

Creating a new l10n project [edit]

To create a l10n project, one would select the source locale files (CVS/SVN tree, a Jar, or a plain directory) and, optionally, target locale files (CVS/SVN tree, a Jar, a plain directory), in a manner similar to what is described under Img2 above.

The Tool then bootstraps a project file. The project file contains at a minimum:

  • paths to source and, if applicable, target locale files
  • copies of all the source and, if applicable, target DTDs and properties files
  • the string database, where for each translatable string we record:
    • id
    • original text
    • translated text
    • one of the states: translated (green), needs-review (greenish), fuzzy (yellow), untranslated (red).

We keep copies of the source and target in the project file because we allow the source and target files to be updated from outside. E.g. the source can be a product jar -- like the en-US.jar found in the Firefox install dir -- or even a CVS subtree like the one in the Mozilla tree.

Why do we need the "target files" (and even copies of those) if we have the string database? To allow us to work in a nice way with other l10n tools like Mozilla Translator, or even with people who prefer to localise by directly editing the DTDs and properties files. The target files can be updated too from outside the Tool, if they are in a CVS tree like the one we are using in the Firefox/Thunderbird 1.5 localisation.

Opening a l10n project [edit]

Dialogue before opening

Each time the Tool opens a project, it tries to synchronise its own copies of the source and target files with the real ones.

  • If strings have been added in the source locale files:
    • If the strings aren't yet present in the target locale, they get marked as Untranslated
    • If the strings are in the target locale, it means that they've just been translated by someone else in the l10n team. The synchronisation wizard marks them as Needs-review to give us the chance to review our colleagues' work.
  • If strings have been changed in the source locale files:
    • strings that have also been altered in the target locale get marked as Needs-review
    • strings that haven't been altered in the target locale get marked as Fuzzy
  • No strings have been changed in the source locale files. Then just merge any changed strings in the target files, and we're go.

Translation work [edit]

Changes that we make are stored in the string database.

Merge translation into target [edit]

If we have target files, from time to time we may want to update them with the translations from the string database. In this step we resolve any conflicts that may arise. After merging, we can commit those changes into CVS, if the target is a CVS working directory.