927855 - [apps][keyboard] manifest.webapp not fully localizable

Status: RESOLVED WONTFIX

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

Description

[Axel Hecht [:Pike]]

The sub-keyboards in the keyboard app are exposed via entry points. Only the en-US one of those uses the pattern for a localizable entry point, and is exposed to l10n, the others aren't.

    "en": {
      "launch_path": "/index.html#en",
      "name": "English",
      "description": "English layout",
      "types": ["url", "text"],
      "locales": {
        "en-US": {
          "name": "English",
          "description": "English layout"
        },
        "zh-TW": {
          "name": "英文",
          "description": "英文鍵盤"
        }
      }
    },

vs

    "en-Dvorak": {
      "launch_path": "/index.html#en-Dvorak",
      "name": "English (Dvorak)",
      "description": "Dvorak layout",
      "types": ["url", "text"]
    },

We don't need to actually embed localizations, just exposing the name and description as "locales":{"en-US":..} will do.

Adding l12y as we can't fully localized the keyboard right now, and request koi as this also affects 1.2

Comment 1

[Axel Hecht [:Pike]]

Attachment: add "locales" and "en-US" key to all entry points

Rudy, I guess you're a good reviewer for this?

I did check that it's picking up localizations from hg if I manually just add them to apps/keyboard/manifest.properties, alongside of checking that the one french entry I made up also shows.

Comment 2

[Ivan Tsay (:ITsay)]

Plus it since this is expected behavior. Since this one is under review, I expect this bug will be finished in sprint 4. Assign target milestone to 1.2 C4 accordingly.

Ivan

Comment 3

[Axel Hecht [:Pike]]

Reading bug 884752, I'm not sure we should actually do this. I guess we'll find out soon, though.

My current thinking is that we'll stick to the keyboard layouts being in their native name only, and that we'll generate the entrypoints at runtime.

Comment 4

[Tim Guan-tin Chien [:timdream] (please needinfo)]

IMHO layout names should be localizable, as a parity to other OSes, but if that's what it takes to solve koi+ I won't stop you from doing that.

Comment 5

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

Comment on attachment 819048 [details] [review]
add "locales" and "en-US" key to all entry points

Do we need still need this patch if we want to take the approach in Bug 884752, i.e. show the keyboard layout name in its native language?

I'll clear the review flag first, please set it back so that I'll get notified.
Thank you.

Comment 6

[Corey Frang [:gnarf]]

The properties are already localizable, the ManifestHelper ensures that they are.  I'm not saying we should localize them, but we can very easily.

If the localization team needs the "locales": {} to be there for each of these for their tools to properly find the right values, I say we just add it and take the patch that is already here Rudy.

Comment 7

[Axel Hecht [:Pike]]

I'm resolving this WONTFIX, because I think the approach we're taking in the jb dictionary bug about factoring this out and just showing the native name of the keyboard is the right approach. In particular if it comes down to extensibility.