Bug 89657 - The lang-pack installation mechanism on OS X unacceptable -- needs refactoring for better installation UX
Summary: The lang-pack installation mechanism on OS X unacceptable -- needs refactorin...
Status: REOPENED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
4.4.1.2 release
Hardware: x86-64 (AMD64) Mac OS X (All)
: medium normal
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: target:5.3.0 target:5.2.0.1
Keywords:
: 89561 97680 98010 (view as bug list)
Depends on:
Blocks: MacOS-UI
  Show dependency treegraph
 
Reported: 2015-02-25 16:33 UTC by miles
Modified: 2017-09-15 13:04 UTC (History)
15 users (show)

See Also:
Crash report or crash signature:


Attachments
pathed script which will start and quit LO before installing a langpack (27.73 KB, application/octet-stream)
2016-04-22 16:32 UTC, Uwe Altmann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description miles 2015-02-25 16:33:44 UTC
Please cf. mailing list sub-thread starting at <http://lists.freedesktop.org/archives/libreoffice/2015-February/066713.html> "Re: OS X build signature"

I am pasting its most important part for this bug report regarding OS X lang-pack installation mechanism:

"For another, our language pack mechanism copies files into an existing 
LO installation, which is not endorsed at least by the updated (>= 
10.9.5) GateKeeper:

If the installed LO had never been started before the language pack is 
installed into it, trying to open LO leads to a "'LibreOffice' is 
damaged and can't be opened. You should move it to the Trash." error and 
requires to lower "System Preferences... - Security & Privacy - General 
- Allow apps downloaded from: Anywhere."

If the installed LO had already been started before the language pack is 
installed into it, it appears that Gatekeeper does not re-verify the 
modified LO installation, and allows to open LO (at least on 10.10.2)."

Since most non-English users automatically install lang-pack over a new LO installation without first running the install, it means that most non-English users will run into this problem.

There is also a rights problem with the lang-pack install, see separate bug report: https://bugs.documentfoundation.org/show_bug.cgi?id=89561
Comment 1 miles 2015-02-25 16:40:11 UTC
I first reported this under
https://bugs.documentfoundation.org/show_bug.cgi?id=84352
(See comment 22), but only now we seem to know how to reproduce/why it happens.
Comment 2 V Stuart Foote 2015-02-25 22:47:53 UTC
@miles, closing as duplicate of your bug 89561

*** This bug has been marked as a duplicate of bug 89561 ***
Comment 3 V Stuart Foote 2015-10-11 14:36:02 UTC
Back to New.

While OS X packages are now showing as signed resolving bug 89561, the 4.4 and 5.0 packaging to append OS X language-pack to an existing valid (e.g. opened once successfully) installation seems to remain a problem. 

Suspect OS X packaging design needs to be reworked in some fashion given Stephan B's comment.

Through 5.0 the work around is to simply launch OS X install/upgrade of LO once. And then apply the language-pack install package.

Adding work around comment similar to 4.4, to release notes for 5.0.

