@Jay,

The problem would be in maintaining this diverse set of installers. MSI based installers are monolithic by design--we're lucky to have Andras Timar willing to maintain the Windows packaging for our VS build scripts.

Frankly, I don't have any issues with current packaging of Windows installers and offline help packs. The size of the installer is the price of admission--and, we distribute via ISO for DVD and in portable versions for those bandwidth constrained.

Suspect to get any traction on this, TDF would need to hire a FTE release engineer to specialize in Windows installer packaging--probably WiX based and move away from MS Visual Studio based packaging-- to be able to support the more granular packaging you are suggesting.

(In reply to Yousuf (Jay) Philips from comment #0)
A list of reasons for keeping the status quo is the optimal solution, i.e. the current arrangement where all the languages are in one file.

1. How would the new arrangement change the installation instruction (cf. http://www.libreoffice.org/get-help/install-howto/windows/) without complicating them further?

2. It could create confusion for LibreOffice users if there are different downloads for different locations.

3. In multicultural Australia there is a large likelihood that there is a person from almost every nation that LibreOffice supports is in Australia. Spelling checkers/grammar checkers/thesauri for English and another language is convenient by being bundled in the one installer.

4. It was interesting to note that you listed
ro (Romanian) in LibreOffice-westEU
hu (Hungarian) in LibreOffice-eastEU
when *hu* is more west and *ro* is more east.

5. There may be request to bundle LibreOffice on political alliances, eg. have a installer which has all the EU member states included.

6. The current set-up with separate downloads for each offline help in the language seems very simple on all account, except perhaps if there a download limits. Perhaps solutions could be found like:
a) bundling LibreOffice on the cover DVD of computing magazines
b) hosting LibreOffice on local ISP ftp servers
c) some other creative options which would not divert the resources of TDF from enhancing LibreOffice, Document Liberation

7. You mentioned that this concept would not work for Linux. Microsoft may be a temporary platform as:
a) Moving a city to Linux needs political backing, says Munich project leader
   http://www.pcworld.com/article/2082460/moving-a-city-to-linux-needs-political-backing-says-munich-project-leader.html
b) Russia Plans to Move to Linux
   http://news.softpedia.com/news/russia-plans-to-move-to-linux-500278.shtml
c) German town of Gummersbach migrates to Linux
   http://osssa.org.za/2014/10/07/german-town-of-gummersbach-migrates-to-linux/
d) There may be other migrations to Linux happening, whether in government or business, that are not in the news

The current arrangement WorksForMe.

A lot of good arguments from Óvári. To give another example: You placed en (en_GB or en_US?) in all packages, likely to offer English to everybody. But not taking the other big languages into account might be offending to many people. 
Messing up language with politics is always a big problem.

The better procedure would be to distribute only the hard-coded language and provide language packs (typically PO files) from another source (if possible directly from Pootle). Users could download the language pack from inside the program (Tools > Options > Language Settings).

