WebExtensions and localizations, or i18n


the l10n team at mozilla took a look at https://developer.chrome.com/extensions/i18n.

We think it’s a good idea to have this API for compat with chrome extensions.

For Firefox, though, we plan to contribute a more powerful API.

We’re also in touch with the folks on the Chrome side of things, and from what I hear they’re not full of pride when it comes down to this API.

Our current focus right now is to spear-head that on fx os, and with gofaster and desktop, there’s another one that’s time-pressing. If you’re interested in helping out, get in touch with the team on the mozilla.tools.l10n list, that’s where we have our conversations.


CC @billm

Is the more powerful API xhtml files with dtd? That is much faster, then i18n.

I don’t expect us to use DTDs.

I actually expect us to use L20n, which does have bindings for html localization. From a developer’s POV, that’s just as easy: You set an attribute with the l10n id, you include references to the localization files, the l20n api, and boom, you have localized html (without the X, too).

Is it as fast or faster then the xhtml ones? Those are instant they seem. i18n you can notice the localizations changing on page load on slower computers.

We’re not seeing flicker on fx os devices with this approach.

Sounds cool I like the approach of making firefox more powerful. So extensions from other browsers can easily port to firefox, but firefox addons cant go to other browsers. I take pride in my addons not being available for other browsers. :slight_smile:

Hey all does i18n and the other tech you are mentioning support loclizing css as does xhtml/dtd(s) method? I use xhtml/dtd(s) method for localizing the css content (works great too, super fast no lag at all), no other way i could find.

We generally have a hard time getting translators to not translate CSS

breite: 75Füsse;

so we’re trying to move away from that.

What are you using localized CSS for?

Note: You might get by with using language selectors in your generic CSS to implement one-offs. Or you can put a CSS file into the localized content. This is what gecko does with intl.css, but it’s really hard to maintain those in practice.

Thanks @Pike,
I don’t meant they should translate the css words, but stuff within the content.

With dtd’s its a no brainer, its just an entity, I use it extensively to localize content. My translators on babelzilla dont even know they are translating for CSS, (which I think is appropritae, translators shouldnt worry about worry about the technicalities of usage).

Here is where I use dtd loclization in my production code:

You’l see in this section of style:

 .stalled a.act-toggle:not(.active-me):hover:after

But it will have only content in its block body. Thats because the rest of the style is in the .css file with the same .stalled a.act-toggle:not(.active-me):hover:after, so I just “overload/plugin” (I guess you can say) the same selector the same selector but just with content.

I have found no other way to localize the CSS. Never needed to, this way was so easy.

I agree your mentioned workaround is very difficult, and maintaining it is a scary though, this dtd method here is a breeze. Whatever we move to, we should have an equally easy, if not easier method for localizing the content values in css.

Asked around, and we actually have a thing that’s safer in gaia:


And then you translate the attribute like any other attribute.

The benefit is that CSS-special characters and typos can’t break or modify your stylesheet.

Thanks for digging in!

Ah I was afraid of that. (Setting attribute on element to localize content)

Setting the attribute on every element that needs this style is not feasible no? Kind of defeats purpose of selectors/<style> no? This method is equivlaent of inline-css, which is no-no :frowning: If content is dynamic based on style each element needs to have multiple attributes in case a certain selector is applied to it. I think this method is a work-around rather then a solution. If it was encountered, I feel it would be easier tofix then it would to maintain attributes on elements. Devs will have to keep in mind that a selector will hit this and it needs the attributes as the build onto their software etc.

I agree though with your characters breaking, however I haven’t encountered that in years, and should be much easier to fix, then it would be to maintain attributes on everything the various selectors will be hitting.

For example if we want to stylize the after element of <label>s in a form, we dont want to go setting attributes on each of those no?