https://wiki.documentfoundation.org/ReleaseNotes/5.0
Comment 4 Frank Fuchs 2015-10-14 09:02:22 UTC
Could you please also add this to the installation Release Notes (e.g. https://wiki.documentfoundation.org/Releases/5.0.3/RC1)
Comment 5 V Stuart Foote 2015-10-14 13:53:33 UTC
@Cloph, regards comment 4, while I've placed it in the 5.0 Release Notes at: https://wiki.documentfoundation.org/ReleaseNotes/5.0#OS_X  would you agree to including an OS X entry in the Installation stanza of your per build Release notes?  Or is the general note sufficient?
Comment 6 Uwe Altmann 2015-12-19 10:28:28 UTC
Besides fixing I see two possible workarounds:
1. when installing a langpack, the installer checks if a first run of LO has taken place (is that possible?). If LO wasn't started yet, 

1.1. a warning dialog is given in language of the langpack that LO has to run one time to install a langpack.

1.2. or LO is started by the langpack-install script and killed immediately after that so gatekeeper has had it's chance. Perhaps this could be done always so no check is necessary.


2. change the location of the langpack from LO-package to systems library. Therefor put a symlink into the package which directs to the appropriate directory in systems Library/Application Support folder. Because the installer of the langpack already is a program, it should be possible to get the necessary admin rights to do this.

2.1 Langpack install script checks also for depecated langpacks with no fitting LO installation (similar to the way it finds it's right install version) and deletes them.
Comment 7 barefootguru 2015-12-19 17:37:25 UTC
3. Have one download which includes all languages, like every other Mac app :]
Comment 8 Thorsten Behrens (CIB) 2015-12-20 16:48:22 UTC
The code for that is here: https://github.com/LibreOffice/core/blob/master/setup_native/scripts/osx_install_languagepack.applescript

Anyone with a mac, a bit of time, and the willingness to debug that script should be able to fix this. Adding EasyHack label.
Comment 9 Tor Lillqvist 2016-02-05 10:43:41 UTC
Also see https://bugs.documentfoundation.org/show_bug.cgi?id=62442#c33
Comment 10 V Stuart Foote 2016-02-05 12:39:21 UTC
*** Bug 89561 has been marked as a duplicate of this bug. ***
Comment 11 V Stuart Foote 2016-02-05 12:41:31 UTC
to see also 
bug 62442
bug 93331
Comment 12 catacombae 2016-02-08 04:57:09 UTC
[OS X developer and long time LibreOffice user, first time LibreOffice Bugzilla commenter...]

I would prefer approach 3 as suggested by barefootguru, but if that would grow the size of the download to the point where it's unacceptable I would like to add one other possibility:

4. Deliver updated code signatures as part of the language pack. However if the user installs multiple language packs this might be a complicated issue where the langpack installer must keep track of signatures for all possible combinations of language packs... a quick calculation gives me more than 13000 possible combinations of language packs. Every langpack installer would need to include signatures for all of those combinations which include the installed language. Doable, but complicated.

In my opinion there are some real problems with approach 1 and 2:

Approach 1 relies on the fact that Gatekeeper will not check an app after it has been checked the first time, so if we add content to the app bundle after it has been verified the first time Gatekeeper doesn't care, but this sounds more like a bug in Gatekeeper. If Gatekeeper should provide any level of security it should detect modifications in a bundle after it has been checked the first time (what if some malware did the modification?).
Indeed when checking the app with codesign after adding a language pack (in this case the Swedish language pack) reveals that it's in fact not valid anymore:
$ codesign -v -v /Applications/LibreOffice.app
/Applications/LibreOffice.app: a sealed resource is missing or invalid
file added: /Applications/LibreOffice.app/Contents/Resources/autotext/sv/crdbus50.bau
file added: /Applications/LibreOffice.app/Contents/Resources/autotext/sv/standard.bau
...

Approach 2 puts data in directories that are not apparent to the user. If the user wants to uninstall LibreOffice the most obvious thing to do is to delete the app, but that leaves unreferenced data behind in /Library, wasting disk space. An application should be self-contained and not rely on data outside the app bundle.
Comment 13 Piet van Oostrum 2016-02-08 07:50:55 UTC
Approach 2 is the standard way these things are done on OS X: install additions in /Library/Application Support/LibreOffice. If they are version dependent, add a version directory to it. The problem of leftovers in this directory is the same for other applications, and these don't seem to bother. Or they provide an uninstaller. Or just tell the user to also delete that one directory.

The same approach could be used for extensions that are installed for all users. At the moment this is quite messy, as IIRC they are still installed in a user directory, or maybe also somewhere in the application.
Comment 14 Tor Lillqvist 2016-02-08 07:54:09 UTC
LibreOffice as distributed in the Mac App Store comes with a set of user interface languages already. No separate lang-packs necessary. Just saying.
Comment 15 Christian Lohmaier 2016-02-09 13:42:42 UTC
*** Bug 97680 has been marked as a duplicate of this bug. ***
Comment 16 steve -_- 2016-02-09 16:03:59 UTC
Raising importance to high | major

Not sure why this never was addressed. Currently users end up with stuck installations. LO website has no clear instructions of what todo.

Workaround: move broken LO to trash. Re-install LO, open LO, re-install lang-pack. Done. Very easy, but if you do not know this: very difficult.

There must be a better way to deal with this situation. I don't think ignoring it, will make it go away.

Listed as known issue under https://wiki.documentfoundation.org/ReleaseNotes/5.0#OS_X but current description is somewhat technical and hard to understand.
Comment 17 V Stuart Foote 2016-02-09 16:29:57 UTC
Back to Medium Normal -- sorry but the "sky is not falling".

Title back to the more appropriate for this issue which is need for refactoring the handling of Lang Packs on OSX.

bug 93331 is the issue with Lang Packs installation as currently implemented

The Workaround as published to 5.0 release notes, and incrementals, remains valid.

Install LO package onto OSX -> Run it once -> Install the lang pack.
Comment 18 barefootguru 2016-02-09 17:25:10 UTC
While I don't have any stats on the number of people affected by this, I think the current system is unacceptable and user hostile:

- you shouldn't have to download 2 things to install LO.  Almost no other Mac app has this requirement

- running the 2 apps in the wrong order results in a broken LO installation.  Obscure web pages are a pathetic user-unfriendly mitigation.

LO needs a single installer or drag-and-drop install, like almost every other Mac app.

As for the suggested workaround @Foote, you missed a few steps:

1. Download LO
2. Find and download desired language pack
3. Find and read obscure web page, so you don't break your install
4. Install and run LO, immediately quit it
5. Install language pack
6. Run LO and switch to desired language
7. Restart LO so language change takes effect

Repeat every time there's a new release.

It should be:

1. Download LO
2. Install LO
3. Run LO (LO remembers your language preference)
Comment 19 V Stuart Foote 2016-02-09 17:43:49 UTC
(In reply to barefootguru from comment #18)
 
> LO needs a single installer or drag-and-drop install, like almost every
> other Mac app.
> 

Hence this Installation/UX issue gathering rational designs for what can reasonably be implemented in our cross platform code base.

Until resolved--the OS X users simply have to be a bit more adult about managing the software they install on their systems, acknowledging a LibreOffice limitation in meeting Apples changed Gatekeeper packaging practices.

Sorry, but the release note comment should be adequate for anyone.  But, if more detailed steps are needed--feel free to post steps to Wiki--and we'll link to it.

Stuart
Comment 20 Frank Fuchs 2016-02-09 18:14:58 UTC
Stuart:

I beg to differ as a really long time StarOffice/OOo/LO user - and MAC user since 3 years:
The problem is even worse than barefootguru described: Because the language packs are not signed, you have open the language pack (the one within the .dmg) with a "right click" and then acknowledge installing from an unsigned installation package - something Apple warns you not to do.
If you look at all these steps needed, I'm fairly sure a "normal" (i.e. non-IT) user will have major difficulties and likely fail w/o IT support.

My 2 cents:
I think the LO team needs to accept that support for a specific platform like OSX requires a "minimum" of platform specific support - and this starts with a user-friendly and secure way to install the application in line with the operating system's guidelines.
And: If I look at the Windows version of LO, it certainly uses a lot of Windows-specific installation magic (e.g. the registry) to ensure proper installation.

My recommendation:
If the LO team is unsure about the best "long-term" solution, a "quick fix" needs to be provided, soon. I believe an easy one is to provide exactly one single *signed* package (including all the language files). While this requires somewhat more space on your permanent storage device, I'm firmly convinced that this is the lesser evil (esp. taking into account current storage medium prices). That'll give everyone enough time to work on a more intelligent installation process (maybe like the one on Windows where you select what parts of LO and which languages you want to install).
Comment 21 Tor Lillqvist 2016-02-09 18:19:43 UTC
But if the user has to know how to bypass Gatekeeper when running a langpack installer, can't she then also bypass Gatekeeper when running LibreOffice that has been "broken" by the langpack? Or is that "brokenness" so several that it can't be bypassed?

Anyway, see comment #14.
Comment 22 Frank Fuchs 2016-02-09 18:24:43 UTC
Tor:

that can't be bypassed. Mac OSX simply reports this app as "broken". You do not get a prompt where you could choose to accept running an unsigned app.
Comment 23 Tor Lillqvist 2016-02-09 18:25:47 UTC
Not even right-click and "Open"?
Comment 24 Frank Fuchs 2016-02-09 18:31:04 UTC
Nope.
If you install a language pack before running a freshly installed LO at least once, all you can do is move the installed LO app to the trash. Afterwards, a new install is possible.
Comment 25 barefootguru 2016-02-09 18:55:30 UTC
Thanks Frank, had forgotten you needed to right-click when installing language pack.

Note you *can* run LO if you immediately install a language pack, but it requires completely turning off Gatekeeper before launching it.
Comment 26 Sierk Bornemann 2016-02-10 17:28:50 UTC Comment hidden (no-value)
Comment 27 V Stuart Foote 2016-02-10 18:03:44 UTC
@Chris, want to be a hero to your fellow OS X users?  ;-)
  
See Thorsten's code tip in comment 8
Comment 28 barefootguru 2016-02-10 18:30:25 UTC
(In reply to V Stuart Foote from comment #27)
> @Chris, want to be a hero to your fellow OS X users?  ;-)
>   
> See Thorsten's code tip in comment 8

Unless the AppleScript will be run automatically, seamlessly, when someone downloads LO, it's not going to help your average user.

Even my computer-literate friends/family struggle with LO, while managing their Mac and other apps fine.
Comment 29 Chris Sherlock 2016-02-12 07:19:46 UTC
Sorry, I'm literally still learning how to develop on OS X :(

I'm happy to look into it, but not sure how long it will take me to work this out... I've been a bit ill lately and I have another thing I'm working on in the VCL module that I need to focus on first once I'm physically able to.

But please keep me on the list, if/when I look at this I'll either add a comment or submit something to gerrit and note it here.
Comment 30 Robinson Tryon (qubit) 2016-02-18 14:51:42 UTC
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC)
[NinjaEdit]
Comment 31 Emir Sarı (away) 2016-02-23 15:37:34 UTC
This bug should be regarded as a "high" importance bug, since it greatly distrupts user experience and creates a "this is sh*t" or "this does not work" (which I belive worse than "this is sh*t") impression on end users.

