Narro: An l10n tool

Back on the topic of localization tools, I scheduled a call today with a Rumanian localizer named Alexandru Szasz to learn more about his recent work on a tool that he calls Narro.  I wanted to learn what he has created and to see if Mozilla can provide any support to him.  There are quite a few tools out there, and we want to find the ones to support that will improve the Mozilla process. He explained his software and we talked more about our initiative to fund tool development through the Community Giving/Empowerment program.

Afterward, he read the evaluation criteria from my last post and blogged about it.  Here are his answers to our criteria.

What do you think?  Can you provide any helpful comments to Alexandru?

We’ve received about four or five ideas for tools development.  Some are very formal proposals and others are great projects/ideas that may or may not need our help.  As we get closer and closer, I’ll post these proposals/ideas (as long as I get approval from the tool proposers), so you can read them and see what we are considering.

Evaluating the l10n tools proposals

In my last two blog posts, I’ve discussed the effort I have undertaken to provide more leveraged resources to the l10n community.  We’re focusing on tools development.  And, it seems clear that I should specify what we’re looking for, who we are targeting, and what our some indicators that we think will lead to a successful deployment of tools for the l10n community.

What we’re looking for?

If you have ever tried to localize a Mozilla product, you know there are tricky steps along the way.  Here is a list of Pain Points from the Mozlla Wiki, describing what’s tough about translation.  (A fair warning:  this is an older list, so it’s changed a bit.  Not all pain points still apply.  My illustrations from the previous post should be a more accurate reflection of the current process.)

Along with these descriptions of the pain points, it is necessary to mention that tools do exist in the FLOSS world.  A number of people have either created open source tools for projects like Mozilla to use, and some have tried to focus on Mozilla and its set of software applications.  Many existing tools have different focuses.  Because of this, we had to ask what would really benefit the Mozilla translation process?  Below is an exhaustive list (we hope) of questions that we felt each proposal should answer.  If a team were willing to create tools that could answer these questions, then it is our belief that we will have found something that makes the lives of Mozilla localizers easier.

Here are the questions:

• 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.

• Does the tool provide context around what needs to be translated?  Does the tool have translation memory and glossaries?
• 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.
• Does it help with updates on new releases, versions (branches vs. trunks)?  The proposal should describe its compatibility.
• What interface will be used by the “user/translator/localization participant” with the proposed tool?
• What is the interface’s path to the final output?  (Hopefully, that final output is bug-free.)
• How is the new interface less complex than existing interfaces or processes?
• 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 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.
• The proposal should describe how the tool streamlines collaboration among the community.
• How does the proposed tool remove barriers to entry/success?  
• How many people does the team expect this tool to reach.  We ask the proposal to estimate the size of the target audience.

If a proposal were to answer these questions, then we think we have a good chance at success.  I’ll continue to blog on this issue because there is a lot to discuss.  In an upcoming post, I want to write about metrics for success.  How will we be able to evaluate the tool?  How will we know we have hit success?  Additionally, I’d like to start opening up what tool proposals we are looking at, who we have talked to, and what we plan to do next.

Now you’ve seen three posts in a row on this topic.  Starting with the high-level direction, moving through the illustration of the existing process, and writing here about how we intend to evaluate each proposal.  It’s a fine time to contribute if you’d like to change the course of this.  This is as open as we can make it, so please chime in now if you have an opinion or can point me in a direction where we haven’t gone yet.

Illustrating the l10n process

In my last post, I described how my Q4 2007 goals had changed a bit with the Community Giving/Empowerment program.  We have begun targeting areas where we could provide support that would benefit large numbers of people in our community, in addition to reaching out to individuals who need support.  I had learned that some members of the community were interested in developing tools for localizers to use.  And I thought, what better way to launch this new facet of our program than by helping to find and fund l10n tools proposals.

Before I solicited proposals, I had to do some homework to understand the process for myself with two goals in mind:  to learn where tools might be needed and helpful; and to provide value to our process by illustrating the steps undertaken by an individual to localize Firefox.  In doing this, I felt I might be able to pin down just where we should develop tools and how Mozilla could help.

The diagram below is an illustration of the steps a new localizer has to take to start a localization.  I’ll admit that it probably has some flaws, but I have passed it around to a number of people familiar with the process and gotten their feedback.  If you’d like to comment or suggest a change, please do so.

(At this point, I’ll dive into a bit of operations mode…sorry to sound too much like an “MBA”, but it was helpful for me to see the process.  Please bear with me as I take us through shapes and colors, and don’t poke too much fun.)

Any circles on the diagram indicate that an operation is (or can be) performed by the localizer.  A triangle means that a localizer is “storing” something.  I used a triangle in combination with a circle to show the “setup a build environment” stage.  Squares usually mean there is some sort of delay in the process due to a third-party review or inspection.  A combination of shapes is a combination of processes.  For colors, I started by coloring everything green, meaning the process is probably serviceable as is.  Yellow means there is a delay in the process.  Red means that the process is broken.

I also created a number of other illustrations you’ll see below.  All are open for discussion and your remarks.  In the comment section of this blog, just point out where you think I am wrong or we need changes.

Here is the diagram of how a localizer updates a localization, say from Firefox 2 to Firefox 3.

…reporting a bug…

…fixing a bug…

..and the last step in the process.

How have I used these?

Once I understood the process a bit more, I started to schedule meetings with people like Mic and Pike.  I also made an effort to contact members of the community to see where we could develop tools.  I used these illustrations during meetings to ask others to point specifically to where they think a tool could be inserted to fix a problem.  Sometimes it’s hard to correctly assess one’s own work, but I do think the illustrations helped us focus.

Next steps?

I’ll continue to blog about where we have progressed.  We have a number of proposals either in creation or that we have reviewed.  We’re getting closer and closer to funding something that will help localizers work on localizations.  In the next post, I’ll describe a bit about who these tools should target, what we are looking to fund, and what we have seen/heard from the community.  It’s not unreasonable to think that we might fund community work around one, two or three ideas, depending on the focus.  It will depend on value of the tool, how many will use it, who it will help, and a set of other outcomes we are defining right now.

Our goal is to find a way to do a lot with a little (leverage…again…), and l10n tools development definitely fits into that.  I’ll do my best to continue to highlight the process so you have a chance to comment and contribute.