Axel Hecht Mozilla in Your Language

I’m hacking on some tool that indexes the localizable strings in our apps.

One of the fall-outs could be a glossary tool, i.e., which terms in Firefox, Thunderbird, etc should localizers bother to get consistently translated.

Which raises an interesting question, where do you draw the line? What’s a good metric to use to define a glossary? Are there glossary-based applications that don’t need a cut-off at all?

Insights welcome.

There isn’t much news on the localization tool front that I started at MozCamp in Berlin, but I’ve got some more questions for the web tool guys among you. As any good project, a localization editor should stand on the shoulders of giants, so I’ve been looking at Orion, Cloud9/Ace, and etherpad-lite. All of them got parts right, and I try to gather some input what it’d take to bring home the rest. I’ve set up an etherpad each for you to type to,

• Comments for Orion
• Comments for Cloud9 / Ace
• Comments for etherpad-lite

A bit of context: Localization is editing code by people that don’t (necessarily) code. An editor needs to take an extra step to make breaking things hard, and editing the right pieces easy. There’s also a host of content assist available to suggest translations, spell checking, glossaries, etc. Which opens two paths: You offer forms, and your localizer will never learn what’s happening in real life, or you drive a code editor beyond what the programmer of that code editor ever needed herself. I would love to try the latter again, this time on the web.

So, if you have some experience with tweaking, wrestling, extending, stripping any of these, or with one I missed, I’d be thankful for your input.