(In reply to V Stuart Foote from comment #1)
> @Jay,

@Stuart,

> The problem would be in maintaining this diverse set of installers. MSI
> based installers are monolithic by design--we're lucky to have Andras Timar
> willing to maintain the Windows packaging for our VS build scripts.

@Andras: Would be good to hear your feedback.

> Frankly, I don't have any issues with current packaging of Windows
> installers and offline help packs.

I personally dont have any issues with the current installer as i have a 10MB fiber optics connection, i've spoken to people who had difficulties downloading it because of size (e.g. my brother who lives in Somalia where he has a shared 512kb connection and it took him ~4 hours to download it).

> The size of the installer is the price of
> admission--and, we distribute via ISO for DVD and in portable versions for
> those bandwidth constrained.

From what i could see, the ISO on DVD is available in north america and germany and most users will miss downloading the portable additions because its isnt on the standard download page for fresh and still and all links (e.g. the big 'Download Now' button on the homepage or in press releases and news articles ) link directly to < http://www.libreoffice.org/download/ >. It is interesting to see that the full portable version is only 166mb, which makes me wonder why the msi file is so much larger.

> Suspect to get any traction on this, TDF would need to hire a FTE release
> engineer to specialize in Windows installer packaging--probably WiX based
> and move away from MS Visual Studio based packaging-- to be able to support
> the more granular packaging you are suggesting.

Not sure if this would help, but there are msi editors like - http://www.instedit.com/ - so likely there maybe some commandline msi apps that could automate the process.

(In reply to Óvári from comment #2)
> 1. How would the new arrangement change the installation instruction (cf.
> http://www.libreoffice.org/get-help/install-howto/windows/) without
> complicating them further?

There would be no changes there, the changes would happen on the download page which would allow users to select which download they'd want, just like we currently have when a user selects to download help in their language. (e.g. http://www.libreoffice.org/download/libreoffice-fresh/?type=win-x86&version=5.1&lang=de )

> 2. It could create confusion for LibreOffice users if there are different
> downloads for different locations.

If this is presented in the right way, there wont be any confusion. Here is firefox's download page, and it isnt confusing ( https://www.mozilla.org/en-US/firefox/all/ ).

> 3. In multicultural Australia there is a large likelihood that there is a
> person from almost every nation that LibreOffice supports is in Australia.
> Spelling checkers/grammar checkers/thesauri for English and another language
> is convenient by being bundled in the one installer.

As stated, the full installer would still be available for to users who want all the languages, but no single user in Australia would need every language to be included in the installer, as there is a limit to the number of languages they speak/know.

> 4. It was interesting to note that you listed
> ro (Romanian) in LibreOffice-westEU
> hu (Hungarian) in LibreOffice-eastEU
> when *hu* is more west and *ro* is more east.

That was a typo, but you can see that i've listed < https://en.wikipedia.org/wiki/Romanian_language > under LibreOffice-eastEU.

> 5. There may be request to bundle LibreOffice on political alliances, eg.
> have a installer which has all the EU member states included.

Well they can grab the full installer. The main advantage of break up EU into west and east is because of the sizes of their dictionaries and the languages spoken their. Germany on the west has the largest dictionary at 70mb and the largest dictionaries on the east (hu, el, ro, ru) total to 27.5mb.

> 6. The current set-up with separate downloads for each offline help in the
> language seems very simple on all account, except perhaps if there a
> download limits. Perhaps solutions could be found like:
> a) bundling LibreOffice on the cover DVD of computing magazines
> b) hosting LibreOffice on local ISP ftp servers
> c) some other creative options which would not divert the resources of TDF
> from enhancing LibreOffice, Document Liberation

Strange that downloading separate offline help is acceptable, but we wouldnt consider the same for UI and dictionaries. Downloading multiple help files for multilingual individuals wouldnt be the simplest process. Many users wouldnt eve notice the 'LibreOffice in other languages' link on the download page, as i know i didnt notice it the first time i visited.

> 7. You mentioned that this concept would not work for Linux. Microsoft may
> be a temporary platform as:
> a) Moving a city to Linux needs political backing, says Munich project leader
>   
> http://www.pcworld.com/article/2082460/moving-a-city-to-linux-needs-
> political-backing-says-munich-project-leader.html
> b) Russia Plans to Move to Linux
>    http://news.softpedia.com/news/russia-plans-to-move-to-linux-500278.shtml
> c) German town of Gummersbach migrates to Linux
>   
> http://osssa.org.za/2014/10/07/german-town-of-gummersbach-migrates-to-linux/
> d) There may be other migrations to Linux happening, whether in government
> or business, that are not in the news

