1204660 - Introduce a temporary proxy for l20n.js to mimic l10n.js API

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::L10n, defect)

Description

[Zibi Braniecki [:zbraniecki][:gandalf]]

As we migrate apps to use l20n.js, we encounter code that has to work with both, l10n.js and l20n.js until we complete the migration.

Such code would require less manual patching if we introduced a proxy for l20n.js to handle as much of l10n.js API as possible.

We will remove this proxy as soon* as we're done with the migration.

*) soon may be an arbitrary unit of time and may not happen soon at all

Comment 1

[Zibi Braniecki [:zbraniecki][:gandalf]]

Attachment: pull request

I didn't add:

 - mozL10n.ready - I'm waiting for your solution to missing events
 - mozL10n.qps - I'm waiting for QPS API in L20n.js
 - mozL10n.languages - It would be hard to mimic because it's synchronous in l10n.js. I have some hope that we may not need to mimic that. If we'll end up needing it we can revisit.
 - mozL10n.get - d'uh!

Comment 2

[Zibi Braniecki [:zbraniecki][:gandalf]]

Stas, can you review this? It would help with Music-NGA web components.

Comment 3

[Staś Małolepszy :stas]

Comment on attachment 8660932 [details] [review]
pull request

I like the idea, but I'm giving it an r- because I'd like to see an updated version of the patch.

Off-bug, you mentioned that a Gaia-specific entry point would make it possible to remove the support for the .properties syntax in the Web variant of L20n.  That sounds tempting but I'm not sure if I see a way of doing that, what with the es6 modules being imported statically.  

Let's leave that aside then and discuss other benefits and disadvantages of having a separate entry point here.  The most important disadvantage as I see it is that we're introducing a risk of code getting out of sync.  I.e. a few months from now we may update src/runtime/gaia but forget to update src/runtime/web or the other way around.  Tests would help, but in general, I'd like to avoid code duplication where it's not needed.

Would it be possible to build the Gaia entry point in the following manner?

  // import the web runtime for its side-effects
  import * from '../web';
  
  // shim mozL10n for backwards compatibility
  navigator.mozL10n = { … } ;

This would give us the obvious benefit of keeping separate things separate which I like.

Also, should we also add mozL10n.ready?

  ready: callback => document.l10n.ready.then(() => {
    document.addEventListener('DOMLocalized', callback);
    callback();  
  }),

Comment 4

[Zibi Braniecki [:zbraniecki][:gandalf]]

Comment on attachment 8660932 [details] [review]
pull request

Updated to your feedback and added qps.

Comment 5

[Staś Małolepszy :stas]

Comment on attachment 8660932 [details] [review]
pull request

r=me, thanks.

Can you also change the following line in gruntfile.js before you land, please?

https://github.com/l20n/l20n.js/blob/5326af94a88653cf7844752cc29499e547eb40c6/Gruntfile.js#L80

This should build babel:gaia now.

Comment 6

[Zibi Braniecki [:zbraniecki][:gandalf]]

Commit: https://github.com/l20n/l20n.js/commit/32a6387ccefa482c4262d64a02368b06f6cb4e25

Comment 7

[Zibi Braniecki [:zbraniecki][:gandalf]]

Filed bug 1250628 to track removal of the reverse proxy