[Libreoffice-bugs] [Bug 89657] The lang-pack installation mechanism on OS X unacceptable -- needs refactoring for better installation UX

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=89657

--- Comment #65 from Fred <d1312 at phx.li> ---
(In reply to Uwe Altmann from comment #64)
> > 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20170915/01a9f50c/attachment-0001.html>