I have been trying to develop a custom Firefox dictionary add-on that bundles multiple distinct botanical word lists into a single extension using Manifest V3.
My manifest.json defines the dictionaries like this:
“dictionaries”: {
“la-x-flora-wfo”: “dictionaries/wfo_flora_latin.dic”,
“la-x-flora-itis”: “dictionaries/itis_flora_latin.dic”,
“en-x-flora-itis”: “dictionaries/itis_flora_english.dic”
}
The extension loads and functions fine, but I am running into a limitation with how the right-click spellcheck context menu handles the labels for these custom lists. Firefox strips out the private-use subtags (-x-…) and falls back to displaying only the base resolved language string. As a result, the UI just shows duplicate entries for “Latin” and “English” rather than identifying the specific datasets (WFO vs. ITIS).
Before I file a feature request on Bugzilla to propose extending the dictionaries schema to support a custom descriptor label, I want to make sure I understand the underlying behavior.
My current understanding is:
-
The WebExtension dictionaries API schema strictly requires a String: String (locale tag to file path) mapping and there is no way for the addon to provide a different display string.
-
The context menu UI generation relies on Services.intl.getLanguageDisplayNames() or similar internals to translate the locale tag. Because it can’t resolve the custom -x- private subtag to a localized string, it falls back to displaying the base language code name (“Latin” / “English”).
-
Standard extension localization tools (like the _locales folder) cannot hook into or override this internal system-level spellcheck menu translation.
Am I understanding this constraint correctly, or is there an existing, documented way to provide a user-facing label for custom dictionary tags that I might have missed?