Those of you who follow the localization tales of Mozilla project know the mythical “L20n” concept introduced by Axel Hecht over two years ago.
Since then, we spent zillion hours thinking about this concept and maturing it. Every time I was working on any project – be it Verbatim, Firefox, Getpersonas, AMO, Pontoon or Jetpack L10n – I was telling myself how much better it could be, had we have L20n in place. Easier for localizers, easier for developers, easier to maintain. Did I tell you it’s faster as well?
Then, last summer, Jeremy Hiatt joined us for his summer internship and spent 3 months working with Axel and me on pushing some of the implementation concepts forward.
With the end of summer, we got again busy with upcoming Firefox 3.6 release and put L20n again in coma…
Until now.
Without getting into much detail, I can tell you that right now we’re preparing for the next, and hopefully, ultimate push toward L20n 1.0. Over the next few months you will have more than enough of blog posts and papers and demos and examples. We will be asking for feedback, presenting the syntax, experimenting with toolchain, building extensions, and slowly preparing to introduce L20n into Gecko platform and our websites.
We believe that L20n is the most crucial piece of Mozilla localization story, aligning perfectly into our core values. Mozilla is in the best position to push the localization experience to the new level, finally enabling software to speak in the natural language of the reader. Gettext is awesome, but aging technology, properties/DTD that we use in Gecko today, are limited, tens of proprietary formats (used by projects like Qt, Webkit, Apple, Nokia) just replicate the same concept. L20n shifts the paradigms of what localization is to the new level. It’s going to be big, and we hope to get a lot of people involved.
Next week I’ll start with the first demos.
p.s. those who like to read the code, may find first bits of fresh code in my hg repo. Yummy! Isn’t it? 🙂
3 replies on “The new era of software localization is approaching”
Looks interesting. Hopefully this won’t leave remote-XUL out in the cold like the current DTD-based approach does. We have to inline our DTD file on the server side for every page request on our remote-XUL app because of bug #22942, adding hugely to the download size, so any system that lets us easily avoid that would be a godsend.
YAY!!!!!
Guess what I just cloned 😉
Do we have some docs on how to use those things? Is something of the code ready for testing use already? I’d be mostly interested in the PHP stuff for now, actually – or maybe JS if there’s an in-Mozilla-chrome way of using it…
Jeremy just showed me first mockups with XUL ContentSink working with L20n. My approach (there’s a xulrunner app in my repo) is a JS way to work with it.
For PHP I have some early lib elements in the repo as well.