1210721 - Make view.pseudo async

Status: RESOLVED FIXED

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

Description

[Staś Małolepszy :stas]

An async view.qps[code].translate will make it possible to keep the whole qps logic in the service.

Comment 1

[Staś Małolepszy :stas]

Attachment: Pull request

Comment 2

[Staś Małolepszy :stas]

We need three things from document.l10n.qps to be useful:

 1. a list of all available qps codes (to check if something is a qps),
 2. a function to pseudotranslate strings into a given qps, and
 3. names of each of the available qps, pseudotransled into those qps.

I suggest the following API:

  1. an object whose keys are qps codes:

    document.l10n.pseudo = {
      'qps-ploc': …,
      'qps-plocm': …,
    }

  2. the values on the above object are translation functions:

    document.l10n.pseudo['qps-ploc']('Hello');
    // -> Promise: Ħḗḗŀŀǿǿ

  3. a special-case of the translation function is when you call without any arguments;  the localized name of the qps is returned

    document.l10n.pseudo['qps-ploc']();
    // -> Promise: Řŭŭƞŧīīḿḗḗ Ȧȧƈƈḗḗƞŧḗḗḓ

This allows us to drop the .translate() and .name properties on qps objects.

(I also suggest using the name 'pseudo' in lieu of 'qps' because it's more widely understood; e.g. http://unicode.org/cldr/trac/ticket/3971).

Zibi, what do you think?

Comment 3

[Staś Małolepszy :stas]

Comment on attachment 8668880 [details] [review]
Pull request

This turned out to be easier than I thought.  Canceling the needinfo in favor of a review request.

I'll need to rebase this against bug 1210719 or the other way around.

Comment 4

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

Comment on attachment 8668880 [details] [review]
Pull request

Overall, I like it.

My only concern is that you seem to choose implicit over explicit in a scenario that is not performance related - API for pseudo.

I think I preferred the explicit {name, translate} pair over the duality of a single function with or without an argument.

My reasoning is that since it's not performance related, and not an API we expect to be widely used, making it less self-explanatory on top of that feels unnecessary.

But either way, looks good to me.

Comment 5

[Staś Małolepszy :stas]

You always care about the number of objects created, so I assumed you'd like the implicit case more.  Just to make this clear, would yo uprefer this:

this.pseudo = {
  'qps-ploc': {
    name: () => getPseudoName(this, 'qps-ploc'),
    translate: str => pseudotranslate(this, 'qps-ploc', str),
   },
  'qps-plocm': P
    name: () => getPseudoName(this, 'qps-plocm),
    translate: str => pseudotranslate(this, 'qps-plomc', str),
};

over the following?

this.pseudo = {
  'qps-ploc': str => pseudotranslate(this, 'qps-ploc', str),
  'qps-plocm': str => pseudotranslate(this, 'qps-plocm', str),
};

?  If so, should we create a lightweight Pseudo class for the first example?

Comment 6

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

> You always care about the number of objects created

I do care deeply about the number of objects and string, and about the amount of operations we add to every app execution.

But I only care about it for a typical - user-centered scenario. Since Pseudo is not part of that, as long as we don't increase the complexity for non-pseudo code flow, I think I prefer not to sacrifice explicitness.

What do you think?

Comment 7

[Staś Małolepszy :stas]

I'm all for being explicit here;  I only chose implicit because I was anticipating an r- b/c of the object count ;)  What's your take on a small Pseudo class with the translate and getName methods?

Comment 8

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

No opinion on class vs. object.

Comment 9

[Staś Małolepszy :stas]

OK, thanks for the review.  Landed in https://github.com/l20n/l20n.js/commit/bedc9f2fa94f0d787d78fb246766073111afa28e.

In the end I went for lightweight Pseudo objects with two methods: getName and procesString, both returning entities.

Comment 10

[Staś Małolepszy :stas]

> In the end I went for lightweight Pseudo objects with two methods: getName
> and procesString, both returning entities.

…both returning promises.