Currently we provide separate MSI help packages - one for each locale. This often creates confusion to people who fail to make sure that help package they installed strictly matches their LO UI language. Total size of all help packages e.g. in http://downloadarchive.documentfoundation.org/libreoffice/old/6.2.3.2/win/x86_64/ is about 150 MB. Given that main LO installer there is 282 MB, it seems reasonable to expect those who need help packages to afford downloading extra 150 MB (in reality, there would be less, because of deduplication of installation machinery overhead). That would put all documentation for all languages available for LO, and so it would be able to pick needed help without disturbing users. https://ask.libreoffice.org/en/question/191056/libraoffice-help/ https://ask.libreoffice.org/en/question/172790/help-pack-install-problems/ https://ask.libreoffice.org/en/question/148310/help-file-installed-but-not-recognised/ https://ask.libreoffice.org/en/question/77601/help-no-longer-works-on-just-installed-lo-5212-on-win10-build-1067-tried-us/ https://ask.libreoffice.org/en/question/77061/how-do-i-access-lo-help/ https://ask.libreoffice.org/en/question/75799/offline-help-51/ https://ask.libreoffice.org/en/question/74443/the-built-in-help-in-libreoffice-doesnt-open-after-f1help-command-but-the-browser-has-started/ etc.
As an enhancement, it makes sense. Moving to NEW
I don't understand the reasoning here. LO is only 282MB, so 150MB for the whole/all languages helpcontent corresponds to 50% of LO size, it's not nothing. I think if you download Spanish localization of LO for example, it should just propose by default Spanish help. If you want Italian help, you should just use the LO setup to check the Italian helpcontent checkbox so it would indicate to LO to download the package and install it. (I don't know if this mechanism exist but it would be useful). I'd like to avoid LO becoming a bloatware, I mean we could also just propose one package per env (Windows, Linux, MacOs, Android, etc.)/ version instead of one package per env/version/language and would have even bigger packages.
A compromise would be : - an MSI archive without any language-related files, - one MSI archive per language (translated user interface, dictionary, offline translated help). 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). Each language MSI archive could provide the below options (all by default) : - translated UI, - dictionary, - offline help.
(In reply to Jérôme from comment #3) > A compromise would be : > - an MSI archive without any language-related files, > - one MSI archive per language (translated user interface, dictionary, > offline translated help). Oh my. This is not any kind of "compromise", it is exactly the very OPPOSITE of what is promoted here. The idea is, that exactly having no split is beneficial for 99% of users. They don't need to have "better user understanding of language-related topics" - they need the system to just work. They don't need two packages installed (let alone three) - they need just one. The links to additional downloads are poor, lead to problems of link rot, more hassle, more maintenance effort, and only serve a few users who case about the used space - and I claim, that here is just a tiny vocal minority, who hamper the maintenance ease in this area, creating the unproportionate cost for it.
(In reply to Mike Kaganski from comment #0) > confusion to people who fail to make sure that help package > they installed strictly matches their LO UI language. a clear page or popup could just provide a link to download the relevant package. currently, the use case is a mess with local/online with a criptic "error 404" page. for example : <<< That is an error. Possible causes are: The page does not exist and must be created. The page exists, but the Help ID is wrong or missing. Use the Module, Contents, Index and Search selectors to find the right page. The following data could be helpful in locating the error: Help ID: modules/scalc/ui/inputbar/sc_input_window >>> (not even sure where how a user can find this 'sc_input_window')