898786 - [communication][manifest] app locales shouldn't under entry_points

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia, defect)

Description

[Evelyn Hung]

There are two apps in communication app that can be launched separately. They are specified in "entry_points" but use this way to provide localized app name:

  "entry_points": {
    "dialer": {
      "launch_path": "/dialer/index.html#keyboard-view",
      "name": "Phone",
      "icons": {
        "60": "/dialer/style/icons/60/Dialer.png",
        "120": "/dialer/style/icons/Dialer.png"
      },
      "locales": {
        "ar": {
          "name": "هاتف",
          "description": "Gaia هاتف"
        },
        "en-US": {
          "name": "Phone",
          "description": "Gaia Phone"
        },
        "fr": {
          "name": "téléphone",
          "description": "téléphone Gaia"
        },
      ...

Per description in https://developer.mozilla.org/en-US/docs/Web/Apps/Manifest#locales, "locale field overrides the matching field in the manifest." So I suppose dialer app and contact app should put their app name under "locales" with a proper override field name (I don't know what it should be). Is it a bug or new rule?

Comment 1

[Evelyn Hung]

We plan to use "entry_points" to describe a keyboard layout (see bug 816905), so want to figure out how "locales" works with "entry_points".

:marcos, can you give a comment here? Thanks.

Comment 2

[Marcos Caceres [:marcosc]]

In the current localization model, it would work like the following. Essentially, you would put new "entry_point" members under each language in "locales", and their values would be picked up automatically
for the thing you need to override. So:

{
    "entry_points": {
        "dialer": {
            "launch_path": "/dialer/index.html#keyboard-view",
            "name": "Phone",
            "icons": {
                "60": "/dialer/style/icons/60/Dialer.png",
                "120": "/dialer/style/icons/Dialer.png"
            }
        },
        "locales": {
            "ar": {
                "entry_points": {
                    "dialer": {
                        "name": "هاتف",
                        "description": "Gaia هاتف"
                    }
                }
            },
            "en-US": {
                "entry_points": {
                    "dialer": {
                        "name": "Phone",
                        "description": "Gaia Phone"
                    }
                }
            },
            "fr": {
                "entry_points": {
                    "dialer": {
                        "name": "téléphone",
                        "description": "téléphone Gaia"
                    }
                }
            }
        }
    },
    "default_locale": "en-US"
}

It's pretty hard to write this by hand. Can you flatten "dialer" a bit?

Comment 3

[Evelyn Hung]

Hi Marcos, thanks for your explanation. I don't have any idea to flatten dialer, but I can follow the same rule on defining 3rd-party IME case. (bug 816905).

@Etienne, any idea for changing communication app's manifest?

Comment 4

[Etienne Segonzac (:etienne)]

(In reply to Evelyn Hung [:evelyn] from comment #3)
> Hi Marcos, thanks for your explanation. I don't have any idea to flatten
> dialer, but I can follow the same rule on defining 3rd-party IME case. (bug
> 816905).
> 
> @Etienne, any idea for changing communication app's manifest?

Not really, sorry.
But I'm not sure I clearly understand the issue...

Comment 5

[GaryChen [:GaryChen][:PYChen][:gchen][:陳柏宇]]

Hi Marcos,
   I am Gary work on 3rd party keyboard supported feature in v1.2.
   We use new manifest in  3rd party IME case. (bug 816905) which is your suggestion in comment#3. 

   I also tested it with |ManifestHelper| (https://github.com/mozilla-b2g/gaia/blob/master/shared/js/manifest_helper.js) which is Gaia shared library to localize mainefest, unfortunately it does not work. 

   After discussed with Rudy (the keyboard app module owner), we proposed to use Evelyn's suggestion as the following:
   "locales": {
        "ar": {
          "name": "هاتف",
          "description": "Gaia هاتف"
        },
        "en-US": {
          "name": "Phone",
          "description": "Gaia Phone"
        },
        "fr": {
          "name": "téléphone",
          "description": "téléphone Gaia"
        },
       .........

    or you can see the source code in Rudy's branch https://github.com/RudyLu/gaia/blob/3rdParty_keyboard_support_commit/apps/keyboard/manifest.webapp#L15.

    We think this format is more clearly and readable, the important thing is it can be adopted with current |ManifestHelper| in Gaia.

    Do you have any comment here, Marcos? 
    Please feel free to give us some feedback.
    Thanks.

Comment 6

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Hi Marcos,

I guess the question is derived from the fact that "entry_points" field is still not standardized/documented.

Hi Marcos,

As you can see from communications app about the usage of localication for entry_points,
https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/manifest.webapp

For 3rd-party keyboard app, we'd like to sync with communication app to use the same structure.
Please let us know if you have strong opinion about this.

Thanks.

Comment 7

[Marcos Caceres [:marcosc]]

I think how you've localized entry_points and contacts is kinda interesting and more legible - which is a good thing. Be mindful that you are basically introducing a new localization model into the manifest format by doing this. 

You will need to define what happens is someone uses "locales" at the root of the manifest, with the aim to override "entry_points". You also need to be clear how this interacts with "default_locale" (if it does at all).

Comment 8

[Ivan Tsay (:ITsay)]

Hi Marcos,

It seems that you were busy on something else so that we didn't have chance to talk over the meeting today. For your additional question on this Manifest design, please post here for Gary and Rudy to have discussion with you. We really want to finalize it as soon as possible since we are approaching the milestone of v1.2 on 9/16. Thank you very much!

Comment 9

[Marcos Caceres [:marcosc]]

Hi Ivan, really sorry I missed our meeting. Was sick last night and ended up staying in bed :( If possible, let's reschedule for some time tomorrow (Wed)? Or let me know what time works. I'll be online from 9am London time.  

I might post some additional questions later today.

Comment 10

[Marcos Caceres [:marcosc]]

Discussed the proposed model on IRC. Concluded that the model is ok, even though it introduces localization on a per-object basis... kinda like a "manifest within a manifest". It's certainly more legible and probably easier to write than relying on "locales" and having to duplicate stuff over and over again (as in comment 2).

Comment 11

[BMO Automation]

Firefox OS is not being worked on