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

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

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

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.

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!

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

Another thing: How well do you know how the answers look for our existing tools?

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

It’s not perfect, but people are contributing translations.

Ian