After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 757121 - Install language packs
Install language packs
Status: RESOLVED OBSOLETE
Product: gnome-initial-setup
Classification: Applications
Component: general
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: GNOME Initial Setup maintainer(s)
GNOME Initial Setup maintainer(s)
: 695792 764836 768477 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-10-26 03:40 UTC by Parag AN
Modified: 2018-09-21 16:16 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Parag AN 2015-10-26 03:40:38 UTC
I am creating this as a reference bug for tracking the changes required for adding a new page that will add a switch button to enable installing langpacks packages. The current idea is to have default disabled switch. If user wants langpacks package he will enable the switch to ON and then either display a dialog box (yes/no) and based on yes input run the package installation using packagekit api or when user clicks on next button on langpacks page then install packages using packagekit api.

Currently problem is there is no progressbar UI for installing multiple packages using gnome-software's packagekit api. More details will be added as and when they will be available here.
Comment 1 Jens Petersen 2015-10-26 05:27:00 UTC
A few comments/ideas:

- I would suggest making it a checkbox on the bottom of Language selection page.
- if no progress API then seems the installation has to be done separately:
  I was wondering if using systemd to install the packages via a reboot
  could be a workaround for this?
- something similar is also needed in control-center for the language UI there.
Comment 2 Allan Day 2015-10-26 10:20:05 UTC
(In reply to Parag AN from comment #0)
> I am creating this as a reference bug for tracking the changes required for
> adding a new page that will add a switch button to enable installing
> langpacks packages. ...

Why would a user want to do this?
Comment 3 Jasper St. Pierre (not reading bugmail) 2015-10-26 15:49:10 UTC
Languages and translations tend to be some of the largest files on a system. Some distributions want to push translations out to separate language packs to save on the distro's size.

Any direction towards language packs is a good one -- most of us have 500MB or so worth of translations we'll never use.

Now, I'm not sure I like using PackageKit directly in g-i-s for language packs, because that (sigh) slowly reaches towards distribution functionality, and we need to figure out what to do for OSTree-alike systems as well.
Comment 4 Parag AN 2015-10-27 06:30:10 UTC
(In reply to Allan Day from comment #2)
> (In reply to Parag AN from comment #0)
> > I am creating this as a reference bug for tracking the changes required for
> > adding a new page that will add a switch button to enable installing
> > langpacks packages. ...
> 
> Why would a user want to do this?

We are trying to address the issue raised in this email topic -> https://lists.fedoraproject.org/pipermail/desktop/2015-March/011689.html

Please suggest if you have any other ideas for this.
Comment 5 Jens Petersen 2015-10-27 06:45:14 UTC
Another approach could be to fork a separate langpack installer process perhaps, which could be distro dependent?
Comment 6 Allan Day 2015-11-05 18:16:27 UTC
(In reply to Parag AN from comment #4)
...
> > > I am creating this as a reference bug for tracking the changes required for
> > > adding a new page that will add a switch button to enable installing
> > > langpacks packages. ...
> > 
> > Why would a user want to do this?
> 
> We are trying to address the issue raised in this email topic ->
> https://lists.fedoraproject.org/pipermail/desktop/2015-March/011689.html
> 
> Please suggest if you have any other ideas for this.

This is a fairly complex issue which could involve multiple components (gnome-initial-setup, gnome-software, gnome-control-center, etc), so I'm not sure a bug report is the best place to start.

It would probably make sense to start a design page, with a description of the problem, some goals, and research into the various solutions out there today. Once that's in place, we can talk about potential solutions - but we'll need to coordinate across the various affected modules.
Comment 7 Michael Catanzaro 2016-01-11 23:13:20 UTC
I think the right thing to do is to automatically install language packs (via PackageKit) when the user selects a particular language. We don't need a separate page for this. There is a UI consideration, though, because it implies that changing language can require time and might not work without Internet connection.
Comment 8 Michael Catanzaro 2016-01-11 23:17:14 UTC
*** Bug 695792 has been marked as a duplicate of this bug. ***
Comment 9 Jens Petersen 2016-01-12 08:45:16 UTC
(For Fedora 24 rpm's weak & rich dependencies should start working
and probably they can be used for handling installation of langpacks.
https://bugzilla.redhat.com/show_bug.cgi?id=1114422#c22
In the context of this bug it would mean installing a meta langpack package
to pull in the langpacks for a the selected new language.)
Comment 10 Allan Day 2016-01-12 12:13:24 UTC
Just to clarify: I don't think that whether language packs are used should be a user preference - they are an implementation detail that a user shouldn't have to care about. However, if there are distros out there that want to use language packs by default, and there is interest in putting work into this feature, I'd be happy to take a look at the overall design.
Comment 11 Allan Day 2017-10-23 16:43:29 UTC
*** Bug 764836 has been marked as a duplicate of this bug. ***
Comment 12 Allan Day 2017-10-23 16:44:31 UTC
*** Bug 768477 has been marked as a duplicate of this bug. ***
Comment 13 GNOME Infrastructure Team 2018-09-21 16:16:42 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-initial-setup/issues/37.