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,
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.
There’s yet another update to compare-locales, we’re now at 0.9.4. Please update your local installs with
pip install -U compare-locales
Changes since 0.9.3 are:
% as error. Sadly, there’s not much more the parser reports than Invalid Token, but at least it says something. You need to escape that as %.<!ENTITY "reference to &ƞǿŧ;-known entity">. Unicode is hard.Powered by WordPress