Cool features and localization
Thanks to Mozilla Labs awesome hackers, we can now enjoy restartless extensions à la Jetpack, and sure this is a cool feature.
One of the most recent extensions of this kind from the Prospector series, is Query Stats. I noticed there are some interface strings bundled in an innerHTML to be found in the bootstrap.js file
Some strings nested in JavaScript code
Now my question is: how are we supposed to localize such an addon?
Is it worth doing it?
Yes, I know: Jetpacks and restartless addons have a very limited number of interface strings or no interface string at all, and Prospector series are mostly experimental, targeting the power user (though I suppose the more mainstream they are, the more useful data they can bring), so i18n may not seem necessary.
I would simply object that restartless addons will probably have a growing success in addons developers community, which is good. But restartless addons with important interface will surface (to me even limited interface is important, but this is another question).
No JavaScript, thanks
Here in BabelZilla we are processing typically .dtd and .properties files, html and xhtml too. But we are definitely not willing to have javascript files uploaded. Moreover we want to lower the entry barrier to translation and we don’t want to ask translators to slalom between javascript functions and variables and translate only strings in code without affecting the syntax.
The right moment?
One little flaw in development makes things more difficult afterwards: localization issues almost always came second as an annoying appendix for real core dev. Localization rises technical issues that should be taken into account right from the beginning of the devlopment process, otherwise it makes things much more complicated (think of the smart and tremendous localization efforts on Ubiquity in the past).
Who can help?
So I would suggest it is due time to think about i18n (hey l20n welcome too!) for this new and promising generation of addons.
Fortunately, and that is why I really love the Mozilla community, there are always brilliant minds who are one step ahead in development and conceive projects that tend to answer questions even before anyone think of asking them 😉
-Please let us know.
Until bug 564667 (I think) is fixed, restartless extensions will have to manage locales themselves. And, well, it sucks.
Restartless add-ons don’t necessarily need to have no/little interface. Perhaps with the bug jr pointed out, it might be difficult right now. But, I think it shouldn’t be too bad to get additional files and register them with a string bundle.
I know resources can be registered dynamically to some uri, so in this case it would be to the add-on xpi. Something similar could probably be done with chrome and/or locales?
Hi Goofy,
localizing innerHTML is one of the biggest challenges we’ll be facing in the future. It’s conceptually tough, as it’s full of HTML with it’s block-vs-inline display challenges, plus, it’s not accessible to any of our existing l10n technologies.
We’re thinking about supporting l20n in some sort for HTML, including innerHTML, but it’s all history in the making right now.
But yeah, innerHTML is the worst of all problems for i18n and at the same time the best tool of prototyping code in HTML. Thus, really hard.
😀 thanks Axel for making a fool out of me. Though I am goofy, I am quite aware the issue I mention is but a very minor problem in the vast much more ambitious plans you coders are conceiving.
If you can have time to waste with irony, perhaps you will have one minute to explain with human-understandable sentences where and how the strings from a jetpack can be localized or shall we wait for l21n?