• Evaluating the l10n tools proposals

    January 16th, 2008 by seth bindernagel with 10 comments »

    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.