When the need to install a second file just to specify the UI language is already a big UX no-no, it is not likely that end-users will try to find (and even if they do, still not get frustrated)a solution for this problem.

Although I cannot comment on a mean to provide a quick fix development-wise, I think LO must switch to an installer-based installation method on OS X, if cannot afford to host all language files within the main .app file.

A desirable method to install LO would be as follows:

1. Run the LO installer
2. Select the UI languages to install
3. During the progress bar section, download the language pack over the web
4. Complete installation

Although OS X has a fame for drag-n-drop installing of new software, significant number of Mac software uses installers. Adobe products, Microsoft Office, NeoOffice - just to name a few.

I cannot think of a more serious bug than this at the moment.
Comment 32 Sierk Bornemann 2016-02-23 17:23:04 UTC Comment hidden (no-value)
Comment 33 William Gallafent 2016-02-29 13:55:58 UTC
I note that the GB language pack (for v5.1), at least, is not “signed by a recognised developer”, so there is yet another hoop to jump through (alt-click -> “open” -> “yes”) in order to get it installed - double-clicking it will not work since gatekeeper will prevent the langpack installer from running. This make and already bad situation even worse.
Comment 34 Christian Lohmaier 2016-04-20 16:36:35 UTC
@Uwe: If you attach your patch to the bug, there's a chance that it might make it in time for 5.1.3 and even 5.0.6…
Comment 35 Uwe Altmann 2016-04-22 16:32:49 UTC
Created attachment 124574 [details]
pathed script which will start and quit LO before installing a langpack

