8235af22db
Why? * Because i18n sucks multi-browser, especially on Chrome. * What's more, this will allow overlaying "incomplete" locales with missing strings over the base locale and get a semi-translated one, which probably is better than nothing. * Additionally we kinda need that implementation anyway for node-based tests. * Also, while not currently implemented, it could allow (hot) reloading of locales, or loading external ones, which would help translators, or providing an option to the user to choose a locale. * And finally, not calling i18n will avoid the "context switch" into browserland. Some implementation details: * Before code can use a locale, it has to be loaded. Sadly sync loading is not really supported. So `await locale` or `await localize`. * Background force reloads locales right now, and caches them in localStorage. Windows will look into localStorage for that cache. * The locale loader will not verify locales other than some rudimentary checks. It is assumed that shipped locales where verified before check-in.
17 lines
537 B
TypeScript
17 lines
537 B
TypeScript
"use strict";
|
|
|
|
// eslint-disable-next-line @typescript-eslint/no-var-requires
|
|
const polyfill = require("webextension-polyfill");
|
|
|
|
export const {extension} = polyfill;
|
|
export const {notifications} = polyfill;
|
|
export const {browserAction} = polyfill;
|
|
export const {contextMenus} = polyfill;
|
|
export const {downloads} = polyfill;
|
|
export const {menus} = polyfill;
|
|
export const {runtime} = polyfill;
|
|
export const {storage} = polyfill;
|
|
export const {tabs} = polyfill;
|
|
export const {webNavigation} = polyfill;
|
|
export const {windows} = polyfill;
|