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.

@miles, closing as duplicate of your bug 89561

*** This bug has been marked as a duplicate of bug 89561 ***

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

Could you please also add this to the installation Release Notes (e.g. https://wiki.documentfoundation.org/Releases/5.0.3/RC1)

@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?

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.

3. Have one download which includes all languages, like every other Mac app :]

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.

Also see https://bugs.documentfoundation.org/show_bug.cgi?id=62442#c33

*** Bug 89561 has been marked as a duplicate of this bug. ***

to see also 
bug 62442
bug 93331

[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.

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.

LibreOffice as distributed in the Mac App Store comes with a set of user interface languages already. No separate lang-packs necessary. Just saying.

*** Bug 97680 has been marked as a duplicate of this bug. ***

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.

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.

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)

(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

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).

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.

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.

Not even right-click and "Open"?

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.

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.

@Chris, want to be a hero to your fellow OS X users?  ;-)
  
See Thorsten's code tip in comment 8

(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.

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.

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.

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.

@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…

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.

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.

Uwe, should we file a new bug or the longterm solution? It would really help LO on OS X to solve such elementry issues.

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€.

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).

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.

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.

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)

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.

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....

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.

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.

I forgot to mention that the language installation pack seems to be properly signed, now. OSX did not complain. Hurra!

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"

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.

(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.

*** Bug 98010 has been marked as a duplicate of this bug. ***

can we close this one or has someone else problems with this?

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.

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

ups... someone hit the enter button to early

... had the feature of requesting NEEDINFO from a specific person.

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.

(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

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.

Setting Assignee back to default. Please change it back if you're still working on this issue

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 :/

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.

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.

> 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.

(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.

(In reply to Fred from comment #65)
> …
> 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.

This is what you get when in System > Security Apps-Download is only allowed from AppStore. And that' exactly what I would expect happen with this setting when I try to install non-AppStore Software. This is not a LibreOffice problem and obviously cannot be solved by LibreOffice devs.
Adapt your settings to your behavior instead :-)

Maybe we should mention this in the installer instructions?

*** Bug 119504 has been marked as a duplicate of this bug. ***

Didn't we fix that with the script years ago? Cloph?

There is a further issue with the install process.

As the script does not shut down LO afterwards, a user who opens LO immediately post langpack install will not see the newly installed language in their interface language options: LO has never rebuilt the list of available interface languages by restarting.

There is thus also need for full LO shutdown post langpack install so it gets a chance to reload the available options before the user (still manually) makes the choice.  Could be a good extra option in the installer to do that for the user as well.

Dear All,

we may also run into the problem that with macOS 10.15 Apple wants all Mac apps to be "notarized" by Apple.
One of the std requirements is that no code in the notarized app is changed or added after notarization (e.g. at runtime).
This may pose a problem for the Mac language pack installation - unless LO is notarized together with a filed exception to this rule (which then makes notarization more or less obsolete).

@Fed: The script /does/ a full shutdown. Maybe you better exercise patience and wait until the "Installation finished" - Message appears and you clicked the "OK" button before starting LO. If that does not help, something seems wrong with your System?

@Frank: Whatever Apple may do or not do in the future and whatever this may bring to us - there is surely too much "may" involved for a bug report. Maybe(!) somewhere in future this will result in a then NEW bugreport!

@Sierk: Please do NOT reopen this one.

@Uwe:
There is no maybe involved regarding app notarization on macOS 10.15 (Catalina).
Quote:
Mac apps, installer packages, and kernel extensions that are signed with Developer ID must also be notarized by Apple in order to run on macOS Catalina.
Weblink:
https://developer.apple.com/developer-id/
The relevant text starts on the middle of the page.

I am happy to open a new bug report on this but I think it directly involves the language installation process (because the LO package is changed by it) and not just the notarization of the LO app (which needs to be a separate "bug" report).

The fact is installing LO with a language pack is markedly more difficult than most Mac apps.  Even with Read Me webpages and helper AppleScripts.

Some people on this thread don’t think this is an issue.  Other people on this thread, and in related duplicate bugs, do consider it an issue.

Very disappointed @Uwe is closing this bug.

(In reply to barefootguru from comment #73)
> Some people on this thread don’t think this is an issue.  Other people on
> this thread, and in related duplicate bugs, do consider it an issue.
> 
> Very disappointed @Uwe is closing this bug.

+1

(In reply to Frank Fuchs from comment #72)
> I am happy to open a new bug report on this but I think it directly involves
> the language installation process (because the LO package is changed by it)
> and not just the notarization of the LO app (which needs to be a separate
> "bug" report).

I don't think you need to create a report for it, it seems to be on the radar since a long time now: https://dev-builds.libreoffice.org/macosx-debug/notarized/

FWIW, 6.3 is supposed to be notarized, cf. bug 126409

On Catalina:

When LO is installed (in my case with Homebrew) "Save" and "Save as" (Finder) dialogs run fine (after LO is edded to list of allowed app to access desktop and document maps), but once the LO app is **changed** by running a language pack (i.e. its installer), these dialogs cannot be invoked any more.

By adding the (changed) LO app to the list of apps that are allowed access, then the save dialogs can be invoked again.

In short: the installation of a language pack should also refresh any relevant permission for the (changed) LO app.

IMHO, there is only one single and unifying Mac-like solution to this problem, bundling all the language packs that macOS has a localisation for. If the user speaks a language outside of macOS-system-provided localisations, then using a language pack is acceptable (and a common practice!).

If we provide the localisations that macOS itself provides, then it wouldn't be an issue to include a basic UI to add an extra localisation (or make it an extension, an .oxt file, problem solved).

I mean, come on, is it this hard? For years macOS users have been left with this frustration, how much extra space is this gonna take?

@ Emir Sarı (away) 
I disagree, Slovenian is not supported by Apple on macOS (as probably the only official EU language, and noone knows why) yet LO is fully localized into Slovenian since OOo2.0, so I disagree that Slovenian should not be a part of the main installation package.

I guess all languages that have a full translation of LO UI (or a certain percentage, like 80 %) could/should be included. That would make the l10n teams eager to finish translation of at least UI ...

(In reply to Emir Sarı (away) from comment #78)
> IMHO, there is only one single and unifying Mac-like solution to this
> problem, bundling all the language packs that macOS has a localisation for.
> If the user speaks a language outside of macOS-system-provided
> localisations, then using a language pack is acceptable (and a common
> practice!).
> 
> If we provide the localisations that macOS itself provides, then it wouldn't
> be an issue to include a basic UI to add an extra localisation (or make it
> an extension, an .oxt file, problem solved).
> 
> I mean, come on, is it this hard? For years macOS users have been left with
> this frustration, how much extra space is this gonna take?

Dear Emir,
This bug has been in RESOLVED FIXED for a while.
If the issue is still reproducible with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/, please report a new issue in https://bugs.documentfoundation.org/enter_bug.cgi providing, if     needed, the steps and documents to reproduce it.
Thanks for your understanding and collaboration.
Closing as RESOLVED FIXED