I'm not shure it works - I cannot test the file without a new Version of LO obviously. So comprehensive testing is necessary.
Comment 36 Uwe Altmann 2016-05-12 15:33:20 UTC
Seems to work, tested with the new 5.1.3. Please let me know if ther are still problems.
This solution is a workaround! A "real" solution would be to install all langpacks (and extensions "for all users" too) in the system's library folder instead into the application package. This is the standard location for this kind of things - and the installed extensions would surive updates, which is another long lasting annoyance on Macs.
Comment 37 steve -_- 2016-05-12 15:54:26 UTC
Uwe, should we file a new bug or the longterm solution? It would really help LO on OS X to solve such elementry issues.
Comment 38 Socratis 2016-05-12 16:49:21 UTC
First I need someone to confirm the following:

If you install LO, but you don't run it, open up Terminal and do:
   "ls -al@ /Applications/LibreOffice.app/"
You should get a "com.apple.quarantine" in the Terminal output. Issue the command:
   "xattr -d com.apple.quarantine /Applications/LibreOffice.app/"
Now see if you can install the language pack without any problems.

I've been doing the 'xattr' thing for all my downloaded apps and I never had any problem with installing my language pack (EL) and subsequently running LibreOffice. As a simple user, mind you, not as the owner/administrator. I just noticed that this was an issue while reading (thoroughly) the release notes and I thought I'd contribute my .02€.
Comment 39 Frank Fuchs 2016-06-16 09:25:02 UTC
Dear All,

