Mozilla quizes Narro

Narro again, you English folks!

I'm answering a quiz found on Seth's blog.

• Who are the toolsets targeting? A spectrum of skill level/interest/involvement of localizers exists. These individuals probably fall in one of the following categories.

  * Translation skills, but no technical skills, and no interest in learning technical processes;
  * Translation skills, but no technical skills, but DO HAVE interest in learning technical processes;
  * Translation and technical skills, but no experience with Mozilla;
  * Translation and technical skills and experience with Mozilla;
  * Technical skills, interested in helping, but no translation skills.

• Narro targets every category.
  It started out as a tool with two main goals:
  - to allow absolutely anyone to translate
  - to allow me to push a button to export the translations on the CVS.
• Does the tool provide context around what needs to be translated? Does the tool have translation memory and glossaries?
• For mozilla, the context is the key used in the dtd, ini and properties files. Yes, it has translation memory. Glossaries is a todo.
• Does the tool create a translation output that does not have any problem integrating with Mozilla’s code base? Another similar question: Does the tool create a new/simplified version from scratch that is ready for check-in to our VCS? Please describe.
• Narro imports and exports directly from and to a CVS mozilla structure with no other conversion. It uses the directories that would normally lie in l10n directory.

  
l10n
- ro
- en-US
mozilla
- browser
- build
- calendar
- client.mk
- config
- configure
- configure.in
- CVS
- dom
- extensions
- mail
- netwerk
- other-licenses
- security
- suite
- toolkit
- tools


  During the import process, Narro reads l10n/en-US as templates and searches in l10n/ro for corresponding files. If files are found, the files are compared to the templates key by key and the data is imported accordingly.

  During the export process, Narro reads l10n/en-US as templates and starts to write them in l10n/ro, overwriting any existing files. The l10n/en-US templates are searched by file and key (e.g. downloads.label); if matches are found, the text corresponding to the key is replaced with the translation. Comments, formatting and special instructions from en-US files are kept in the files written in l10n/ro.

  During the import/export processes, access keys are automatically converted like this:
  
<!ENTITY printPreviewCmd.label "Print Preview">
<!ENTITY printPreviewCmd.accesskey "v">


  The resulting text in Narro is:
  
Context: printPreviewCmd.label
Original text: Print Pre&view


  Starting a new translation or updating changes from CVS is done via the import process.

• Does it help with updates on new releases, versions (branches vs. trunks)? The proposal should describe its compatibility.
• Separate projects can be defined. Considering we have Firefox 2 completely translated, the steps to create a Firefox 3 project are:
  - checkout the Firefox 3 CVS tree (this part could be integrated in Narro)
  - import it in Narro specifying that you want the strings that are already translated to be validated during the import (if no manual check is desired)

  That's it. See that it can be done with the push of a button if desired. After this, users can select to see the strings that have no suggestions and start adding suggestions. Validators can select to see strings that are not validated and start validating.

  Note that Narro keeps a collection of texts to be translated and each one can have multiple translation suggestions. Texts are unique. A project holds a reference to the texts based on contexts (keys, e. g. downloads.label, in mozilla). So if there are suggestions for a text, any project that uses that text will have the suggestions available for use.

• What interface will be used by the “user/translator/localization participant” with the proposed tool?
• Simple web translation focused on usability and fastness.
• What is the interface’s path to the final output? (Hopefully, that final output is bug-free.)
• A CVS structure is updated with the push of a button. Next step is committing changes to CVS. This is done manually now, but could be automated to be done nightly.
• How is the new interface less complex than existing interfaces or processes?
• Narro's interface is as simple as it gets. Here's how it works:

  1. Choose what project you want to translate
  2. Select a text to start translating from
  3. Type in the translation, push save and you'll be taken to the next text to translate (repeat)

  People can receive a link to get directly to the first text that needs translation, so the first 2 steps would be eliminated.

• Is the proposed toolset scalable and maintainable? Does the tool require that the developer continually maintain it or is the process fully-automated? Describe the level of ongoing maintenance involved with the tool developer and how the tool scales.
• The tool can be fully automated such that the import/export is done periodically via cron. There is no maintenance needed.

  The heavy part is carried by the database. Firefox 3 has about 4765 texts now. I'm using Narro for OpenOffice too, where I have about 70000 texts. There are two tables that will continuously grow. The texts table and the suggestions table. Millions are acceptable. MySQL database is not a must, other databases can be used. Right now, searching takes the most out of the database. This can be easily fixed by having a Lucene index for this. If a project has over 1 million texts, such an index is recommended. So growing has no known limits so far.

• The proposal should describe who owns the tool and what open source licensing will be used. Is the final product free and open? This is a must.
• I own the tool. Releasing to OpenSource is in progress. I'm guessing GPLv2, but since I'm no legal junkie, I'll listen to other suggestions if there are better ones. I want it to be free to use and free to be developed.
• The proposal should describe how the tool streamlines collaboration among the community.
• The most important part achieved regarding the community is that the translation is available for everyone to easily see it, browse it and search it. Users don't have to dig in the jar or browse the cvsweb interface.

  Right now, users have the possibility to comment translation suggestions when they are added and also they can vote for the suggestion they like most. In a perfect world, the most voted suggestion would be validated and used.

  A way to communicate is not a Narro objective, so web groups or other ways should exist in parallel to allow discussions.

• How does the proposed tool remove barriers to entry/success?
• By allowing to simply type in the translation with no extra fuss. All that you have to do is translate. No software installation needed, you can do it from anywhere you are and anytime you have some spare time.

  Think of Narro as fans that keep coming to get autographs from you. You ask each one their name, think and write something accordingly.

  The fans are the texts to be translated, the names are the contexts in which the texts appear and your autograph is the translation of the text taking in account the context.

• How many people does the team expect this tool to reach. We ask the proposal to estimate the size of the target audience.
• Because it allows anyone to translate, this number of users who translate is expected to be big.

  100 people that translate 10 texts each is better than the one man job. You come, you translate, you leave. That's it. If you liked it, you return. If you find some translation wrong while using the software, come back and type in a better suggestion.

  The number of people who validate should be small, so they can keep contact to ensure a consistent final product is obtained. 1 or 2 will do.

  The number of people who export/import for CVS should be small as well for the same reasons.