Some random notes on extension localization update; shaver made me do it.

• Locale packs for extensions should exist
  • Probably should be marked as depending on the extension to be localized, or something
• On extension update, if a corresponding locale update is not available, indicate this to the user.
• Use the localized strings where the strings exist, and fallback only if it does not
  • If the only unlocalized string is obscure, using a partially localized version is much more preferable to completely not localized
• Fallback should be according to the user's locale prefs (or region or something), and to the untranslated version (as came in the extension, not necessarily en-US) if not possible

Extension Locales bug 245946

There are two ways that extensions can be localized:

1. The extension author can include any number of locales directly in the extension. Localizers send extension authors localizations for inclusion in the extension. This is the traditional way to localize extensions, but it has significant coordination overhead for extension authors and localizers. Online collaborative l10n tools such as http://babelzilla.org/ can help.
2. The extension is released in one main language (typically English); each localizer releases an "extension language pack". Currently there is some client support for these l10n packs, but not support for nifty features like downloading the correct langpack on demand. Need robstrong to fill in details here...
   • what data can automated tools grab from install.rdf to identify an extension langpack?

Note, also, that we should support application langpacks for our apps. UI would probably be very similar to Dictionaries.