Description of problem: On first startup firefox installs dozens of language-packs. Version-Release number of selected component (if applicable): firefox-3.0.4-1.fc10 How reproducible: Always Steps to Reproduce: 1. create a new account 2. log-in under this new account 3. launch firefox Actual results: firefox comes up with a dialog box, reporting to be enabling a lot of language packs. Expected results: I find this behavior is non-sensical. Normal users only speak very few languages and therefore have no use for this amount of language packs. => IMO, the behavior should be reverted: Enable those language packs by default, which correspond to a user's locale, and leave the rest initially disabled. Additional info: The current implementation forces users wanting to reduce the amount of enabled language packages to wade through each of these numerous checkboxes.
*** This bug has been marked as a duplicate of bug 355791 ***
Reopening. This is not a bug of 355791 (a packaging issue). This is a firefox preferences' RFE.
The change you request means huge workload for us and minimum advantages for users. The first startup is only one place which is affected by this issue so we're not going to change the language pack model just because of the first-start check which happens after firefox upgrade only.
(In reply to comment #3) > The first startup is only one place which is affected by this issue so we're > not going to change the language pack model just because of the first-start > check which happens after firefox upgrade only. I still sense a mis understanding: I am not asking to change the language-packs' packaging. If you want to put it overly simplified: I am asking to change the default of language packs firefox wants to enable at first startup from "all enabled" to "only one default language enabled".
That's an involved change than we're not willing to do in the Fedora packages as it has an effect on registration of add-ons/extensions (which is essentially all langpacks are). A bug should be filed upstream. This probably wants to be keyed off the value of the intl.locale.matchOS pref. E.g. if it's true, only register the "best" langpack. Otherwise, keep the current behavior.
If this proposal is inacceptable to you, there would be another alternative: Remove this dialog entirely and enable all lang-packs. I am aware, this might sound like a radical, destructive position, but ... except of cases, when a user is really going through all these dozens of enabled lang-packs to disable them, the effect in end is basically the same as it currently is (User being confronted with utterly long list, turning away by enabling all) One difference, however exits: One less nagging and hardly usable (Things would be much easier to use if these entries were classical "one-click" check-boxes, instead of these "click/confirm" sub-dialogs) dialog less ;)
Created attachment 327505 [details] Screenshot of non-reproduction Reporter, I don't get it. When looking at my firefox, I have all language packs in a separate tab of Tools/Add-ons dialog. Isn't this effectively from the user interface point of view the same as what you suggest? Langpacks are hidden somewhere else and user doesn't have to be bothered with them.
Ralf, I understand why you want the change done. I also understand the codebase and politics well enough to say that if you want this fixed, it must be done upstream. The change I proposed in comment 5 is one possible fix. Your proposal in comment 6 will not work because that "dialog" is a general add-ons dialog: removing it will change the user experience for users to upgrade their extensions (e.g. adblock), themes, and plugins they have installed via xpi, such as those from addons.mozilla.org. The code to remove it may be trivial, but it would change the user experience negatively in some cases and essentially "fork" us from Mozilla, which is to me unacceptable. This could be lobbied for upstream, but again, it would IMO harm the user experience so I do not think upstream would go for this solution either. I can think of a third possible solution, which is to fix https://bugzilla.mozilla.org/show_bug.cgi?id=412446 and package the extensions in their own directories, then have the firefox startup shell script set the env var appropriately such that only the langpack that is referred to by LANG is used. But still, that must happen upstream. This might be a "better" fix than what I thought of in comment 5... in that it is probably less invasive to the add-on registration codebase.
I think and petition again that langpacks be subpackaged and not all installed. There really is no reason why all users are forced to download the full set of langpacks. For F11 I want to make a yum langpacks plugin should take care of getting langpacks installed automatically for a particular language - so then the previous argument against subpackaging that the user's langpack might not get installed would no longer hold. Please do consider this again for F11.
Why should the bug be filed upstream? Fedora is the only operating system that I work on that installs all the language packs. A Windows binary directly off of mozilla.com doesn't do this, nor does a Linux binary directly from upstream. Of Windows, Debian GNU/Linux, Fedora, Ubuntu and FreeBSD, Fedora is the only operating system installing the language packs. 'rpm -ql firefox | grep langpack' shows that the language packs are coming from the firefox RPM. 'dpkg -L firefox' shows that the languages are not part of the Debian package shipped with Firefox. I certainly don't think this is an upstream issue, but a package maintainer issue.
There are several reasons people give for wanting this to happen. * All the langpacks show up in the browser's add-on manager. - I believe that the system should only attempt to load the langpack for the system language. Find the first langpack to match the system language and then not worry about the rest. If the user wants to switch languages, she can do so at the system level, rather than changing every app individually. * Having so many langpacks installed leads to slower behavior as the browser needs to register them all. - I believe this is also a bug upstream. Having multiple addons installed should not slow down the browser as dramatically as it does. * Size. - This is a real issue. However, it is a problem for virtually every translated package in Fedora. It is most visible in Firefox because of the quantity of langpacks, and because of the previous two issues. I feel strongly that this should be solved at a distribution level, and not at a package level. Else, when GNOME gets translated into as many languages as Firefox currently is, we will be having the same discussion. On my system, /usr/share/locale takes up 527MB, which easily dwarfs Firefox. That's a full CD's worth of translations I never use, and need to download updates for, when they are available. I really would like to see this issue solved on a more global level instead of trying to sweep it under the rug by forcing the large packages to act differently from the rest of the distro.
Some comments from the "upstream side": Making language packs not extensions is something that we're unlikely going to do, at least not anytime soon. It'd make things like localizing extensions harder, or installing langpacks off of addons.mozilla.org. Mozilla itself at this point in time doesn't ship anything but single-locale builds. For us that's the right decision, as we're producing builds for people that didn't get Firefox via their OS. For users that do get Firefox with their OS, using OS locale selection mechanism to set the Firefox locale is probably the right thing to do. Onwards on that: - I still don't like the matchOS code path, even though bsmedberg recently OKed that we switch it on if we get to the point that Mozilla creates multi-locale builds. - If matchOS is on, installing *all* language packs is unlikely the right answer, as the user doesn't have a UI to switch them on, in general. At which point we're at a packaging problem, and I don't know enough about redhat's packaging stuff to enlightenfully comment. But the distros would have to solve how to install and update those language packs that would be the right choice and be picked by matchOS for all the languages that the user has currently installed. Quickly glancing at ubuntu, it seems that's what they do. If you want to emphasize that those are distro managed, you might want to set them to <em:hidden>True</em:hidden>. Get that reviewed by Mossop or :bs, though. To detail a bit about "install and update", the language packs should get updates when the upstream localization is updated. l10n-changesets and its history would help in making that call. We do get complaints about that not happening with other aforementioned distros ;-) from our localizers. Didn't verify if that's fixed by now.
PS: after talking to mossop, distribution/bundles might be even more like it. https://bugzilla.mozilla.org/show_bug.cgi?id=392251 is as far as docs go :-/
(In reply to comment #11) > * Size. > - This is a real issue. However, it is a problem for virtually every > translated package in Fedora. It is most visible in Firefox because of > the quantity of langpacks, and because of the previous two issues. Well it is most visible in firefox/thunderbird since other projects with large langpacks upstream (openoffice.org, kde-l10n, eclipse-nls, etc) are already subpackaged. ;-) > I feel > strongly that this should be solved at a distribution level, and not at a > package level. Else, when GNOME gets translated into as many languages as > Firefox currently is, we will be having the same discussion. On my system, > /usr/share/locale takes up 527MB, which easily dwarfs Firefox. That's a > full CD's worth of translations I never use, and need to download updates > for, when they are available. I really would like to see this issue solved > on a more global level instead of trying to sweep it under the rug by > forcing the large packages to act differently from the rest of the distro. Yes it should be taken care of by the distro - but that needs major changes to Fedora (rpm/yum) and is not going to happen any time soon... in the meantime it would still be better to subpackage the langpacks until we have something better.
We have had yum-langpacks in Fedora now for a while and it seems to be working well enough. I think now would a good time to think again about subpackaging firefox's langpacks for F16. I am happy to try for a patch to firefox.spec to do that if it helps.
Last I asked Chris about this he still felt there was too much risk, packaging overhead, and churn in the currently available langpacks to feel the subpackaging would be easy to do. :-\ Perhaps it would be easier/lower risk to try it first for Thunderbird?
I guess there's no more need for separated langpacks. They're disabled by default and only the one which is selected is installed as an extension to Firefox. So the speed argument is no longer valid. According to mozilla data only 30% of all users run English version of Firefox, all others are the localized ones. If we separate the langpacks, 30% of all users may save ~20MB of disk space, 70% of them have to install an extra package and we will need to mess with another extra work during security updates. I think we're not going to do that thing, especially when 20MB of disk space is ridiculously cheep nowadays :)
Anyway, if there's a distro wide solution which saves ~500MB of data we're going to use that mechanism. But it's pointless do all the thing for 20MB of saved space.
(In reply to comment #17) > They're disabled by default and only the one which is selected > is installed as an extension to Firefox. Okay that is an important improvement to the UI side. Given the development overhead I agree it makes sense to keep the status quo. Presto covers the bandwidth overhead so overall I think now it is not too bad.
With the recent state (the langpackages installed on demand) closing. We can reinvestigate it if the global situation changes.