chrome.i18n.getMessage not a function

[Jason Savard]

I am testing using the "service_worker" in manifest v2 in preparation for v3.

But it seems the getMessage function does not exist from within the context of a Chrome extension's service worker. Is there an alternative?

My use case is simple I generate a context menu which needs to be internationalized.

Note: It does exist and work from within other extension pages.

[Jackie Han]

You're right. I searched a bit and found that someone has already reported this issue.

See #1175053 and #1159438 

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/6c8b3b99-8a19-4e3f-9b38-ebf2e5f4e9c5n%40chromium.org.

--

Jackie Han

[Simeon Vincent]

Thanks for calling out those bugs, Jakie. I just passed them to a colleague to hopefully get eyes them soon.

Cheers,

Simeon - @dotproto

Chrome Extensions DevRel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAAgdh1%2B4oZzynSO8kB25izn5QcnrupManTZAF7FZF9sdXAkATQ%40mail.gmail.com.

[Kamer DINC]

Any update about this issue? 

Im still getting error from background service worker.

[Jackie Han]

chrome.i18n.getMessage() is a sync method that needs to read files, so I guess it's not suitable for (async) service workers.

Workaround is not difficult, just don't use it, use your custom method. Basically like this:

1. write your getMessage(key) function, that returns a string from memory or fetch from local files.

2. use navigator.language to decide which language to use.

[Kamer DINC]

Thanks a lot. I will try it

[Carlos]

@Jackie Han Using navigator.language or chrome.i18n.getAcceptLanguages is not gonna provide the same result. As chrome.i18n.getUILanguage and chrome.i18n.getMessage use the language of the browser itself. Not the languages websites are requested in.

In addition, going for a fetch to _locales won't consider language fallbacks. Currently getMessage can go from es_419 to es to en. And many webextension authors make use of this fallback mechanism to reduce the extension package size.

Supporting chrome.i18n.getMessage has been proposed in the w3c webextension group. See:
https://github.com/w3c/webextensions/issues/93

Op vrijdag 14 mei 2021 om 12:46:13 UTC+2 schreef kame...@gmail.com:

[GroupNinja Official]

Hey jason i use your extension "Explain and send screenshots" i need help one person submitted fake dmca report and now my extension is down i submitted the counter notice but it will take 10 days 

and even then i do not know if he can just put another fake dmca report 

what to do?

[Jackie Han]

Carlos,

So I said it's a workaround method (if there is no other way), and didn't say it is exactly the same implementation mechanism.

The browser UI language is usually the language of the operating system or specified by the browser's startup parameter.

navigator.language(s) is also usually the languages of the operating system by default and users can customize them in the browser settings(chrome://settings/languages). This is also used for the Accept-Language HTTP header.

Although navigator.language may be different from the browser UI language, it is still an acceptable language for users.

Compared with the front pages, the service worker or background page usually requires a small number of messages. So developers can write messages in JS code directly if they don't use chrome.i18n.getMessage() .

By the way, chrome.i18n.getMessage() can't support passing a preferred language as a parameter. If you want to let users change your extension's language independently (don't change browser UI language or OS language), you can't rely on chrome.i18n.getMessage().