| Summary: | Customize/personalize windows installer to user's download preference | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Yousuf Philips (jay) (retired) <philipz85> |
| Component: | Installation | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | enhancement | CC: | cloph, cno, heiko.tietze, libreoffice-ux-advise, mikekaganski, timar74, vsfoote |
| Priority: | medium | Keywords: | needsUXEval |
| Version: | Inherited From OOo | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: | https://bugs.documentfoundation.org/show_bug.cgi?id=97991 | ||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
| Bug Depends on: | |||
| Bug Blocks: | 113117 | ||
|
Description
Yousuf Philips (jay) (retired)
2017-10-14 15:16:48 UTC
Because the Windows installer packaging is monolithic including all languages, with optional localized help file .msi, there is no logic in the download pages that can call the needed SelectLanguage custom action to set a user selected locale other than OS system/user locale. Without major changes to the Windows build system and packaging, this would require the current monolithic installer to be wrapped in a setup.exe with logic to control the custom action and pass in arguments made with the website download. I don't seem much need to move from that, especially as a move to "regionalized" and reduced size .msi builds (as for bug 97991) has little dev interest. And frankly getting incremental updates (bug 54242) sorted is a lot more important UX than handling the corner case installation downloads where system or user locale is not the desired installation locale. Aside from facilitating alternate locale installs, delivery with a configured setup.exe would offer a means of allowing convenient parallel /a admin installations. But to me it seems like a lot of churn for limited value--most users will install a single build of LibreOffice and not be interested in removing/installing to gain use of GUI in other locale. Those that need it now are going to be comfortable with running a command line install with UI_LANGS flags set (bug 50509) for those language locales they need. IMHO => WONTFIX The current MSI architecture was introduced in 3.5 [1] just to go away from old EXE+MSI+Languages+stuff. Launching installer in system's (actually user's) language (concern a) is normal, because if user can use system with this language, then there shouldn't be problems with understanding the installer's messages. Trying to do otherwise would fail in case a system doesn't have support for e.g. arabic (or other language). Moreover, if that is a multi-user system, and the arabic-language installer would succeed, then later non-arabic-speaking person could have troubles with reconfiguration or uninstall. The same is also true for default UI language and locale (concerns b and c). Given that there is a possibility that LO would be used in multi-language environment, having single-language installers would also make it more difficult to support such scenarios where one system is used by different-language-speaking users, and correct solution in this case is to have proper user UI language selected on OS level (e.g., using MUI packs on Windows). While there *could* be users whose experience would increase from the proposed changes, the downside for many others would greatly outweigh this. The maintenance cost (both in terms of developers' effort, and of user support required to solve problems resulting from this change) would increase non-proportionally. Closing WONTFIX. [1] https://wiki.documentfoundation.org/ReleaseNotes/3.5#Windows_installer |