Toolkit's extension manager has some preliminary support for a language panel, but the actual implementation is missing. Such a panel should basically parallel the themes panel, including the switching capability and even the handling of a default package. The default language for the build should probably be handled (and installed) like the default theme, so that it's listed in that EM panel, can be switched to, but cannot be uninstalled (and probably keeps its files in chrome/ instead of extensions/ dir, just like that hack we have in place for the default theme). Eventually, we could even hide that tab/panel from EM unless at least one additional language pack to the default is installed. I'm not completely sure on this one though. I'm sure many localizers would be happy about such a panel, and SeaMonkey would also love to have it in its toolkit-based future for replacing the the old language switching pref panel of the xpfe days.

A different issue but a similar place for handling locales is the existing bug for locales of extensions: bug 285848.

Robert, have you installed a locale and Firefox and did not see the Languages view? It worked as you suggested last time I tested it.

Oh, I haven't seen that the language panel is visible when you install another locale. I can see it in Firefox and Thunderbird. But there is one major drawback. And this is a part what Robert Kaiser IMO wants to see. You are not able to switch the languages. Even there is no entry for the default locale. What I also expect is a panel with the same functionality like the panel for themes. Do we need the disable button? Is this button also visible for installed themes? I think we should change the summary of that bug to reflect the remaining things which are to do.

Oh, well, I'm no Firefox/Thunderbird user, so I couldn't test. I mostly care about this from the view of SeaMonkey as a future user of EM. Let's morph this into enabling language switching and listing the default language then. Sorry.

The direction that Firefox and Thunderbird took for setting the appropriate language is to detect the language of the OS and use that language if available. Not sure that it is appropriate to do this via the EM vs. some other way... my initial impression is this should be separate and handled by an extension for those that want it but I haven't convinced myself of this.

If someone has multiple languages installed, he probably wants to be able to switch between them, or have multiple profiles with different languages (might be different OS users as well). Not all OSes (esp. Windows comes to my mind) support different OS users with different general UI languages, so the OS-bound detection will always pick the same language for all users. In that case, it looks like it doesn't make sense to have multiple language packs installed anyways. Also, if the user has a language installed that the OS doesn't support, it will never get activated. Needing to install yet another extension to be able to use that language pack at all sounds a bit strange to me, esp. as the mechanism is the same as for themes, and we allow switching from EM there. Maybe it might be a good idea to have a checkbox in that language panel that says "Pick language by OS settings" (or something easier to understand) as IIRC this is a pref anyways behind the scenes, and enable else deactivated "use this language" buttons on the language pack entries when this checkbox is unchecked. I think this would be an acceptable way to handle multi-language installations. Single-language installations still have the whole panel hidden, so no unneeded complexity where it takes no effect anyways.

Agreed but the best way to accomplish this isn't clear to me especially since I highly doubt the majority of users have multiple locales installed. This isn't to say that an app couldn't provide the functionality outside of the EM since the EM doesn't have anything to do with this currently besides managing the install / uninstall, disable / enable, update, etc. currently.

Note, the language pack panel is not only used for language packs for the application, but for extension language packs, too. And we actually don't have any means to set the language per ... hrm ... right ... what? EM would try to set them per add-on, chrome registry would pick by packagename, as that doesn't have any chance to do that, AFAICT. There are likely tweaks we can do to do "the right thing" in most cases, but this should depend on some "what is the selected language" architecture in the chrome registry. Likely not going to make Firefox 3, AFAICT. CCing Benjamin to get that confirmed.

What do we do for extension theme packs? Isn't that the same topic as extension language packs?

