1393111 - Switch back to Services.strings for devtools/shared/l10n helper

Status: NEW

(DevTools :: Framework, enhancement, P3)

Description

[Julian Descottes [:jdescottes]]

Follow up to Bug 1386616.

We have a complex mapping to load properties files in devtools, which was introduced for devtools.html.

See http://searchfox.org/mozilla-central/rev/48ea452803907f2575d81021e8678634e8067fc2/devtools/shared/l10n.js#11-34

We should try to see if we can push this complexity to our webpack helpers/rewriters and if we can use the real URLs (e.g. "chrome://devtools-shim/locale/key-shortcuts.properties") when calling the l10n helper.

The main guideline for devtools.html was that client/ files should not using chrome resources, which is why the urls got standardized. But in the case of the properties files, we still end up requesting the actual chrome:// file, so the added value is not clear.

Comment 1

[Julian Descottes [:jdescottes]]

Repurposing.

The initial goal of having a l10n helper free from chrome privileged APIs was to be able to use it directly when using devtools in a webpage. However we have an alternative for such cases, which is to use a different helper in web context and in Firefox.

We could move the current l10n.js helper, based on sprintf.js, to devtools-core and rollback to an implementation of our LocalizationHelper that relies on Services.strings. Two reasons for that:
- go back to using the real chrome:// URLs (initial purpose of this bug)
- performances

Re: performances, we are improving performances of our L10N helper in Bug 1406311. We can get the same performance improvement by using Services.strings instead of sprintfjs (and with less maintenance). 

As we would still need the current chrome-free module for tools running in launchpad, we will need to make sure both APIs are tested in the same way.