In my add-ons, i need to access the entire set of translated strings for the current locale.
When using cfx, doing
var l10nData = require("@l10n/data");
gives me exactly what i want: the current locale and all the strings as an object.
When moving to jpm, the same code returns null.
Any suggestion, workaround ?
Thanks.
I cannot find any reference to the “data” folder on https://developer.mozilla.org/en-US/Add-ons/SDK/Tutorials/l10n or https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/l10n.
Have you tried
var l10nData = require("sdk/l10n/data"); ?
I just gave it a try and i get an error
Module `sdk/l10n/data` is not found at resource://gre/modules/commonjs
By the way, this is different from require("@l10n/data") which does not say the module is not found but simply returns null.
Hm, it was worth a try. Do you have a documentation page for require("@l10n/data")?
No, this is something i got reading Firefox add-on SDK source code.
Now, i’m wondering if it’s worth moving from cfx to jpm given that there will soon be changes that will break everything anyway. Is cfx supposed to still be around until WebExtensions becomes the recommended way to develop extensions ?
Michel, I’m one of the folks doing l10n apis at mozilla. I don’t have any background on the sdk apis, but nevertheless, I’m curious:
What are you actually doing?
I develop a popular add-on called Video DownloadHelper.
This add-on includes a large number of various UI panels, with support for 14 locales. All those panels are built the same way, over angular.js, and use a very convenient localization method which requires the locale strings to be passed to the panel as a hash object as soon as it is created. Hence my need for accessing the whole strings set from the chrome part of the add-on.
I may have missed things, but i do not understand why the l10n add-on SDK module only provides a get() method. Having also a getAll() would make sense in my opinion, along with a getCurrentLocale().
We’re trying to get away from APIs that need “all of l10n is OK”. The APIs we develop going forward will assume imperfect localizations with missing strings, and asynchronous APIs that allow to do runtime fallback.
The challenge you’re facing is to use one API half way and another API the other half. That’s always gonna be clunky, I’m afraid.
I’d suggest that you try to do one or the other. Either use angular’s l10n API, or the sdk one.
I cannot use the pure SDK l10n since i need to access some locales in Javascript from content code and i also don’t think you can use Firefox data-l10n HTML attributes along with angular HTML templating.
I cannot use the angular l10n API, since i also some locales from the chrome part of the addon which does not load angular.
So i used Firefox localization plus generic angular mechanisms to display localized strings when needed. And this worked very well until the feature that allowed accessing all translated keys was removed.
I ended up writing my own module to replace @l10n/data that loads the appropriate .properties files string bundles. This seems to work ok so far.