This removes legacy locales from the extension. The individual commits should be self-explanatory.
The code will change again, when the legacy XUL pages are converted to WebExtension HTML pages, but the concept remains. JavaScript can access the locale data directly (Experiments via extension.localeData.localizeMessage() and WebExtension code/pages via browser.i18n.getMessage()), but there is no automatism to replace strings in markup and the common pattern is to use __MSG_*__ placeholders (a.k.a. WebExtension locale strings), which are manually replaced during page load (using the i18n.js script).
The options page will be converted next from XUL to HTML and I would not put too much thought into why its window is so large at the moment. The important part for this PR is to verify that all user facing strings are correctly shown.
This removes legacy locales from the extension. The individual commits should be self-explanatory.
The code will change again, when the legacy XUL pages are converted to WebExtension HTML pages, but the concept remains. JavaScript can access the locale data directly (Experiments via
extension.localeData.localizeMessage()
and WebExtension code/pages viabrowser.i18n.getMessage()
), but there is no automatism to replace strings in markup and the common pattern is to use__MSG_*__
placeholders (a.k.a. WebExtension locale strings), which are manually replaced during page load (using thei18n.js
script).The options page will be converted next from XUL to HTML and I would not put too much thought into why its window is so large at the moment. The important part for this PR is to verify that all user facing strings are correctly shown.