383582 - Language packs should activate/deactivate at install/de-install/deactivate

Status: NEW

(Toolkit :: Add-ons Manager, defect, P5)

Description

[Axel Hecht [:Pike]]

I have tested this today, and putting firefox-l10n.js into defaults/preferences inside the xpi significantly improves the user experience of installing those.

I'm not worried about what happens for people installing multiple language packs, I don't know if this affects linux distro installations, though.

Benjamin, I'm not exactly sure if we'd run into some deeper repackaging foo if we'd try to have both pref and preferences in xpi-stage, do you know?

Comment 1

[Marek Stępień [:marcoos, inactive]]

I don't think we should add the prefs file to the language packs... What we should to is make the Languages pane in the Addons window let you select a language just like you would select a theme.

Comment 2

[Axel Hecht [:Pike]]

Language selection in the addons manager is a different feature, but that would still require two application restarts, which is a sucky user experience. And of course, we probably can't do that at all on the branch, which I'm tentatively thinking about still.

Comment 3

[Benjamin Smedberg]

Why would it require two application restarts? Frankly I'd thought about adding that to my extension... it wouldn't be all that hard to do.

Comment 4

[Axel Hecht [:Pike]]

Installation of language pack, restart, selection of language, restart. Isn't it?

IMHO, the language switcher extension is nice for people that do that often, but I'm not convinced that it's the right thing to do for users of one language pack, nor do I think that installing two extensions for one is the best possible way, given that adding the pref "just works".

The idea is to make this feasible for end end users, so any click less is a win.

Comment 5

[Axel Hecht [:Pike]]

I still think that this is the right thing to do, as it makes the language selection correspond to install/disable/uninstall behaviour of the language pack.

The unfortunate effect of adding the pref to the add-on is, it's ending up as a value on the default pref branch, thus it would regress bug 334136, software update with language packs.

I'm torn on what I consider the right thing to be for prefs coming from profile-installed extensions. I'd kind of expect them to not be default prefs, though I have no idea what should happen on reset.

Benjamin, did you have thoughts about this before?

Comment 6

[Benjamin Smedberg]

I think that the EM ought to act like my locale switcher and set the userpref for the 'selected' language pack. The hard part about that right now is knowing what language a language pack is for. Perhaps we could add an extra em:locale RDF arc for that?

Comment 7

[Axel Hecht [:Pike]]

Ok, shipping firefox-l10n.js doesn't work, I think we should try to do something like Benjamin said in the extension manager. Moving over to that component and adjusting summary.

Comment 9

[Andrew Swan [:aswan]]

Pike, should we close this in favor of the current multi-lingual project?

Comment 10

[Francesco Lodolo [:flod]]

We're still going to have users installing language packs outside of preferences, at least for a while.
The multilingual project is going to make this a low priority, but I'd keep it around for now.