Talk:Specification of Language Pack UI for Applications and Extensions

Comments by l10n@

I don't see any reason to restrict ourselves to one language pack.

Robert Strong We are going to use the current app locale to decide which locales to offer and install. During install available language packs for an extension will be checked in the update rdf and then automatically installed with the extension. If the current locale is not available then the extension's default locale will be used. If the locale is changed a matching locale will be looked for and presented in a similar manner as an extension update. At no point would we uninstall a locale unless the extension is uninstalled.

The UI should just list the available locales for that extension and be done for it. Or rather, how about it showing only those locale packs that don't match the current general.useragent.locale?

Robert Strong We aren't planning at this time to add ui to select additional locales to be installed via the EM ui except through the available locale check when an app locale doesn't match an extension's locale as mentioned above - this can of course be accomplish on the web page from which the extension was installed from. Perhaps for 3.0.

So extension foo with german, french and en-US locales would be listed to a german user as "Meine Erweiterung (en-US, de, fr)"

Robert Strong I'm not convinced there is value in adding the locales installed to the ui for an extension. If a locale is available that matches the app's locale it will just use that locale.

The extension should show it's available locales in general if none of the available ones match the currently selected ones.

Such as "Another Extension (en-US)".

I don't think that we need to expose any language selection for extensions, this should just fall back to the fuzzy locale selection that the chrome registry already has.

Robert Strong We aren't planning on exposing language selection.

Regarding update, updates to an installed locale pack only should be possible, I don't see that being layed out clearly.

Robert Strong We are planning on using extension update to install locales that match the current app locale and aren't installed. Other than that the plan is to only update installed language packs.

Regarding installing a langpack for a non-existing extension, we should just require langpacks to require their extension, we will have extension deps for 2.0, right?

Robert Strong that is the plan.

One point that wasn't mentioned yet is conflicting langpacks. Two different localizers localize the same extension, and a user wants to switch over. Though that sounds like something we could postpone to 3.0.

Robert Strong that is out of scope and what we will provide are locales based on the extension's update rdf with the specification that the extension author should only specify one language pack for a given locale per extension.

--AxelHecht 05:27, 31 Jan 2006 (PST)

Comments by bsmedberg

Should we force the langpack ID into some particular format? (de-inspector@extensions.mozilla.org) or should that relationship be managed with metadata?

Robert Strong There are several areas that require this metadata and for simplicity I prefer not to auto-generate it. I do believe we should document a recommended format.

Another way for a user to get multiple langpacks for an extension is for the user clicks a weblink that installs the de-inspector langpack, right?

Robert Strong Correct.

The minVersion/maxVersion setup of a langpack should reference the *extension* version, not the app version (the app version should be irrelevant). This could be handled with extension dependencies internally.

Robert Strong We will handle this with extension dependencies.

I don't think we should worry about conflicting langpacks.

Robert Strong agreed

If you install an extension which has English and German 'builtin' and you install a French langpack, what does the UI look like? (en-US, de, fr) or just (fr) ?

Robert Strong I would prefer to avoid adding the language due to this and other issues with it.

--bsmedberg 07:09, 31 Jan 2006 (PST)

comment by l10n

I think the list should list all available locales for a particular extension, unless there is only one language, and it matches the current locale selection, in the usual "up to the first -" sense that we use for locale picking.