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: NEW
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: Uwe Altmann
QA Contact: Uwe Altmann
URL:
Whiteboard: target:5.3.0 target:5.2.0.1
Keywords:
: 89561 97680 98010 (view as bug list)
Depends on:
Blocks: 42082
  Show dependency treegraph
 
Reported: 2015-02-25 16:33 UTC by miles
Modified: 2016-10-23 17:24 UTC (History)
13 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.