This is my thinking. There's some overlap with other folks around l10n and l10n drivers, emphasis on some.

There are a few aspects where we're loosing wall-clock time, and I'll go through them one by one. I think we're struggling in rallying existing contributors for a particular task. Once people actually translate, the actual translation tools are awkward. And finally, it's often easier to just do it yourself than to take contributions.

Rally the troops

This is anything among rally the troops, engage with contributors, resourcing a statement of work.

How do localizers find opportunities to contribute? If they need to come to us, our wall-clock time is limited by them coming. We need to reach them where they are. We need to break out of dashboards and feeds that people have to poll, and be in their own inbox.

We've learned that inbox can be anything from their personal email, an RSS feed, a mailing list, facebook group, a twitter poke.

There's a huge opportunity for tooling here to keep track of who is who, where to reach them, and to offer mozillians that want to reach out to l10n a consistent interface to do so.

Contribution Management System or a Messaging Framework are punch lines in this context.

Want to help?
This is an open field without existing constraints, and really valuable.

Localization Tools

This is where localizers do their magic. This is the actual translation work, but also questions like What's new? What's still maintained? What's old? How do I test my work?

This section focuses on a few aspects. The full story takes much longer to write, and even longer to read.

Discovery and status of translation work is where dashboards are key, so continuing to develop elmo is key.

Mozilla is a source-code environment, thus we are best when dealing with that. Our existing access guidelines to source-code are really restrictive. ssh keys, passwords, basically just things that work from your own machine in a terminal. To really bring the power of the web to our source code, we should open up pathways for web tools (and others?) to have well-defined write access to our code. Not just interesting for l10n, I'd think.

Want to help?
Define a process for (web-)tools to write to version control, get buy-in throughout the org, document it

Now on to actual translation tools. There are a few, pootle being prominent for a number of communities these days. It doesn't work on our source code directly though, and the interaction is non-trivial. It's also impacting turn-around times. Source code needs to be found, updated, imported before localizers can work. Once they worked, that needs to be exported, converted, commited, pushed. Aside from being tedious to maintain, it's taking time.

Axel wants to get localizers to directly work on source code instead. There are a lot of benefits, but there's also going to be a lot of stop energy. That project is code-named Aisle.

Another aspect of being fast can be achieved with Pontoon, as long as it's working in its in-place editing mode. Localizing within the visual context can short-cut the testing cycle, and thus wins back wall-clock time that can otherwise be lost with getting its database.

Aisle

Aisle is a pathway to success, and also sounds like ILE, or Intergrated Localization Environment.

The current status is that it's unblocked, one can run c9 locally, http://cloud9-sdk.readme.io/v0.1/docs/running-the-sdk, and install the moz.aisle plugin.

There are a number of milestones ahead of the project.

Want to help?
Add javascript code to moz.aisle

Want to help?
Think about hosting/workspaces

Want to help?
:gps might have excellent ideas about how to do version control fast and cost effective

Pontoon

Pontoon support in-place editing for HTML documents. Matjaz and Osmose are currently working on this, and should at some point add more content here. For now, see the buglist.

Taking Contributions

One big timesink today is the very few contributors we have per language. There are many reasons for that, a big one being the time and energy it takes to accept other people's contribution.

In our development of tools, we need to keep an eye out on how to make reviewing and feedback easy.