(In reply to comment #7) > Agreed but the best way to accomplish this isn't clear to me especially since I > highly doubt the majority of users have multiple locales installed. True, and if they haven't, the whole language pane is hidden for them, which is a good idea. > This isn't > to say that an app couldn't provide the functionality outside of the EM since > the EM doesn't have anything to do with this currently besides managing the > install / uninstall, disable / enable, update, etc. currently. True, it doesn't manage anything about language pack but everything else there is to manage - except switching which one to actually use. Disable/enable is about as useless on a language pack as on a theme as long as you don't use it anyways.

This does not block the final release of Firefox 3.

(In reply to Henrik Skupin (:whimboo) from comment #3) > Oh, I haven't seen that the language panel is visible when you install > another locale. I can see it in Firefox and Thunderbird. Mozilla/5.0 (X11; Linux x86_64; rv:8.0a1) Gecko/20110808 Firefox/8.0a1 SeaMonkey/2.5a1 ID:20110808003106 In about:addons, I see a Language tab with all the langpacks which I installed as add-ons. Only the one which came compiled-in (en-US, in my case) is not visible. OTOH, I see a rolldown at Edit → Preferences → Appearance → User Interface Language, with all installed UI languages _including_ en-US. Of course, as long as langpacks aren't restartless (bug 677092), a restart is required, which makes it redundant with the -UIlocale command-line switch (though IMHO still useful: I am *not* advocating the removal of either one of these two ways to select the UI locale).

What do you reckon ? If you think this is good, do you have some implementation tips.

Comment on attachment 658837 [details] Mock-up of possible UI Gonna ping some additional people for feedback here, since I personally don't use langpacks (I'm monolingual). In an ideal world, I'd have it so you could only enable one langpack (like how themes work), and that's what would be used. But I know it isn't as simple as that :( The requirements for langpacks have always seemed needless complex to me.... but as I said, I don't use them.

Comment on attachment 658837 [details] Mock-up of possible UI Er, sorry, wrong email...

> Gonna ping some additional people for feedback here, since I personally > don't use langpacks (I'm monolingual). > We can provide feedback on that. > In an ideal world, I'd have it so you could only enable one langpack (like > how themes work), and that's what would be used. That would be a good start.

Comment on attachment 658837 [details] Mock-up of possible UI The difference between langpacks and themes is mostly that we don't expose a "default language pack", like we do for the themes. The way that I would implement this dropdown is to show all languages that you get from toolkitchromereg.getLocalesForPackage('global'), plus a "Reset". The explicit choices would disable matchOS and set general.useragent.locale to an explicit value, reset would reset both. This essentially boils down to only one active locale, and works around potential weird setups with language packs for addons. I also think this should work for the multi-locale setups that are used in linux distros.

PS: the search box can be dismissed, that's in the mockup, but a change to the search box in the add-ons manager is not part of the intended change here, I chatted about that with Arky in person back in Warsaw.

Can we instead of offering two pieces of UI - one to enable locales, another to select one of them, offer a single UI that allows users to sort locales? The benefit is not only simplicity but also it builds a proper fallback chain for languages (if a given locale is not available/broken, fallback to the next one on the list). Sort of what Apple does in Mac OS.

+1 for gandalf's suggestion. It is really high-time we had this feature in Firefox. See comments on this blog post: http://playingwithsid.blogspot.com/2012/05/ideas-for-improving-locale-management.html

Gandalf, can you do a mockup?

(In reply to Zbigniew Braniecki [:gandalf] from comment #23) > Can we instead of offering two pieces of UI - one to enable locales, another > to select one of them, offer a single UI that allows users to sort locales? > > The benefit is not only simplicity but also it builds a proper fallback > chain for languages (if a given locale is not available/broken, fallback to > the next one on the list). > Sort of what Apple does in Mac OS. This would be pretty awesome, especially when we incorporate things like translation into Firefox. But, as the mockup arky posted demonstrates, the most important functionality this would provide is letting users change their default language. That should be the focus of a new UI which could set priority levels, when to translate, etc.

Ok, cool. In that case, this is dependent on bug 595847 being fixed - which coincidentally is currently being implemented as part of the work going on in bug 335781.

This is a very good idea, but it would be UX-wise to put that in the in-content preference.

Any update on this?

The menulist shows all languages returned by toolkitchromereg.getLocalesForPackage('global'), *plus* the value of the general.useragent.locale preference, when it corresponds to an unavailable locale. I worked with many ideas for an "in-content" implementation, as the mock-up made by arky, but I could not get comfortable with the results, so I simply ended linking to this prefwindow that I had. There is many things that I don't like much about it: the top bar in the Languages pane overflows easily in narrow windows, by example, so I probably will resume this plan in the future.

See bug 1425941 for the implementation of it in the Fx options page.

In fact, bug 1425941 is about "UI for switching languages" generally, which I don't think belongs in about:addons