Evaluating the l10n tools proposals
January 16th, 2008 by seth bindernagel
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.
At Songbird we too the approach of building a web based tool for editing strings.
It’s not perfect, but people are contributing translations.
Ian
Ian, Can you share the tool with us? I’d love to take a look.
The Songbird web tool is a good start but I find it very difficult to use (I know you are improving that
).
There are two different targets for a l10n tool:
1. Translators
2. Translators with technical skills
A tool for 1 could be nice and easy, like for example launchpad, but it’s difficult to create a web based system with the same features than Mozilla Translator.
A tool for 2 could be very robust but not easy to use for non-tech users.
Personally, I think that a l10n tool should have the best from a tool like Mozilla Translator and the best from an easy-to-use tool like launchpad.
I know that it’s difficult but dreaming is free
I’m not too sure how good it is to create a new tool tied to the Mozilla DTD/properties formats when we might switch to a different format with L20n with Mozilla2. I’m not yet too sure how likely it is to really get L20n up and running there, Axel will know more, but we definitely should have it in mind when looking into tools.
Another thing: How well do you know how the answers look for our existing tools?
@Nukeador:
Thanks for the comments. I think we are trying to be very experimental…call it dreaming! We want to have a tool that can be dynamic and help many of the localizers. If you have some more depth to your idea, email me sethb at mozilla dot com. We’re trying to find the best ideas and we are not locked down to supporting just one proposal.
@KaiRo:
This is a great point and has caused me to tread fairly lightly, but we also need to start this process. Ideally, we’ll have a solution that can work with Mozilla 2…in fact, it’s a must. Perhaps designing a tool that uses a different file type altogether…separate from DTD or from Mozilla2. Then, create a file converter to whatever format is necessary? I’ve seen this already with some translation tools that use .PO files. Here is a helpful link to the Translate Toolkit, which I am sure you have seen, but I’ll post it for everyone: http://translate.sourceforge.net/
Maybe projects like these are good starting points.
To answer your last question: I think we know fairly well how our existing tools work. If nothing else, there are many vocal members of the l10n community who continually seek support on various issues. Pain points have been highlighted on our Mozilla Wiki. And, we receive many anecdotes from people who want to localize…but just can’t figure out the process with some attention. This type of initiative shouldn’t be lost because our process is too complex to figure out. We should try to make something that is an option tool that makes life easy for those who find the tool helpful.
Hi!
In my opinion, a good localization tool should be targeted to non-techies, because there are a lot of people who could help translating, but they become discouraged as they stumble along the steep learning curve.
A web-based tool with workflows would be great! Imagine you could localize your browser from inside it!
So I don’t think that a good tool for po or dtd/properties will be a good tool for l20n. There’s a paradigm shift from what po and mozilla do onwards to l20n, and that will require different UE tricks.
And we don’t need more file formats and conversion, but abstraction of algorithms from data formats, compatible software licenses and then cherry pick code and algorithms and integrate them in whichever UI/UE we provide.
Hi,
I’m Ricardo Palomares, from es-ES L10n team. I think I have already exchanged most information about this topic in the round of messages you did some months ago, but anyway…
- I don’t really like web-based interfaces. They usually are slower to work with the keyboard (shortcuts tend to be lengthier or don’t exist at all), and are definitely slower than a desktop application. They may be better and more appealing for complete non-techies, but (and this is my prejudice) I feel that too many people will want to help, without caring for terminology consistency, good grammar and spelling, and so. A bit of learning curve means that people willing to go through it has real commitment.
- I’m in the never-ending, always-stalled process of writing a DB-based replacement for MozillaTranslator, also in Java. The long-term idea would be to architecture the application so it could have a Java back-end providing webservices so people could write front-ends in other languages. Unfortunately, I can’t see right now a point in the future when I will be able to see this part working. Besides that, the application will have (this for sure) a glossary manager and translation memories. I also want to provide means to automate repository check-out and commits, though at this time I just aim to be able to launch shell scripts, not bundle CVS support. Of course, it will be open-source licensed.
- The good part of being so late is that I’m open to include L20n if I manage to see more of it (I will talk to Pike when I’m ready to undertake that part of development, which I hope to be not so far).
- I face two big problems in this effort: I need to do it alone, because it will be my final year project in the University; and, since I’ve been “detached” from programming evolution in the last ~15 years (I finished classes just around 1994, a year before they started to teach OOP), I find huge challenges in every small step I do, which gets worse as I have little time to progress.
Again, I think I’ve already sent you some information in the past. If you want me to comment on each point in your list, just let me know.
Ricardo
Disclaimer: I was the original developer of the translate toolkit and Pootle.
Just a note to Axel/Seth: The translate toolkit does in fact provide a good API to different translation formats - it just happens to be used to convert between formats because the most common editing tools are for PO format, and a lot of translators in other projects are more familiar with those.
But we did a lot of work to make sure there’s a good API that handles a wide range of translation formats (including of course DTD and properties) and I’m pretty sure it could be easily extended to handle l20n using the same API.
All in Python of course
Thanks for the input David. Reading your comment:
“I’m pretty sure it could be easily extended to handle l20n using the same API.”
is encouraging. The existing API might be able to handle any changes that occur with l20n. That’d be great!
If not, it seems that the toolkit could be changed and updated to work with however Mozilla 2 might change the way we do l10n now.
Your comments are really helpful.