Continuing from the discussion in bug 730625, here's what I'm thinking: * Revamp the code in browser/components/preferences/languages.js so that it can process language tags à la bug 730209 and bug 741842. * Include every language in toolkit/locales/en-US/chrome/global/languageNames.properties by default. * Use intl/locale/src/language.properties only to: ** Include more specific language tags (with regions, scripts, etc.) ** Turn off a language from languageNames.properties * Remove the l10n strings 'languageCodeFormat' and 'languageRegionCodeFormat' from /browser/locales/en-US/chrome/browser/preferences/preferences.properties, since: ** Each subtag name is its own independent entity, so the combination of them all should not need to be localized. ** We'd need a whole bunch more strings to cover the possibilities BCP 47 support would allow. ** Nobody ever seems to localize them anyway. None of this should be a problem, except if there are other parts of the code that use language.properties. A quick search didn't turn up anything specific, but there are a number of references to including the file in mobile builds. (That is, the file is included, but I didn't see it ever being used.) Thoughts?
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 3 days ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.