Proposal: declarative localization of title in contextMenus.create() and contextMenus.update()

[bershanskiy]

Proposal

contextMenus.create() and contextMenus.update() should accept title string which has the format __MSG__${stringId}_ and automatically resolve stringId from the relevant _locales file.

Motivation

As of now, developers typically need to write boilerplate code like:

  chrome.contextMenus.create({
    id: 'id',
    title: chrome.i18n.getMessage('awesome_menu') || 'Awesome menu',
  });

This || ensures that if a particular menu name string was not translated, there will be some default fallback. This is not just inconvenient, but also prone to (minor) bugs when the title is updated in _locales but not in code, when the default locale changes, etc.

Also, this declarative manner would simplify the handling of the extension locale change introduced in #258. (Browser will be able to update the content menu labels automatically without the developer having to listen for i18n.onLanguageChanged and update menus manually.

Solution

Similarly to localizable extension manifest keys, support __MSG__${stringId}_ format in title property of arguments passed to contextMenus.create() and contextMenus.update().

[carlosjeurissen]

As for the || fallback, I'm not so sure how the __MSG__${stringId}__ is supposed to solve this. It actually makes it impossible to have a fallback using this syntax and is thus a less powerful way of setting the label.

There exist several more APIs which set text. Like the action.setBadgeText and action.setTitle APIs.

Something to consider is the additional effort the browser has to do on each API call, and how it needs to revisit its uses everywhere in the UI once the language gets changed. While the extension author can simply use the i18n.getMessage() API right now.

Using the __MSG__${stringId}__ syntax for this would also not be backwards compatible.