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.

Trackback URI | Comments RSS