In the linux builds, we dont bundle all the language packs into the installer ( http://downloadarchive.documentfoundation.org/libreoffice/old/latest/deb/x86/ ), so users would need to download the separate language packs like they download the separate help packs on windows. Also most linux users get LibreOffice through their package manager, so they dont visit the website to download it, unlike Windows and Mac users.

Windows isnt going anywhere and that wont being changing anytime soon no matter which governments switch over to linux, as there are more people in businesses and in their homes than employees in a government.

(In reply to Heiko Tietze from comment #3)
> To give another example: You placed en
> (en_GB or en_US?) in all packages, likely to offer English to everybody. But
> not taking the other big languages into account might be offending to many
> people. 

Yes en meant en_US (our default english) so that it is available to everyone and the LibreOffice-default included all the major languages, that dont have their own dedicated installer.

> Messing up language with politics is always a big problem.

The organization was based on languages and geographics, not politics.

> The better procedure would be to distribute only the hard-coded language and
> provide language packs (typically PO files) from another source (if possible
> directly from Pootle). Users could download the language pack from inside
> the program (Tools > Options > Language Settings).

Yes it would be great to have the ability to add and remove languages and help directly from within LibreOffice, but of course that goes on the assumption that users have internet. ;D

Just as an additional piece of information about the breakup based on languages, the windows daily installer on @62 only includes a similar set of languages (en-US, de, ar, ja, ru, qtz).

http://dev-builds.libreoffice.org/daily/master/Win-x86@62-merge-TDF/current/

(In reply to Yousuf (Jay) Philips from comment #6)
> the windows daily installer on @62 only includes a similar set of
> languages (en-US, de, ar, ja, ru, qtz).

Not sure if “en-US, de, ar, ja, ru, qtz” are a similar set of languages; however for testing purposes they may give a broad cross-section of use cases.

If effort is going to be expended to create separate downloads, perhaps the best solution for minimal downloads would be to have:
* a core LibreOffice download (without any language pack); and
* each language as a *separate* download, not grouped at all.

There could be a page on LibreOffice.org to download language packs. It could look like:
http://www.libreoffice.org/download/libreoffice-fresh/?type=win-x86_64&lang=pick
with the title changed from “Please select your language” to “Language packs for Windows 64 bit”.

Having each language *separate* may make adding extra languages easier as:
* extra languages would not need to find which build of LO it should be added to;
* if there are similar languages that could be bundled together, but there is a political situation between the languages, this would be avoided;
* installation files would be the absolute minimum, satisfying bug 97991. Perhaps it would also reduce the amount of data through a government/enterprise installation (this could be a lot for installations in the magnitude of 10^4 or more).

The Mac build has challenges as the Release Notes state, “Mac OS X: Please start LibreOffice at least once before installing a LangaugePack.” (https://www.libreoffice.org/download/release-notes/). Perhaps this blocks this bug.

I thought that the current install is optimal, hence suggested WorksForMe; however, a core LO installation (without any languages) and separate language packs for each language would be the best solution for: reducing the download size, data travelling through a network when installations in the magnitude of 10^4.

Setting to status to UNCONFIRMED → NEW.

(In reply to Yousuf (Jay) Philips from comment #4)
> 
> @Andras: Would be good to hear your feedback.

Windows installer is created with help of a huge Perl script and standard tools from Windows SDK, such as msidb.exe.

Installer maker script is configurable in regards of languages you build in, and you can fine tune what go into the package in scp2. 

So, in theory, your goal can be reached.

I do not see why WiX or other installer maker frameworks would be better, but I see a big amount of work, if someone wants to migrate the scripts from one framework to the other. 

> 
> I personally dont have any issues with the current installer as i have a
> 10MB fiber optics connection, i've spoken to people who had difficulties
> downloading it because of size (e.g. my brother who lives in Somalia where
> he has a shared 512kb connection and it took him ~4 hours to download it).
> 

The situation was the same everywhere in the world 15 years ago. It is easy to get used to the comfort of high speed net connection, but I think 4 hours is not that much (maybe those users will not download LibreOffice daily for testing). If TDF ever decides to split the installer for different languages or geographies, I hope that the decision will be based on some survey and calculations of cost/benefit, not on anecdotal evidence.

There are several goals here that are in tension with each other:

* reduce download size
     + I assume this is not a goal; since the help has significant size[1],
       and by bundling lots of help files in we will rapidly become larger
       than the existing download.
     + IMHO our ~static 200Mb download footprint is reasonably small.
	  + I suspect we could even increase this;
	    I'd say an upped 250Mb is reasonable myself.

* reduce update size ?
     + not an explicit goal thus far, but clearly after the initial download
       the size of the incremental updates is prolly by far more important
       than the download size itself. This is an area where TDF could invest
       in improving things for the vast majority of users.

* reduce install size
     + IMHO our ~1Gb install size is reasonably small too.
        + Office 2013 requires 3Gb:
	    + https://technet.microsoft.com/en-us/library/ee624351.aspx?f=255&MSPPError=-2147217396

* improve performance
     + there is some level of cost from having all languages installed,
       I don't think this has been characterized recently - but it might
       be interesting to do that again in eg. cachegrind to get a hard
       number of eg. startup cost with more langs installed.
          + this should have some technical fix of course.

* increased font bundling
     + seemingly we want to include more fonts for some locales
          + in general a bit of engineering work can usually save
            some space to free it up for more fonts without growing
            our download footprint, if we're indeed too worried
	    about that.

* distribute on-line help in the package
     + this essentially requires cutting the package into several
       pieces as suggested in order to keep the size sensible, that:
	   + increases our test burden
	     - 5x builds to test instead of one.
	   + somewhat increases our releng burden
	     - 5x builds to push -> more B/W
	         -> a relatively small effect though
  	   + download page simplification / complexity
	     - this will need re-engineering / tweaking
	     - will need to be different for Windows.
	     - how reliably can we detect people's locales
	       and map that to the "click here to download"
	       so 99.9% don't mis-download the wrong thing ?
	       If we have eg. 2% downloading the wrong thing
	       this adds ~4Mb to our apparent download size.
	   + some engineering to the packaging perl scripts
	     - some man days of work; no need to move to Wix.
     + I guess we would want to have roughly 20 languages
       in each of say five piece.
     + against this:
	  + would obsolete the on-line help for Windows users.
	  + what %age of users actually use the on-line help ?
	    Previous studies I've seen suggest a surprisingly
	    small number; and clearly an even smaller number
	    of them are off-line at the time.
	      ie. what is the benefit ? =)
	  + confusion wrt. "what is LibreOffice" - mine is
	    not the same as yours etc. "yours does not have my
	    language" etc.

* Anyway - all things are possible; I imagine if someone has
  done the engineering work already; and has a real proposal
  that might be more interesting.

	My general suggestion would be to optimize our size and
packaging instead; I imagine investing in reducing and compacting
and/or better arrangement in the MSI so that the compression works
better (it is IIRC per-file based not global so it can't see
commonality between eg pt_BR and pt if they are in different streams)
would be a better use of time. Other things like moving our clipart to
SVG from PNG might help too (it compresses better usually).

	And/or if we want to include more things, upping the target
file-size limit might be a good idea.

	Just my 2 cents.

(In reply to Michael Meeks from comment #9)
> * improve performance
>      + there is some level of cost from having all languages installed,
>        I don't think this has been characterized recently - but it might
>        be interesting to do that again in eg. cachegrind to get a hard
>        number of eg. startup cost with more langs installed.
>           + this should have some technical fix of course.

And I assume that, although the .msi contains all languages, only a small subset is preselected during installation, so that a typical scenario will end up with only a small number of languages actually installed?

(In reply to Óvári from comment #7)
> Not sure if “en-US, de, ar, ja, ru, qtz” are a similar set of languages;
> however for testing purposes they may give a broad cross-section of use
> cases.

Yes these select languages were chosen as a means of testing a broad range of languages. e.g. ja to test asian/cjk languages, ar to test rtl/ctl languages

> If effort is going to be expended to create separate downloads, perhaps the
> best solution for minimal downloads would be to have:
> * a core LibreOffice download (without any language pack); and

There would always have to be atleast a single language pack in it or else it wouldnt work

> * each language as a *separate* download, not grouped at all.

Not sure how much benefit would be attained in this approach, as each language UI pack is normally quite small in size ( < 2Mb ).

(In reply to Andras Timar from comment #8)
> Windows installer is created with help of a huge Perl script and standard
> tools from Windows SDK, such as msidb.exe.
> 
> Installer maker script is configurable in regards of languages you build in,
> and you can fine tune what go into the package in scp2. 
> 
> So, in theory, your goal can be reached.

Glad to hear.

> The situation was the same everywhere in the world 15 years ago. It is easy
> to get used to the comfort of high speed net connection, but I think 4 hours
> is not that much (maybe those users will not download LibreOffice daily for
> testing).

Yes my brother doesnt use the daily builds, but with the cost/availability of electricity where he is, he chose not to download it.

> If TDF ever decides to split the installer for different languages
> or geographies, I hope that the decision will be based on some survey and
> calculations of cost/benefit, not on anecdotal evidence.

The main object of this issue was to save users from downloading an installer larger than what they need, which in turn would reduce TDF's bandwidth costs. It was also to make the installer closer in size to LO competitors like AOO (134Mb) and WPS (78Mb). But yes i do see the ramifications of this proposal as it would involve extra work for building as well as modification of the website, so it would be good for someone/committee to read through the proposal and make a decision in it.

(In reply to Michael Meeks from comment #9)
> There are several goals here that are in tension with each other:
> 
> * reduce download size
>      + I assume this is not a goal; since the help has significant size[1],
>        and by bundling lots of help files in we will rapidly become larger
>        than the existing download.
>      + IMHO our ~static 200Mb download footprint is reasonably small.
> 	  + I suspect we could even increase this;
> 	    I'd say an upped 250Mb is reasonable myself.

The proposal wasnt to include help packages as part of the installer, as that would highly increase the size, it was about removing things currently bundled and possibly include small useful extra items, like additional fonts, into particular installers. The old windows daily builds which only had english bundled were around ~120mb.

> * reduce install size
>      + IMHO our ~1Gb install size is reasonably small too.
>         + Office 2013 requires 3Gb:
> 	    +
> https://technet.microsoft.com/en-us/library/ee624351.aspx?f=255&MSPPError=-
> 2147217396

The install size of ~1Gb would be only if a user installed every single language in the installer, but most users are likely to only install 1 to 3 languages, which means the install size for most users would be around 600mb.

> * increased font bundling
>      + seemingly we want to include more fonts for some locales
>           + in general a bit of engineering work can usually save
>             some space to free it up for more fonts without growing
>             our download footprint, if we're indeed too worried
> 	    about that.

With the CJK font mentioned in the other bug being around ~100mb uncompressed, i would wonder how much it could be reduced in an .msi file.

> * distribute on-line help in the package
>      + this essentially requires cutting the package into several
>        pieces as suggested in order to keep the size sensible, that:
> 	   + increases our test burden
> 	     - 5x builds to test instead of one.

Is this about testing the installer or testing the languages, as if it is about testing the languages, CJK users would only be testing the CJK version, and of course download the extra help package to also test that.

> 	   + somewhat increases our releng burden
> 	     - 5x builds to push -> more B/W
> 	         -> a relatively small effect though

Yes there would be 5 more installers to push, but alot less B/W would be consumed from downloaders.

>   	   + download page simplification / complexity
> 	     - this will need re-engineering / tweaking
> 	     - will need to be different for Windows.

Ideally this would also work for Mac OS as well.

> 	     - how reliably can we detect people's locales
> 	       and map that to the "click here to download"
> 	       so 99.9% don't mis-download the wrong thing ?
> 	       If we have eg. 2% downloading the wrong thing
> 	       this adds ~4Mb to our apparent download size.

Ideally we'd show them the 6 versions and let them choose the one they want. We currently dont detect people's locales as a means of giving them the correct help pack.

> Other things like moving our clipart to
> SVG from PNG might help too (it compresses better usually).

I think > 25% of the clipart is SVG.

> 	Just my 2 cents.

Thanks for weighing in.

The recurring questions on AskLibO that keep asking why a help pack doesn't work suggest that having different installers for different languages bring more confusion than help.

The problem with help packs not working is that users use one UI language, but have help pack from another. They don't find it intuitive to match UI language and help pack language; the hypothetical one-helppacks-in-one-installer scenario would solve great number of user problems. Of course, at cost of increased download size.

The reduced size of program installer wouldn't be that small as to help people to go from 4 hrs of download to 15 minutes. More realistic is scenario when this will reduce to ~3 hrs; and that would still make most people who refuse to download now to keep refusing. But the cost will be great, both in terms of developers effort, infrastructure (size required for each version on servers), and user support in cases like where a single-regional setup is tried to be upgraded by all-lang installer (waste of bandwidth again, because user now needs to re-download required package?) or other interesting issues.

My strong opinion is WONTFIX.

*** Bug 153844 has been marked as a duplicate of this bug. ***

And see also bug 124992 would take things the opposite direction, larger installers (core and help/localization) and then based on os/DE locale sort it out.

This discussion didn't mentioned the install with the wapt tool.

In my organisation, we spread a new LibreOffice release with wapt but we are using a maximum of 3 languages (for the documents themselves but 1 language for the user interface and the help).

(In reply to Jérôme from comment #15)

And what prevents from installing everything, even when you use one to three languages?
We have continuing problems with Linux distro packages, where they offer "modularity", which results in users' confusion, when they expect something to work, but it doesn't, because some package was missing. Going into the same rabbit-hole on Windows would be an insanity; we already removed some options from the installer just because of that [1].

Indeed, one may argue that the proposal here doesn't go as far; but I think that even today's installer is just too complex, and should be simplified to install *everything* without options. Exceptions might *possibly* be considered only for components that might create security issues, like ActiveX component.

[1] https://wiki.documentfoundation.org/ReleaseNotes/4.2#Installer_(Windows_only)

In reply to comment #16 :
> what prevents from installing everything,
> even when you use one to three languages?

The problem encountered by my organization is not related to the installed size. My organization distributes a version of LibreOffice to over 10,000 computers. On each host, wapt downloads the complete MSI archive. On our large internal network, we are experiencing problems due to the large size of this MSI archive.


Comment #12 by Mike Kaganski reported a bad user experience when UI language and help are in separate packages :
> The problem with help packs not working is
> that users use one UI language,
> but have help pack from another.
> They don't find it intuitive
> to match UI language and help pack language

So, for Windows users, we could gather all "one language" related files in a single package.


Comment #7 by Óvári proposed a solution in order to decrease the download size :
> If effort is going to be expended
> to create separate downloads,
> perhaps the best solution
> for minimal downloads would be to have:
> * a core LibreOffice download (without any language pack); and
> * each language as a *separate* download, not grouped at all.

This last solution solves several problems:
- reduced download size,
- better user understanding of language-related topics.

In addition, the language settings of LibreOffice could provide an Internet link to download additional language packs (always installed for all computer users).

(In reply to Jérôme from comment #17)
> Comment #7 by Óvári proposed a solution in order to decrease the download size :
> ...
> 
> This last solution solves several problems:
> ...
> - better user understanding of language-related topics.

No, it doesn't solve this - it requires this (better understanding of language-related topics) from users. Adding requirements does not solve anything.

Let's turn this into a meta bug, seeing the variety of improvement suggested, many of which can be handled independently.