It seems to me that a major driver for getting langpacks out of Workstation Live, years ago (I think?) was to restrict its size for the Live CD case. Am I remembering this wrong?

At the time, we had a hard size limit of 1.0 GB for the installation media. We were doing tricks like shrinking the images that appear in user help in order to save space on the media.

Nowadays we do not have a hard size limit and can consider installing all language packs. We probably do not want to do so if it would make the download huge, but it's not really possible to make an informed decision without knowing how much space we are talking about.

@petersen: Clearly the easiest thing is to include them. Can you give us an idea of size here, like:
85M - ja
45M - de
...etc.? Maybe sort the list by the most-requested/used languages so we could consider a cutoff point if needed.

I looked at libreoffice-5.4.2.1-1.fc27.

Total size of all 44 libreoffice-help-* rpms is 294MB (about 6MB each)
Total size of all 69 libreoffice-langpack-* rpms is 32MB (average 460KB each)

So just including all the langpacks would not be so bad: maybe arguably they don't even need to be subpackages anymore? However the Help files are significantly large but maybe less critical to include? We may need some input from the Libreoffice guys on this though.

Unsubpackaging all the libreoffice langpacks would add significant size to the libreoffice packages (or libreoffice-core). But for Workstation Live itself 32MB is not that bad, and it could even be reduced by selecting languages.

32MB doesn't seem like an issue to me. These could just be added as a wildcard 'libreoffice-langpack-*' in our kickstart, right?

That sounds okay to me.

/cc @dtardon and @caolanm

I looked at libreoffice-5.4.2.1-1.fc27.
Total size of all 44 libreoffice-help- rpms is 294MB (about 6MB each)
Total size of all 69 libreoffice-langpack- rpms is 32MB (average 460KB each)
So just including all the langpacks would not be so bad: maybe arguably they don't even need to be subpackages anymore?

The packages serve two purposes:
1. Install UI translations for a language.
2. Install support for a language (spell checking dictionary, thesaurus, auto-correction rules, font(s)).
So even if we moved the translations to other subpackages, the langpack subpackages themselves would remain, because it would be highly undesirable to add deps on 69 hunspell-<lang>, mythes-<lang> etc. packages to core...

Btw, this also means that the 32MB size estimate may be wrong. You have to count also the langpacks' dependencies, which may not yet be included in the installation media.

However the Help files are significantly large but maybe less critical to include? We may need some input from the Libreoffice guys on this though.

I intentionally split them out of langpacks to make their installation optional. langpacks currently use Recommends to depend on help, but I could change it to Suggests, if necessary...

Right here is the wiki page to show the size estimation if one need to check for Fedora 27 release.

Btw, this also means that the 32MB size estimate may be wrong. You have to count also the langpacks' dependencies, which may not yet be included in the installation media.

This is a good point. Weak deps makes the installation of langpacks swell to an unacceptable size (383 MB download, 1.6 GB on disk, since -help-* gets dragged in too). I'm not sure whether it's possible to turn off those deps for ISO generation when we build the Workstation Live. Let's assume for the moment it is. Even without, it's 94 MB download, 461 MB on the disk once you count the required deps. That seems like way more than we should add to an image everyone has to download.

So we need to figure out a smarter way to do this, based on the user's language selection.

The langpacks will need to be installed via PackageKit by gnome-initial-setup and the Region & Language panel in gnome-control-center, whenever the user selects a new language. There will need to be some user interaction, because we want the user to know if this fails due to e.g. lack of internet connection.

Gnome Software seems to be able to do some of this.

gnome-software --details-pkg=lang-pack-ja will start gnome-software and then allow a user to install the meta package with one click (--install doesn't seem to do anything for me in this case). So a simple solution (or hack?) would be to have gnome-initial-setup and control-center call out to gnome-software after they see a language has been chosen with no langpacks support installed. This could probably be refined, but how does it sound? There could also be a button "Install langpacks" for this.

We discussed this in the WG meeting just now.

A few more points were raised:

• using a separate window during initial setup is not desirable
• in gnome-initial-setup wifi setup happens after language setup, so langpack installation would have to happen afterwards
• Owen suggested it could also be "just entirely in the background possibly with a notification". (I think mclasen also suggested to me before just doing it in the background)
• It is probably good to have buttons to start or skip the process: they could be on the language screen.

I had another idea last week: a wrapper script around libreoffice that would offer to install langpacks the first time it is launched.

Discussed at today's WG meeting. @petersen will continue to investigate this. In addition to modifying gnome-initial-setup, he has also considered creating a wrapper app that offers to install langpacks before starting LibreOffice.

Libreoffice in Rawhide now notifies users about installing langpacks for their locale via gnome-software.

Jens, one thing I forgot to mention in the meeting: the lang packs themselves (and their presentation in gnome-software) could use some love. They all use the same icon, have no description, and all claim to weight 7.9kB (which is obviously not the information you're interested in in this case).

Good point, Matthias: I filed https://bugzilla.redhat.com/show_bug.cgi?id=1538105
against the langpacks metapkg component for this.

I learned today from Matthias that latest gnome-initial-setup may have some pkgkit support for
installing supplementary packages, which we could probably leverage for installing langpacks.

I learned today from Matthias that latest gnome-initial-setup has some pkgkit support for
installing supplementary packages, which we could probably leverage for installing langpacks.

May I know where is the latest gnome-initial-setup code is committed related to above mentioned support? I checked https://github.com/GNOME/gnome-initial-setup/commits/master and https://git.gnome.org/browse/gnome-initial-setup/log/ but could not find any latest commits mentioning PackageKit word.

Can't find it either, right now. I'm asking Kalev

I have now tried different solution to have langpacks auto installation in GUI. I have created new langpacks-install project which uses PackageKit dbus Modify interface to install langpacks-xx package.

About this tool
1) installs langpacks-install.desktop in /etc/xdg/autostart/ directory to make sure langpacks-install binary runs at every Gnome session startup.
2) Read the current locale. e.g. if "ja_JP.UTF-8" then use langcode as "ja". If zh_CN.UTF-8 then use langcode as "zh_CN".
3) Generate package name as langpacks-xx where xx is above langcode.
4) Use PackageKit Dbus Query interface (org.freedesktop.PackageKit.Query) to cross-check if langpacks-xx is already installed. If it is then do nothing.
5) If it is not installed then use org.freedesktop.PackageKit.Modify to generate PackageKit notification to install langpacks-xx.

User can then act on this notification or ignore it.

Forgot to mention above
Pagure project link -> https://pagure.io/langpacks-install
This package is already available for testing in F27+ releases.

After some discussion with Kalev and Richard Hughes we came to the conclusion that Gnome Software is probably best setup to have langpacks installation functionality.

It could detect initial login and changes of desktop locale to trigger the installation of langpacks-XX for your current locale, which would pull in any langpacks for your installed applications, etc.

@petersen could you provide an update here?

Yes, I think there is a good news: thanks to work by @suanand with help from Kalev and Hughsie the next Gnome Software release should support automatic Langpacks installation for the user's desktop locale - I hope/expect it will be included in Fedora 31.

(For Silverblue currently langpacks still need to be layered manually but in the long term we would like to enhance that too - there are some related tickets in Taiga.)

Well, if it's automatic, then can this issue be closed? Or is there more that we need to track here?

Assuming this is good to close, please reopen if not.