with macOS 10.12 (Sierra) coming this fall, the mechanism how to install a language pack might run into another difficulty:
Sierra will introduce something called Gatekeeper Path Randomization (e.g. see http://9to5mac.com/2016/06/15/macos-sierra-gatekeeper-changes/) which may make it difficult to change the installed LO app with an installation of a language pack (manually or with a script). Unfortunately, I'm not a beta tester of Sierra, but someone needs to check this out.

I believe it is high time for the LO UI team to focus on a proper Mac installer (please see comments 18 and 20).
Comment 40 jani 2016-06-17 06:57:02 UTC
Removing assigned, and easyHack, the new demand goes above a easyHack

Uwe@ if you want to continue helping with this one, please assign yourself again.
Comment 41 Uwe Altmann 2016-06-17 07:03:18 UTC
thats OK for me, but I can do only limited QA because I never had seen that bug on my Mac :-/ . And also I never had a feedback if my workaround really did solve it by those people who reported it.
So let's wait for MaxOS 10.12 and see what happens. Perhaps someone here is in the beta testing and can post a first glance on it.
Comment 42 Frank Fuchs 2016-06-17 07:24:37 UTC
Uwe,
(and Jan)

your workaround may work, but I don't think it solves the core problem of a missing proper Mac installation routine. 
Maybe a separate bug needs to be opened for this.

Regarding your workaround:
I didn't test your workaround because for me it makes no big difference if I have to start LO once before installing a language pack or not. And it does not solve the problem of unsigned language packs.
And waiting for macOS Sierra to become GA may create another problem: users will update to 10.12 and then may no longer be able to install a LO language pack. It's then a bit late to start addressing the whole issue. Rather, it should be solved by then.

I firmly believe the TDF team needs to commit resources on a new Mac installation program. The requirements have been described in earlier comments.

As a workaround until then:
* sign the language packs and installation packages and ensure you can install them on Sierra (or run Uwe's script on Sierra)
and/or
* provide one "huge" LO file containing all language packs (or at least the most common ones)
Comment 43 Sierk Bornemann 2016-06-17 08:07:44 UTC Comment hidden (no-value)
Comment 44 Commit Notification 2016-06-20 19:58:06 UTC
Christian Lohmaier committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=78c7929ac4f03d90e956cc1052208c646feaabf3

tdf#89657 sign Mac languagepack installer and force-start-close LO

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 45 Christian Lohmaier 2016-06-20 20:00:07 UTC
Uwe's fix to use --convert-to didn't work for me on El Capitan to trigger gatekeeper verification - need to open and close completely to trigger the process....
Comment 46 Commit Notification 2016-06-21 03:43:49 UTC
Christian Lohmaier committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3491a1a7d17bc12a30af900fa83df44ddbd75108&h=libreoffice-5-2

tdf#89657 sign Mac languagepack installer and force-start-close LO

It will be available in 5.2.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 47 Frank Fuchs 2016-06-23 10:52:38 UTC
I just installed LO 5.2.0.1 on Mac OS X 10.11.5 and one part of the patch did not work and another part may need a bit of tweaking:
* I installed the LO core pkg and did not run it
* Immediately after, I installed the German language pack. During the installation it failed and asked me whether I want to re-try as an administrator. Since I already have admin rights with my std user maybe this check can be avoided and maybe it is only necessary for users w/o admin rights. Afterwars it installed the language pack.
* Then I started LO but it complained that the package is "broken" (can't remember the exact word used) and recommended to move it to the trash.
Comment 48 Frank Fuchs 2016-06-23 10:53:27 UTC
I forgot to mention that the language installation pack seems to be properly signed, now. OSX did not complain. Hurra!
Comment 49 Christian Lohmaier 2016-06-23 11:26:03 UTC
I see - I added the statement to open/close LibreOffice in the overall try statement:

https://github.com/LibreOffice/core/blob/libreoffice-5.2.0.1/setup_native/scripts/osx_install_languagepack.applescript#L143-L171

So apparently for you the

		tell application choice to activate

statement fails, and thus LO is not launched, and then it errornously goes into the error block that is meant/worded for the case when extracting the tarball fails)
As you then provided admin-credentials, it did install the tarball without launching LO first, hence getting the corrupted package warning.

When installing the languagepack, you then did not get gatekeeper's do you want to launch/has been downloaded from Web message and "Verifying LibreOffice" for LibreOffice itself and you didn't see LibreOffice startcenter flash.

Fixing the bogus error message is easy (and replacing it with a warning "you need to launch LO at least once, attempting to do this automatically failed. Please run LibreOffice and then click continue"), but of course would be interesting to know why launching LO did fail...

when this line is run, "choice" is already known to be the targeted and suitable version of LO (and as you get the corrupted message, it also shows that it did use the correct path)...

########
Please open the actual applescript in scripteditor and run it from there - you should then be able to see the error message (show contents on the languagepack installer, go into Contents, open osx_install.applescript in Scripteditor, then hit "run"
Comment 50 Frank Fuchs 2016-06-23 12:40:15 UTC
Christian,

I did get the warning from Mac OS X that the installer had been downloaded from the web. This actually works a s desgned. But since the lang pack installer is now signed, I did not get the warning whether I want to run an unsigned app. So, a tick of for that.

Regarding your suggestion:
I ran the script from the script editor and it seems the problem is that immediately with launching the script editor shows a message box with the following text:
---
Die Datei „osx_install.applescript“ ist geschützt.
Wenn Sie dieses Dokument ändern möchten, klicken Sie auf „Schutz aufheben“. Wenn Sie die Datei unverändert lassen und mit einer Kopie arbeiten möchten, klicken Sie auf „Duplizieren“.
---
It then offers three choices: Duplizieren, Abbrechen, Schutz aufheben

The problem is that you cannot klick on any of these choices since the actual script itself is running in parallel and seems to be modal to this dialog. After the script "completes" - and shows "button returned OK" in the results window in the script editor - you could then pick a choice, but that's too late.
Anyway, I chose "Schuttz aufheben" and then receive another msg box:
Die Datei „osx_install.applescript“ ist auf einem schreibgeschützten Volume und kann nicht entsperrt werden.

I then press "Duplizieren" and run the script, but then - after asking for admin rights - it fails and returns "1".

I assume the whole problem is that the script cannot actually be executed at all.
Comment 51 Uwe Altmann 2016-06-25 16:34:01 UTC
(In reply to Christian Lohmaier from comment #45)
> Uwe's fix to use --convert-to didn't work for me on El Capitan to trigger
> gatekeeper verification - need to open and close completely to trigger the
> process....

Mac OS 10.11.5 (El Capitan, all patches)
Copied LO 5.1.4 into "Applications"-folder, it never had a run before. Renamed it to "Libre Office 5.1.4" for better orientation (I've installed 3-5 diferent versions). Not starting!
Started LangPack installer (for de), choose /Applications/Libre Office 5.1.4.app
Waited until it had finished ("Installation of...finished"-Dialog), quitted that with "OK"
Started LO.
>> NO error Messages at all, neither wiht LanguagePack-Installer nor with LO. All perfect as expected.
No idea why you got troubles with that. Perhaps a clean machine is better for testing ( I can imagine you have installed a lot of somewhat obscure software on the machine you use - I remember once I Installed some weird SANE drivers on my old mac to test new scanner functionality in OpenOffice for a special french guy ;-) - I never ever could come back to a clean system. By that, I did a complete reinstall.
Comment 52 Alex Thurgood 2016-09-07 09:35:05 UTC
*** Bug 98010 has been marked as a duplicate of this bug. ***
Comment 53 Uwe Altmann 2016-09-07 17:56:25 UTC
can we close this one or has someone else problems with this?
Comment 54 Frank Fuchs 2016-09-07 18:48:49 UTC
unfortunately, the situation is unchanged.
While signing the lang packs helped, Christian's work remains unfinished and currently adds one extra user interaction w/o benefit to the user.
Comment 55 steve -_- 2016-09-07 20:33:06 UTC
The title of this bug is somewhat unclear. Should we define what is needed to call this solved?

I always preferred the method of packaging the most common languages as done with the MacAppStore version of LO. This would cover the majority of users. The remaining percent could stick to installing the additional language pack. But for the majority the entire process would be a lot more seamless.

Mozilla solves this nicely by providing localized builds for each country. But I think this is out of scope for LO at the moment.

Unless we know what we want, it's somewhat hard to say what the status of this bug is. Also why is it in NEEDINFO?

I wish LO Bugzilla had the feature to re
Comment 56 steve -_- 2016-09-07 20:33:49 UTC
ups... someone hit the enter button to early

... had the feature of requesting NEEDINFO from a specific person.
Comment 57 Alex Thurgood 2016-09-16 10:59:00 UTC
IMO, this should contains needsUXEval and needsDevEval and then set to new.

The installation problem per se of any given language pack is solved with Christian's commits, other than the fact that even the admin user on the system gets asked to enter their credentials to validate the installation of the pack. Yes, another rather unnecessary user interaction, but it works.



I would however tend to agree with others that including the mainstream languages in the download like MSOffice, and other OSX apps would provide a more "OSX-conform" user experience and avoid the issue of separate lang-pack installations for the greatest number of users. Lang-pack bundles are currently ca. 10Mb compressed each, whereas the LO DMG is ca. 200Mb. Supporting say, 10 languages, by default in the LO DMG would therefore increase the total download size by a further 100Mb.
Comment 58 Sierk Bornemann 2016-09-16 11:29:28 UTC
(In reply to Alex Thurgood from comment #57)
> Yes, another rather unnecessary user interaction

+1

> but it works.

"It just works" in the sense of "it just works – works for me" or "it just works – but with some steps to do" should not be the leading goal concerning common user experience. The easier it is, the fewer steps are needed, the less user interaction is needed to install this software, the better.


> I would however tend to agree with others that including the mainstream
> languages in the download like MSOffice, and other OSX apps would provide a
> more "OSX-conform" user experience and avoid the issue of separate lang-pack
> installations for the greatest number of users.


+1 (!)

> Lang-pack bundles are currently ca. 10Mb compressed each,
> whereas the LO DMG is ca. 200Mb.
> Supporting say, 10 languages, by default in the LO DMG would therefore
> increase the total download size by a further 100Mb.

+1

This should be reasonable and affordable.


LibreOffice, German:

LibreOffice_5.2.2.1_MacOS_x86-64.dmg: 201MB
LibreOffice_5.2.2.1_MacOS_x86-64_langpack_de.dmg: 22MB

For comparism, full german localized installation of Apache OpenOffice 4.1.2:
Apache_OpenOffice_4.1.2_MacOS_x86-64_install_de.dmg: 197.1 MB


Apache OpenOffice - Full Installation vs. Language Pack
http://www.openoffice.org/download/full_vs_lp.html
Comment 59 steve -_- 2016-10-23 10:34:00 UTC
Why is this in NeedInfo? Seems we all agree that most important languages should be bundled as it is the case with all other software on macOS.

Should be easy to evaluate, what the most used 5 or x languages are and bundle those. I'd be curious to hear as to what percentage of all languages being used that would cover.

Setting to NEW. If I missed something please elaborate from who NEEDINFO is being requested and what's missing to put this bug back to NEW.
Comment 60 Xisco Faulí 2017-07-13 09:22:56 UTC
Setting Assignee back to default. Please change it back if you're still working on this issue
Comment 61 Fred 2017-08-11 06:22:47 UTC
I'm not sure if the answer is bundling the 5 most prevalent languages as it increases the volume of the application (I was already surprised by finding dictionaries for every language on the planet packaged, I  need to see if there's a way to strip out the ones I really don't need), but one thing should really change: the need to manually set the interface language in the LO settings after a language interface pack has been installed.  I am uncertain if this should be a separate bug but it's the same process that may need revisiting.

The current "core + language pack" approach turns any non-American* install of LO into a non-trivial, multi stage affair as the end user first has to install LO, then install another package, next has to root out where the interface settings are (in an LO that at that point does not operate in their native language) and finally switch to the desired language.  

That's an issue for two reasons: 1. For the average end users, this is a bridge too far.  It gets LibreOffice labelled as 'complicated" compared to other products which is problematic for adoption.  2. It makes business deployment nigh impossible - try doing this in volume.  Optionally there's a 3rd point: it makes upgrading a pain too.

Assuming the need to start up LO once before a langpack is installed is fixed, the easiest way to fix this would be for the langpack to have an option "set LO interface language to xx" and enable this by default.  So, if I were to install in German, the langpack would show a screen in German (or maybe both English and German to keep it universal) and a tickbox already ticked that states "set LO default interface to Deutsch/German".  It still means you have two stages in install (LO + langpack) but it omits the third stage where you have to dig out where the language settings are hiding and do the very thing you'd install a language pack for in the first place.  

Alternatively, maybe make *langpacks* run the actual install process, because that also allows you to get an installation in the user's language without increasing the size of the installer itself with all the languages, makes it more focused.  Just an idea, but I'd leave American/English then as a second option for the poor tech who has to install LO in Swahili and doesn't speak the language :).

* non-American: you even have to go through this to make it speak UK English :/
Comment 62 Christian Lohmaier 2017-09-14 11:04:20 UTC
there is no additional user interaction, the starting of LO is done automatically.

and there is no agreement to "bundle the 5 most important languages" - after all there is no such list of important langauges to begin with, and even if there were, the same issue would apply to the other languages.
You'd still need to download the additional languagepack and install those.
If this is what you mean  with "additional user interaction",  then this is a wontfix.
Comment 63 Fred 2017-09-14 11:31:08 UTC
OK, so the "start LO once before updating" issue is now solved and automated (cool), but the key problem is left unaddressed: the process to install a non-US variant (i.e. core + langpack) is not end-user compatible (i.e. simple).

To repeat myself:

> Assuming the need to start up LO once before a langpack is installed is fixed, 
 
(which is apparently the case if I read the script)

> the easiest way to fix this would be for the langpack to have an option 
> "set LO interface language to xx" and enable this by default.  
> So, if I were to install in German, the langpack would show a screen in
> German (or maybe both English and German to keep it universal)

(where "German" is any value of $LangpackLanguage)

> and a tickbox already ticked that states "set LO default interface to
> Deutsch/German".  It still means you have two stages in install (LO + 
> langpack) but it omits the third stage where you have to dig out where
> the language settings are hiding and do the very thing you'd install a
> language pack for in the first place.

In a nutshell, without this, a non_US LO installation is not really user upgradeable as it doesn't speak the user's installed or desired language.  Thinking about this some more, the langpack itself could actually be the overall installer (so you have just one language to manage during the install process), or the LO installer could have a feature to download the right langpack as part of the process (which is more costly in that you then need all languages in the installer).

Whatever approach is taken, what matters is that during that install process, LO is already set up to use the UI contained in the langpack, instead of the user having to start it up in English and then dig through the settings to finally set the LO UI in the language of the langpack, exit and restart.  Since you have all the data to hand when you start a langpack, why not use it, or default to using it and offer the user an ability to opt out (just in case)?

The goal is to improve the install process to the point where a non-English end user can do this in one single go without ever having to switch away from their own language.
Comment 64 Uwe Altmann 2017-09-15 08:47:20 UTC
> 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!
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)

This involves definitely less foreign language/english UI interaction than starting LO after download, using the english(!) UI to find the language selection, tick my language and "OK" it. Even if above step 3 fails to use the local installed and LO starts in english, form there it is the same interaction than starting in build-in langpack-installer.

The only thing I could see as an improvement would be a language selector popping up at fist start as part of the personalization dialog. But because this is a Mac only thing, I see no chance to get that - except we change this also for Windows to get smaller over all volume of downloads.
Comment 65 Fred 2017-09-15 13:04:38 UTC
(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.