Bug 477127 - RFE: subpackage or separate language packs from main package
RFE: subpackage or separate language packs from main package
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Jonathan Blandford
Fedora Extras Quality Assurance
: Reopened, Triaged
Depends On:
Blocks: 681943
  Show dependency treegraph
 
Reported: 2008-12-19 04:49 EST by Ralf Corsepius
Modified: 2013-06-22 21:02 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-07-10 04:08:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Screenshot of non-reproduction (103.83 KB, image/png)
2008-12-19 18:54 EST, Matěj Cepl
no flags Details

  None (edit)
Description Ralf Corsepius 2008-12-19 04:49:53 EST
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.
Comment 1 Matěj Cepl 2008-12-19 07:48:23 EST

*** This bug has been marked as a duplicate of bug 355791 ***
Comment 2 Ralf Corsepius 2008-12-19 07:55:29 EST
Reopening. This is not a bug of 355791 (a packaging issue).

This is a firefox preferences' RFE.
Comment 3 Martin Stransky 2008-12-19 08:59:36 EST
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.
Comment 4 Ralf Corsepius 2008-12-19 09:17:06 EST
(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".
Comment 5 Christopher Aillon 2008-12-19 12:18:18 EST
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.
Comment 6 Ralf Corsepius 2008-12-19 12:47:31 EST
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 ;)
Comment 7 Matěj Cepl 2008-12-19 18:54:25 EST
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.
Comment 8 Christopher Aillon 2008-12-19 19:13:46 EST
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.
Comment 9 Jens Petersen 2008-12-22 01:28:17 EST
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.
Comment 10 Aaron Toponce 2009-07-02 16:03:05 EDT
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.
Comment 11 Christopher Aillon 2009-07-02 16:36:11 EDT
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.
Comment 12 Axel Hecht 2009-08-18 03:24:11 EDT
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.
Comment 13 Axel Hecht 2009-08-18 04:11:40 EDT
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 :-/
Comment 14 Jens Petersen 2009-08-31 03:23:22 EDT
(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.
Comment 15 Jens Petersen 2011-06-13 01:19:41 EDT
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.
Comment 16 Jens Petersen 2011-11-15 20:57:33 EST
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?
Comment 17 Martin Stransky 2011-11-16 02:06:12 EST
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 :)
Comment 18 Martin Stransky 2011-11-16 02:09:20 EST
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.
Comment 19 Jens Petersen 2011-11-16 03:55:10 EST
(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.
Comment 21 Martin Stransky 2012-07-10 04:08:49 EDT
With the recent state (the langpackages installed on demand) closing. We can reinvestigate it if the global situation changes.

Note You need to log in before you can comment on or make changes to this bug.