<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - The lang-pack installation mechanism on OS X unacceptable -- needs refactoring for better installation UX" href="https://bugs.documentfoundation.org/show_bug.cgi?id=89657#c65">Comment # 65</a> on <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - The lang-pack installation mechanism on OS X unacceptable -- needs refactoring for better installation UX" href="https://bugs.documentfoundation.org/show_bug.cgi?id=89657">bug 89657</a> from <a class="email" href="mailto:d1312@phx.li" title="Fred <d1312@phx.li>"> Fred</a> <pre>(In reply to Uwe Altmann from <a href="show_bug.cgi?id=89657#c64">comment #64</a>) > > not really user upgradeable as it doesn't speak the user's installed or desired language. > This is not quite right. Installation process by now reads as follows: > 1. Download, open .dmg and and install LO. On a Mac this means just copy > the file somewhere. No need to start LO at this point! Yes, my bad. Note to self: do not post after a long day. > 2. Download, open .dmg and start language pack installer for your native > language. The installer of the language pack is localized, so there should > be no problem. > 3. Start LO the first time. In my experience it starts in the language last > installed by language pack. (This may be attributed to my saved preferences; > so if there is no such mechanism in code, this could be an improvement) Alas, that's not what happens on MacOS 10.12.6. Just to verify, I re-installed 5.3.6 (latest stable) and added the Dutch langpack. I then set the language, so I now have a Dutch install. Installing 5.4.1, then langpack: I get the usual "it's not from the App Store" warning, and the followup installer window is hiding behind other windows instead of being on top (and no, didn't touch the machine in the meantime). I dig out the langpack window and OK it, and eventually arrive at the "installed" notification which tells me where to change the language - exit langpack. Meanwhile, LO's icon in the dock has gone to the "active but hidden" state, I presume due to the kickstart fix not termination LO afterwards. When I click on it, I get an LO defaulting back to US English, NOT Dutch as it was previously. In addition, after then selecting the language I am told LO needs a restart. So, the correct proces seems to me to be: 1 - ask user if langpack language must be set in UI, the current setting (if other langpacks already installed) or US default which is what a core update resets to. Default is the language of the current langpack being installed, and other language choices will not exist if it's straight after a core update. 2 - start LO to negate the langpack corruption bug, but then immediately terminate the program again (this termination failed on the LO update install, but worked fine when installing a second EN-GB langpack). 3 - install LO langpack contents. 4 - access user preferences and set language to choice made in step (1) 5 - notify user of completion and exit - optionally offer to start LO on termination. This makes the process less complex for the user. One core upgrade, one langpack upgrade and mainly accepting defaults, to arrive at an LO that starts up in the desired language without ever needing to read English other than on the LO website (and that may be my browser anyway). Maybe something that may help debugging: I then installed the EN-GB langpack again that I use. During that process, LO /did/ start and terminate correctly, and I was left with an LO that still spoke Dutch when I started it up, so manually had to change it to UK English. It appears a core update nulls the language settings (which makes sense to avoid conflicts with langpacks of an older version) but otherwise a langpack simply add a UI language choice. Hope this helps clarify what I mean. I start from the position of a user who is competent enough to download files, but who does not necessarily speaks English, but also from Enterprise size deployments where someone going round to reset user preferences for each machine would be too much overhead.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>