Bug 134607 - LO7RC1 - LANGPACK macOS language pack fails to recognize LibreOffice 7 installation as valid on Catalina and Big Sur
Summary: LO7RC1 - LANGPACK macOS language pack fails to recognize LibreOffice 7 instal...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
7.0.0.1 rc
Hardware: All macOS (All)
: highest critical
Assignee: Not Assigned
URL:
Whiteboard: target:7.0.2 target:7.2.0 target:7.1....
Keywords:
: 134926 139497 140149 140212 140379 140391 140531 140795 141170 (view as bug list)
Depends on:
Blocks: Language-Help-Packs
  Show dependency treegraph
 
Reported: 2020-07-07 10:50 UTC by Alex Thurgood
Modified: 2023-05-28 12:45 UTC (History)
21 users (show)

See Also:
Crash report or crash signature:


Attachments
Confirmed on M1 MacOS 11.2 beta, using public release 7.1.0.3 (61.61 KB, image/png)
2021-02-04 18:33 UTC, Fred
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Thurgood 2020-07-07 10:50:59 UTC
Description:
Attempting to install the French RC1 langpack with LO7RC1 results in the following error message :

/Applications/LibreOffice.app/Ce n'est pas une installation valide de LibreOffice 7.0.

Exécutez de nouveau l'installeur et choisissez une version valide de 7.0 LibreOffice

The installation of the lang pack fails.

In the first displayed window, the choice available of target is limited to a user chosen target, rather than discovering the presence of the default LibreOffice.app bundle. Selecting the user choice option and then picking out the LO bundle from the possible apps leads to the error message above.

Steps to Reproduce:
See above

Actual Results:
The lang pack fails to install.

Expected Results:
The bundle should be detected and the lang pack should be installed normally.


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Possible signing issues ?
Comment 1 [REDACTED] 2020-07-09 09:00:40 UTC
I can confirm this behaviour with the German languagepack for L07RC1 as well. I'm getting the same  error message just in German. I'm running macOS 11 Big Sur Developer Beta 2.
Comment 2 Xisco Faulí 2020-07-09 13:36:59 UTC
I can't reproduce it in

Version: 7.0.0.1
Build ID: 04ba7e3f1e51af6c5d653e543a620e36719083fd
Threads CPU : 8; OS : Mac OS X 10.14.6; UI Render : par défaut; VCL: osx
Locale: en-US (en_ES.UTF-8); Langue IHM : fr-FR
Calc: threaded

Mac Mojave 10.14.6

as you can see, LibreOffice is using the french UI
Comment 3 Xisco Faulí 2020-07-09 13:38:03 UTC
Alex, which version of Macintosh version are you using ?
Comment 4 Alex Thurgood 2020-07-10 06:30:27 UTC
Hi Xisco,

Catalina 10.15.5
Comment 6 Kamei 2020-07-16 07:08:07 UTC
I confirmed this issue too.
When I try to install the 'LibreOffice_7.0.0.1_MacOS_x86-64_langpack_ja.dmg'
the installer show following message.
'これは、LibreOffice 7.0 の有効なインストールではありません。
もう一度インストーラーを実行し、有効な LibreOffice 7.0 インストールを選択してください'
(This is not a valid installation of LibreOffice 7.0.
Run the installer again and select a valid LibreOffice 7.0 installation.)


Version: 7.0.0.1
Build ID: 04ba7e3f1e51af6c5d653e543a620e36719083fd
CPU threads: 16; OS: Mac OS X 10.15.5; UI render: GL; VCL: osx
Locale: ja-JP (ja_JP.UTF-8); UI: en-US
Calc: threaded
Comment 7 Xisco Faulí 2020-07-16 13:14:18 UTC
@Kamei, are you also using Catalina ?
Comment 8 Peter Kranz 2020-07-16 15:15:33 UTC
There is the same with the Langpack-install German RC1
Comment 9 Xisco Faulí 2020-07-16 15:26:39 UTC
(In reply to Peter Kranz from comment #8)
> There is the same with the Langpack-install German RC1

which OS version ?
Comment 10 Kamei 2020-07-17 01:19:58 UTC
@Xisco Faulí
Thank you for your replying.
Yes, I'm using on macOS 10.15.5.
Comment 11 Alex Thurgood 2020-07-18 14:59:57 UTC
*** Bug 134926 has been marked as a duplicate of this bug. ***
Comment 12 Frank Fuchs 2020-07-31 09:02:48 UTC
The bug is still there with LO 7.0.0.3.
Tested on macOS 10.15.6
How can you release with this bug being present?
Comment 13 Xisco Faulí 2020-07-31 09:50:16 UTC
I believe this might be related to bug 133511 but I fail to see why it doesn't work on Catalina and works with previous versions
Comment 14 Xisco Faulí 2020-07-31 09:57:41 UTC
For the record, I only have one version of LibreOffice installed ( 7.0.0.1 )
How many versions of LibreOffice do you have in parallel ? Does it work if you remove them all and you install LibreOffice from scratch ?
Comment 15 Frank Fuchs 2020-07-31 10:04:23 UTC
I have only exactly one version of LibO installed.
With 7.0.0.3 I replaced 6.4.6.1.
I had to completely remove 6461 including everything that AppCleaner detected belonging to 6461 - w/o that even the 7.0.0.3 base installation failed.
But even with that complete removal of 6461 and no other LibO installed, the lang pack installation failed:
- first, it could not detect the LibO package it is supposed to work on
- after selecting the LibO package in the application directory, it complained that 7.0.0.3 is not a valid LibO installation
Comment 16 steve 2020-07-31 10:22:58 UTC
macOS 10.15.6, LO 7.0RC3
Cannot confirm this problem

Downloaded and installed 7.0RC3. Ran a single time.

Downloaded and installed de language pack. Mounted, installer ran and finished as expected.

Version: 7.0.0.3
Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e
CPU-Threads: 8; BS: Mac OS X 10.15.6; UI-Render: Standard; VCL: osx
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded
Comment 17 Xisco Faulí 2020-07-31 13:56:33 UTC
Those having these problem, could you please tell how the software in called in Applications ? Is it called 'LibreOffice' or it has another name ?
Comment 18 Frank Fuchs 2020-07-31 14:53:52 UTC
It is called "LibreOffice.app" (as always).

BTW, I also tried giving both LibreOffice and the LibreOffice Language installer app full disk access rights in macos 10.15.6 - unfortunately, this did not help (at least we can rule this out).

I also tried and set full read and write access rights for all users to the LibreOffice.app before installing the language pack - again, no success.
Comment 19 Xisco Faulí 2020-07-31 14:58:57 UTC
(In reply to Frank Fuchs from comment #18)
> It is called "LibreOffice.app" (as always).
> 
> BTW, I also tried giving both LibreOffice and the LibreOffice Language
> installer app full disk access rights in macos 10.15.6 - unfortunately, this
> did not help (at least we can rule this out).
> 
> I also tried and set full read and write access rights for all users to the
> LibreOffice.app before installing the language pack - again, no success.

Hi Frank,
What do you get when you run from commandline < mdls --raw --name kMDItemDisplayName --name kMDItemVersion /Applications/LibreOffice.app | xargs -0 | fgrep 'LibreOffice 7.0.0.3' > and < mdfind "kMDItemContentType == 'com.apple.application-bundle' && kMDItemDisplayName == 'LibreOffice' > ??
Comment 20 Frank Fuchs 2020-07-31 15:06:30 UTC
zsh: = not found
Comment 21 Xisco Faulí 2020-07-31 16:02:49 UTC
(In reply to Frank Fuchs from comment #20)
> zsh: = not found

Which both commands ? Is it the same problem as described here https://medium.com/@singhaniatanay18/mac-os-catalina-update-zsh-instead-of-bash-d688f68f70b8 ?
Comment 22 Frank Fuchs 2020-07-31 16:10:31 UTC
Sorry:
* First command: no output
* second command: after adding an " at the end, I also get no output
Comment 23 Xisco Faulí 2020-07-31 16:45:35 UTC
(In reply to Frank Fuchs from comment #22)
> Sorry:
> * First command: no output
> * second command: after adding an " at the end, I also get no output

First command returns 'LibreOffice 7.0.0.3' for me and the seconds all the pathes where LibreOffice.app is present.
According to your comment 18, it should have return /Applications/LibreOffice.app
Comment 24 Kamei 2020-08-03 04:13:29 UTC
(In reply to Xisco Faulí from comment #23)
> (In reply to Frank Fuchs from comment #22)

A few corrections

$ mdls --raw --name kMDItemDisplayName --name kMDItemVersion /Applications/LibreOffice.app | xargs -0 | fgrep 'LibreOffice.app 7.0.0.3'

LibreOffice.app 7.0.0.3

$ mdfind "kMDItemContentType =='com.apple.application-bundle' && kMDItemDisplayName == 'LibreOffice.app'"

/Applications/LibreOffice.app


But this issue is still occurred on my environment.

Version: 7.0.0.3
Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e
CPU threads: 16; OS: Mac OS X 10.15.6; UI render: GL; VCL: osx
Locale: ja-JP (ja_JP.UTF-8); UI: en-US
Calc: threaded
Comment 25 Christian Lohmaier 2020-08-03 09:48:45 UTC
(In reply to Kamei from comment #24)
> 
> $ mdls --raw --name kMDItemDisplayName --name kMDItemVersion
> /Applications/LibreOffice.app | xargs -0 | fgrep 'LibreOffice.app 7.0.0.3'
> 
> LibreOffice.app 7.0.0.3

So to avoid any confusion: In a previous commit you wrote you were trying to install LibreOffice_7.0.0.1_MacOS_x86-64_langpack_ja.dmg - so the languagepack from rc1, but you have LibreOffice 7.0.0.3 (rc3) installed.

So in this case the message is correct - the languagepacks want the exact same version. (a conservative approach, in theory the data files would likely be compatible, but only allowing same version just eliminates another point of failure).

So please confirm that you tried the installation of the languagepack with the rc3 version as well.
Comment 26 steve 2020-08-03 09:56:41 UTC
NEEDINFO until feedback is in
Comment 27 Kamei 2020-08-04 01:55:15 UTC
(In reply to Christian Lohmaier from comment #25)

Sorry for my lack of explanation.
I installed 7.0 RC3 and then tried LibreOffice_7.0.0.3_MacOS_x86-64_langpack_ja.dmg and it's still the same situation.
Comment 28 Italo Vignoli 2020-08-04 13:39:31 UTC
macOS 10.15.6
issue same with all LibreOffice 7.0 RCs and Italian language pack
message tells me to provide a valid LibreOffice 7.0 installation
Comment 29 Xisco Faulí 2020-08-04 13:42:07 UTC
(In reply to Italo Vignoli from comment #28)
> macOS 10.15.6
> issue same with all LibreOffice 7.0 RCs and Italian language pack
> message tells me to provide a valid LibreOffice 7.0 installation

What do you get from the commandlines from comment 24 ?
Comment 30 Alex Thurgood 2020-08-04 14:05:43 UTC
The FR lang pack installation still fails for me with 7.0.0.3

Tried :

mdls --raw --name kMDItemDisplayName --name kMDItemVersion /Applications/LibreOffice.app | xargs -0 | fgrep 'LibreOffice.app 7.0.0.3'

LibreOffice.app 7.0.0.3

mdfind "kMDItemContentType =='com.apple.application-bundle' && kMDItemDisplayName == 'LibreOffice.app'"
/Applications/LibreOffice.app

Version: 7.0.0.3
Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e
CPU threads: 8; OS: Mac OS X 10.15.5; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Calc: threaded
Comment 31 Italo Vignoli 2020-08-04 15:37:23 UTC
(In reply to Xisco Faulí from comment #29)
> (In reply to Italo Vignoli from comment #28)
> > macOS 10.15.6
> > issue same with all LibreOffice 7.0 RCs and Italian language pack
> > message tells me to provide a valid LibreOffice 7.0 installation
> 
> What do you get from the commandlines from comment 24 ?

italo@Italos-MacBook-Pro ~ % mdls --raw --name kMDItemDisplayName --name kMDItemVersion /Applications/LibreOffice.app | xargs -0 | fgrep 'LibreOffice.app 7.0.0.3'
LibreOffice.app 7.0.0.3
italo@Italos-MacBook-Pro ~ % mdfind "kMDItemContentType =='com.apple.application-bundle' && kMDItemDisplayName == 'LibreOffice.app'"
/Applications/LibreOffice.app
Comment 32 Kamei 2020-08-05 07:13:45 UTC
(In reply to steve -_- from comment #16)
> macOS 10.15.6, LO 7.0RC3
> Cannot confirm this problem
> 
> Downloaded and installed 7.0RC3. Ran a single time.
> 
> Downloaded and installed de language pack. Mounted, installer ran and
> finished as expected.
> 
> Version: 7.0.0.3
> Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e
> CPU-Threads: 8; BS: Mac OS X 10.15.6; UI-Render: Standard; VCL: osx
> Locale: de-DE (de_DE.UTF-8); UI: de-DE
> Calc: threaded

I cannot install de Lang Pack (LibreOffice_7.0.0.3_MacOS_x86-64_langpack_de.dmg) as well as ja on my enviroinment.
Installer shows "Starten Sie das Installationsprogramm erneut und wählen Sie eine gültige Installation von LibreOffice 7.0".

Version: 7.0.0.3
Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e
CPU threads: 16; OS: Mac OS X 10.15.6; UI render: GL; VCL: osx
Locale: ja-JP (ja_JP.UTF-8); UI: en-US
Calc: threaded
Comment 33 Christian Lohmaier 2020-08-05 09:33:42 UTC
did see this effect once now, but with different symptoms and also could not reproduce after updating to 10.15.6

When it failed that one time for me, Catalina failed to index the new LibreOffice.app (that I dragged to Desktop), and instead tried to install to the 6.4.2 that I had in /Applications, so that failed as expected (what was not expected of course is that it didn't offer the new one from Desktop)

manually running mdfind didn't include it, and even weirder running mdls on the app folder directly did return nothing at all once, and after that just undefined values (so again expected that the languagepack script would refuse to install, but of course not expected that system tools fail to work as expected).
After reboot the new copy I installed to Desktop did show up in mdfind, and was offered in the langpack installer to pick from, but mdls (and hence the installer) still failed.
Tried to extract again and order macOS to replace the existing copy and also tried to delete the copy and install again, but that didn't change the mdls problem - it was found by mdfind, but mdls still didn't return valid data.

I then updated to 10.15.6 and rebooted and from that point on I was no longer able to recreate the effect, mdls always returned valid info, and the languagepack installscript was happy/did work.

While I was "happy" at first that I could see a failing installer on one of the systems I can lay my hands on, it again was extremely frustrating that it was yet a different failure compared to what was described here, and clearly a bug in macOS. Even more frustrating that I didn't have the problem anymore after installing the Catalina update, but people in this bug also have it with 10.15.6, so also can not be dismissed as an apple bug/we can't just tell people to update macOS and all will be fine :-((

I still have no clue at all how it could fail repeatedly/reproducibly on systems where the mdfind/mdls commands return the expected result/Why it works on some systems, but not on others.

The default user shell doesn't matter - applescript's "do shell command" is always executed using /bin/sh (bourne shell), no matter what the user did configure. And my Catalina installation is a pristine one with the zsh as default and no development or other third party stuff installed. Only thing that the installation did see was previous versions of LibreOffice, apart from that it was a fresh install via macOS internet recovery without carrying any data over.

tldr:
Since it is a real/independently confirmed problem, and the ratio of affected users is unknown, but certainly not insignificant, I'll build new languagepacks that skip that check completely.
Comment 34 Alex Thurgood 2020-08-06 06:30:11 UTC
With the release of 7.0 GA, I have just downloaded both the main app bundle and FR langpack.

The FR langpack installer still fails to displau a valid LO70 installation entry. At least the manual selection option now works though, so there is some improvement.
Comment 35 Xisco Faulí 2020-08-06 08:32:45 UTC
(In reply to Christian Lohmaier from comment #33)
> tldr:
> Since it is a real/independently confirmed problem, and the ratio of
> affected users is unknown, but certainly not insignificant, I'll build new
> languagepacks that skip that check completely.

For the record, the languagepacks for LibreOffice 7.0 RC3 were reuploaded skipping the check.
Could you all please redownloaded the new langpack for your language and try again ?
Comment 36 Alex Thurgood 2020-08-06 09:20:39 UTC
(In reply to Xisco Faulí from comment #35)


> For the record, the languagepacks for LibreOffice 7.0 RC3 were reuploaded
> skipping the check.
> Could you all please redownloaded the new langpack for your language and try
> again ?

I downloaded the 7.0 release and corresponding FR langpack this morning, cf. comment 34.
Comment 37 Alex Thurgood 2020-08-06 10:03:16 UTC
The same problem has just been reported separately on the French discuss m-l, with regard to High Sierra 10.13.
Comment 38 Frank Fuchs 2020-08-06 12:25:52 UTC
I re-installed LO 7.0.0.3 (replacing 6.4.6.1 completely).
Afterwards, I tried with the updated German language pack installer:
* It could not find the LO Application
* After manually selecting the LO Application from the application directory, it successfully installed.

So it seems both the check (now removed) and the way to identify the installed LO is not working correctly - at least on some systems, including mine.
The good news is that it is now installable through the manual selection of the target application (not sure if this is fine with non-tech users).

macOS 10.15.6
no shell extensions, default zsh shell
Comment 39 Christian Lohmaier 2020-08-06 14:15:47 UTC
The could not find LO problem could be the same as I was seeing - can you confirm that 

mdfind "kMDItemContentType =='com.apple.application-bundle' && kMDItemDisplayName == 'LibreOffice.app'"

(all in a single line) 

Doesn't return the location of LO 7.0 for you Alex & Frank?

or if it does now, does re-running the installer now manage to locate the 7.0 installer?

Did you do a full shutdown and reboot in the meantime (as opposed to just a deep sleep?)

And does 

mdls /path/to/LibreOffice7.0.app

return valid data for you?
In a previous comment#30 before replacing the 7.0 app Alex wrote the results of the commands and they returned the expected results…
Comment 40 Frank Fuchs 2020-08-06 16:45:48 UTC
Hi Christian,

re your questions in comment 39 (after I successfully installed the German language pack (see my comment 38)):

1) mdfind "kMDItemContentType =='com.apple.application-bundle' && kMDItemDisplayName == 'LibreOffice.app'"
now returns
/Applications/LibreOffice.app
which is correct

2) does re-running the installer now manage to locate the 7.0 installer?
NO

3) Did you do a full shutdown and reboot in the meantime (as opposed to just a deep sleep?)
NO

4) mdls /Applications/LibreOffice.app
now returns a lot of meaningful information:
_kMDItemDisplayNameWithExtensions      = "LibreOffice.app"
kMDItemAlternateNames                  = (
    "LibreOffice.app"
)
kMDItemAppStoreCategory                = "Produktivität"
kMDItemAppStoreCategoryType            = "public.app-category.productivity"
kMDItemCFBundleIdentifier              = "org.libreoffice.script"
kMDItemContentCreationDate             = 2020-07-29 22:46:08 +0000
kMDItemContentCreationDate_Ranking     = 2020-07-29 00:00:00 +0000
kMDItemContentModificationDate         = 2020-07-29 22:46:08 +0000
kMDItemContentModificationDate_Ranking = 2020-07-29 00:00:00 +0000
kMDItemContentType                     = "com.apple.application-bundle"
kMDItemContentTypeTree                 = (
    "com.apple.application-bundle",
    "com.apple.application",
    "public.executable",
    "com.apple.localizable-name-bundle",
    "com.apple.bundle",
    "public.directory",
    "public.item",
    "com.apple.package"
)
kMDItemDateAdded                       = 2020-08-06 12:18:29 +0000
kMDItemDateAdded_Ranking               = 2020-08-06 00:00:00 +0000
kMDItemDisplayName                     = "LibreOffice.app"
kMDItemDocumentIdentifier              = 0
kMDItemExecutableArchitectures         = (
    "x86_64"
)
kMDItemFSContentChangeDate             = 2020-07-29 22:46:08 +0000
kMDItemFSCreationDate                  = 2020-07-29 22:46:08 +0000
kMDItemFSCreatorCode                   = ""
kMDItemFSFinderFlags                   = 0
kMDItemFSHasCustomIcon                 = (null)
kMDItemFSInvisible                     = 0
kMDItemFSIsExtensionHidden             = 1
kMDItemFSIsStationery                  = (null)
kMDItemFSLabel                         = 0
kMDItemFSName                          = "LibreOffice.app"
kMDItemFSNodeCount                     = 1
kMDItemFSOwnerGroupID                  = 80
kMDItemFSOwnerUserID                   = 501
kMDItemFSSize                          = (null)
kMDItemFSTypeCode                      = ""
kMDItemInterestingDate_Ranking         = 2020-08-06 00:00:00 +0000
kMDItemKind                            = "Programm"
kMDItemLastUsedDate                    = 2020-08-06 12:21:00 +0000
kMDItemLastUsedDate_Ranking            = 2020-08-06 00:00:00 +0000
kMDItemUseCount                        = 2
kMDItemUsedDates                       = (
    "2020-08-05 22:00:00 +0000"
)
kMDItemVersion                         = "7.0.0.3"
Comment 41 Alex Thurgood 2020-08-07 07:55:41 UTC
(In reply to Frank Fuchs from comment #40)

> 1) mdfind "kMDItemContentType =='com.apple.application-bundle' &&
> kMDItemDisplayName == 'LibreOffice.app'"
> now returns
> /Applications/LibreOffice.app
> which is correct

Same here.

> 
> 2) does re-running the installer now manage to locate the 7.0 installer?
> NO

Same here with FR langpack. No automatic discovery of the installed LO bundle even after re-running the langpack installer.



> 3) Did you do a full shutdown and reboot in the meantime (as opposed to just
> a deep sleep?)
> NO

YES, from a cold boot.
Comment 42 Kamei 2020-08-12 01:55:58 UTC
I could install JA lang pack.

I change the line 69 of 'LibreOffice Language Pack.app/Contents/osx_install.applescript'  
	set found_ooos_all to (do shell script "mdfind "kMDItemContentType == 'com.apple.application-bundle' && kMDItemDisplayName == 'LibreOffice'"")
to
	set found_ooos_all to (do shell script "mdfind "kMDItemContentType == 'com.apple.application-bundle' && kMDItemDisplayName == 'LibreOffice.app'"")

And change the line 129
	do shell script "mdls --raw --name kMDItemDisplayName --name kMDItemVersion " & quoted form of (choice as string) & " | xargs -0 | fgrep 'LibreOffice 7.0'"
to
	do shell script "mdls --raw --name kMDItemDisplayName --name kMDItemVersion " & quoted form of (choice as string) & " | xargs -0 | fgrep 'LibreOffice.app 7.0'"


Then, Run the Script. 

environment:

Version: 7.0.0.3
Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e
CPU threads: 16; OS:Mac OS X 10.15.6; UI render: GL; VCL: osx
Locale: ja-JP (ja_JP.UTF-8); UI: ja-JP
Calc: threaded
Comment 43 Kamei 2020-08-12 02:19:36 UTC
Sorry. The escape character for line 69 is missing.
line 69
	set found_ooos_all to (do shell script "mdfind \"kMDItemContentType == 'com.apple.application-bundle' && kMDItemDisplayName == 'LibreOffice'\"")
to
	set found_ooos_all to (do shell script "mdfind \"kMDItemContentType == 'com.apple.application-bundle' && kMDItemDisplayName == 'LibreOffice.app'\"")

Line number 129 is as shown in the earlier post.
Comment 44 Frank Fuchs 2020-08-13 20:40:08 UTC
LibO 7.0.1.1 is back to the old behaviour: 
* The language pack installation cannot find the LibO app
* if manually selected, it complains about an invalid LibO file

Apparently, someone put the (not working) check back in to the Mac language packs.

Until this bug is fixed, can someone please re-deploy the Mac language packs w/o this check (same as done for 7.0.0.3).
Comment 45 Xisco Faulí 2020-08-14 07:04:28 UTC
(In reply to Frank Fuchs from comment #44)
> LibO 7.0.1.1 is back to the old behaviour: 
> * The language pack installation cannot find the LibO app
> * if manually selected, it complains about an invalid LibO file
> 
> Apparently, someone put the (not working) check back in to the Mac language
> packs.
> 
> Until this bug is fixed, can someone please re-deploy the Mac language packs
> w/o this check (same as done for 7.0.0.3).

Yes, that's because the check hasn't been remove in the code yet.
Comment 46 Frank Fuchs 2020-08-29 08:08:49 UTC
Unbelievable, but LibO 7.0.1.2 has the very same problem.
IMHO, you cannot release 7.0.1 with this showstopper.
Either this needs a fix or - as a workaround until a fix is implemented - the installation check needs to be removed from the language packs.
Comment 47 Xisco Faulí 2020-09-01 16:54:39 UTC
(In reply to Frank Fuchs from comment #46)
> Unbelievable, but LibO 7.0.1.2 has the very same problem.
> IMHO, you cannot release 7.0.1 with this showstopper.
> Either this needs a fix or - as a workaround until a fix is implemented -
> the installation check needs to be removed from the language packs.

Yes, builds are being rebuilt with the workaround included. thanks for noticing.
Comment 48 Commit Notification 2020-09-07 16:16:11 UTC
Christian Lohmaier committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/d6667aec86718cc4b843a69658fcc83203d66734

tdf#134607 workaround – mac langpack: don't verify target location

It will be available in 7.0.2.

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

Affected users are encouraged to test the fix and report feedback.
Comment 49 Tino Hendricks 2020-12-16 17:48:55 UTC
Same here on Big Sur 11.0.1 (20B29)

Error reads: 
(sorry, German)

"/Applications/LibreOfficeDev.app/Dies ist keine gültige Installation von LibreOfficeDev 7.1.

Starten Sie das Installationsprogramm erneut und wählen Sie eine gültige Installation von LibreOfficeDev 7.1"

I have a working and localized installation of LO 7.0.3.1 d7547858d014d4cf69878db179d326fc3483e082
also sitting in Applications.
Comment 50 Frank Fuchs 2020-12-22 20:35:48 UTC
LibO 7.1.0.1 (7.1 RC1) cannot install any language pack - the workaround introduced in LibO 7.0 seems to be MISSING in 7.1

Tested on macOS 11.1 (big sur) with LibO 7.1.0.1 on a MacBook Pro 15" 2018.
Comment 51 Alex Thurgood 2021-01-12 09:02:14 UTC
*** Bug 139497 has been marked as a duplicate of this bug. ***
Comment 52 Alex Thurgood 2021-01-12 09:04:22 UTC
(In reply to Alex Thurgood from comment #51)
> *** Bug 139497 has been marked as a duplicate of this bug. ***

I'm having the same problem as Frank in comment 50 with BigSur/Mac silicon M1 and 7.1RC1, seems like the fix was not applied to master before branch off for 7.1 ?
Comment 53 [REDACTED] 2021-01-31 10:38:47 UTC
Repro 

Version: 7.1.0.3 / LibreOffice Community
Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c
CPU threads: 4; OS: Mac OS X 10.16; UI render: default; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Tried langpacks:
[1] LibreOffice_7.1.0.3_MacOS_x86-64_langpack_en-GB.dmg
[2] LibreOffice_7.1.0.3_MacOS_x86-64_langpack_de.dmg

Ends with error notification (popup)

/Applications/LibreOffice.app/This is not a valid LibreOffice 7.1 installation.
Run the installer again and choose a valid LibreOffice 7.1 installation

(or with the German translation of that)


$ mdls --raw --name kMDItemDisplayName --name kMDItemVersion /Applications/LibreOffice.app | xargs -0 | fgrep 'LibreOffice.app 7.1.0.3'

LibreOffice.app 7.1.0.3

$ mdfind "kMDItemContentType =='com.apple.application-bundle' && kMDItemDisplayName == 'LibreOffice.app'"

/Applications/LibreOffice.app
Comment 54 Wim M 2021-02-03 12:00:06 UTC
Confirming this bug. I was unable to install the en-GB language pack on the release version of 7.1.0 on macOS.

Version: 7.1.0.3 / LibreOffice Community
Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c
CPU threads: 8; OS: Mac OS X 10.15.7; UI render: GL; VCL: osx
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded
Comment 55 Christian Lohmaier 2021-02-03 19:33:04 UTC
Good news everyone, seems that Florian just stumbled upon what is causing the issues:

* the bug occurs if you configure finder to show all file extensions

so that also is the simple workaround: To install the languagepack disable the setting to show all suffixes (you can reenable it after installing the language pack)

That all explains why it is reproducible for some, esp. people in QA, but not as widespread of a problem...


Finder | Properties | Advanced -> first option there..
Comment 56 Photokabinett 2021-02-04 16:03:58 UTC
Unfortunately, the solution works in the Finder to disable the setting option “Show all filename suffixes”  for me with the following configuration NOT!

macOS Big Sur Version 11.2
LibreOffice_7.1.0_macos_x86-64
libreOffice_7.1.0_macos_x86-64_langpack_en

After uninstalling the LO above, I installed the previous version 7.0.4 again and was able to add the de-langpack 7.0.4 again (without removing the hook in the Finder setting).

On two older MBP (one from Mid 2012, the other at the end of 2014) the same result: 7.1.0 langpack installation no, 7.0.4 langpack installation without any problems yes!
Comment 57 Frank Fuchs 2021-02-04 16:06:43 UTC
The workaround worked for me:
macOS 11.2
LibreOffice 7.1.0.3
German language pack 7.1.0.3
MacBook Pro 15" 2018
Comment 58 Fred 2021-02-04 18:33:00 UTC
Created attachment 169478 [details]
Confirmed on M1 MacOS 11.2 beta, using public release 7.1.0.3

Confirmed for MacOS Big Sur 11.2 beta running on an M1 Mac mini.

I used the formally released version 7.1.0.3, i.e. files:

LibreOffice_7.1.0_MacOS_x86-64.dmg
LibreOffice_7.1.0_MacOS_x86-64_langpack_en-GB.dmg

The error pops up immediately.
Comment 59 Fred 2021-02-04 18:36:02 UTC
Apologies, forgot to mention that LO langpacks have required to be manually pointed at /Applications/LibreOffice.app since v7.0.  I thought this could have something to do with the MacOS need to have first execution confirmed, but starting LO before langpack execution (to get that out of the way) has not made a difference.
Comment 60 Fred 2021-02-04 18:41:37 UTC
Update: the workaround of ..

Finder - Preferences - Advanced - untick "Show all filename extensions" 

.. worked in this case too.

Strange.
Comment 61 Fred 2021-02-04 18:44:28 UTC
(and in this case, the langpack did NOT require manual indication of where the LibreOffice.app was located so these issues are related)
Comment 62 Wim M 2021-02-05 10:33:58 UTC
The workaround mentioned in Comment 55 worked for me (see Comment 54) as well.
Comment 63 Martin Häcker 2021-02-05 10:35:51 UTC
Same here workaround from comment:55 works for me.
Comment 64 pierre-yves samyn 2021-02-05 11:18:13 UTC
Hi

Workaround confirmed on Ask FR : 

https://ask.libreoffice.org/fr/question/291173/erreur-installation-pack-de-langue-71-mac-os/

Regards
Pierre-Yves
Comment 65 Commit Notification 2021-02-05 14:31:11 UTC
Christian Lohmaier committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/dbaf1d75601cb911d1c17e1e63d2c7047f2cf9e1

tdf#134607 mac-langpacks: always query for full name with extension

It will be available in 7.2.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 66 Commit Notification 2021-02-05 19:56:17 UTC
Christian Lohmaier committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/b6f74722173b0384efa6798799b83807e9f0d814

tdf#134607 mac-langpacks: always query for full name with extension

It will be available in 7.1.1.

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

Affected users are encouraged to test the fix and report feedback.
Comment 67 sophie 2021-02-06 10:44:20 UTC
*** Bug 140212 has been marked as a duplicate of this bug. ***
Comment 68 Fred 2021-02-06 11:06:37 UTC
I can confirm that the patch appears to work on my system.

System: M1 Mac mini, MacOS 11.3 beta

Source: 
/daily/libreoffice-7-1/MacOSX-x86_64@tb81-TDF/2021-02-06_07.18.19/

Files used:
LibreOfficeDev_7.1.1.0.0_MacOS_x86-64.dmg
LibreOfficeDev_7.1.1.0.0_MacOS_x86-64_langpack_en-GB.dmg

The langpack works so fast it's merely a screen flash :).

Good work.
Comment 69 Albert Wiedemann 2021-02-06 11:45:56 UTC
I can confirm too that the patch appears to work on my system.

System: iMac I5, MacOS 10.15.7 Catalina

Source: 
/daily/libreoffice-7-1/MacOSX-x86_64@tb81-TDF/2021-02-06_07.18.19/

Files used:
LibreOfficeDev_7.1.1.0.0_MacOS_x86-64.dmg
LibreOfficeDev_7.1.1.0.0_MacOS_x86-64_langpack_de.dmg

Many thanks.
Comment 70 Christoph Sold 2021-02-07 15:54:40 UTC
Me too:
- MacOS 10.13.6 High Sierra
- LibreOffice 7.1.0.3
- german Langpack, created January 28th, 2021
Comment 71 Commit Notification 2021-02-08 09:07:10 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/77699401ebfccfd8d55424d771d311639059bf4c

Revert "tdf#134607 workaround – mac langpack: don't verify target location"

It will be available in 7.0.5.

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

Affected users are encouraged to test the fix and report feedback.
Comment 72 Commit Notification 2021-02-08 11:26:38 UTC
Christian Lohmaier committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/d8ec1283220c56d78bbcee95748283ef590a674b

tdf#134607 mac-langpacks: always query for full name with extension

It will be available in 7.0.5.

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

Affected users are encouraged to test the fix and report feedback.
Comment 73 Xisco Faulí 2021-02-08 11:36:02 UTC
I think we can close this issue as RESOLVED FIXED now.

@Christian Lohmaier, thanks for fixing this issue
Comment 74 [REDACTED] 2021-02-12 19:00:15 UTC
*** Bug 140379 has been marked as a duplicate of this bug. ***
Comment 75 [REDACTED] 2021-02-13 13:48:00 UTC
*** Bug 140391 has been marked as a duplicate of this bug. ***
Comment 76 Rob 2021-02-15 16:48:25 UTC
*** Bug 140149 has been marked as a duplicate of this bug. ***
Comment 77 Xisco Faulí 2021-02-19 11:57:54 UTC
*** Bug 140531 has been marked as a duplicate of this bug. ***
Comment 78 Xisco Faulí 2021-03-04 12:09:56 UTC
*** Bug 140795 has been marked as a duplicate of this bug. ***
Comment 79 Roman Kuznetsov 2021-03-06 15:49:37 UTC
I can't install a RU language pack to LO 7.1.1 (and on latest 7.2 master build too) with the same problem. People please retest it on your macs
Comment 80 [REDACTED] 2021-03-08 12:42:53 UTC
No repro (works for me 

Version: 7.1.1.2 / LibreOffice Community
Build ID: fe0b08f4af1bacafe4c7ecc87ce55bb426164676
CPU threads: 4; OS: Mac OS X 10.16; UI render: default; VCL: osx
Locale: de-DE (de_DE.UTF-8); UI: ru-RU
Calc: threaded
Comment 81 SveDec 2021-03-08 17:36:10 UTC
Hi,

I just updated a MacBook Pro from Mavericks (10.9) to El Capitan (10.11).
I consequently updated LibreOffice from v6.2.8.2 to v7.1.1.

The bug with the langpack occurs : it can't find automatically the LibreOffice install, and manual selection ends with the invalid install message.

As the OS is older than Catalina and Big Sur, this comment might not be relevant here, but the problem seems similar. Excuse-me if this is the wrong place to report.


Some infos :

Version: 7.1.1.2 / LibreOffice Community
Build ID: fe0b08f4af1bacafe4c7ecc87ce55bb426164676
CPU threads: 4; OS: Mac OS X 10.11.6; UI render: default; VCL: osx
Locale: fr-FR (fr.UTF-8); UI: en-US
Calc: threaded

```
$ mdfind "kMDItemContentType == 'com.apple.application-bundle' && kMDItemDisplayName == 'LibreOffice'"
/Applications/LibreOffice.app

$ mdls --raw --name kMDItemDisplayName --name kMDItemVersion /Applications/LibreOffice.app | xargs -0 | fgrep 'LibreOffice'
LibreOffice 7.1.1.2

$ mdfind "kMDItemContentType == 'com.apple.application-bundle' && _kMDItemDisplayNameWithExtensions == 'LibreOffice'"
-> no result (same with 'LibreOffice.app')
```


I tried to turn the Finder's "show all file extensions" setting ON, and OFF again (it was off as default), without any change.

I also tried to remove the ".app" on lines 69 and 129 (based on https://bugs.documentfoundation.org/show_bug.cgi?id=134607#c42 but in reverse) in the `Contents/Resources/osx_install.applescript` file, without success.

Finally, I tried to replace the `_kMDItemDisplayNameWithExtensions` argument with `kMDItemDisplayName` on line 69, but then it directly displays the invalid install message.


When i try to reinstall v6.2.8.2 and its langpack, it works well.
Comment 82 SveDec 2021-03-08 17:56:28 UTC
Ok, i found the problem :

The property `_kMDItemDisplayNameWithExtensions` does not exist when i do `$ mdls /Applications/LibreOffice.app`.

I replaced it by the property `kMDItemFSName` (which as the same value "LibreOffice.app") on lines 69 and 129, and the langpack installed successfully.

In addition, in my `mdls` output, compared to comment #40 :
- `kMDItemFSName` and `kMDItemAlternateNames` are the same
- `kMDItemDisplayName` is "LibreOffice" (without the .app), because of the Finder setting i guess.
Comment 83 Christian Lohmaier 2021-03-12 11:45:21 UTC
Thanks for having a look - cannot test with all versions of macOS, so I just hope that the new patch will work independent of any user settings and on all supported versions of macOS.. patch prepared with that changed here: https://gerrit.libreoffice.org/c/core/+/112385 

Would appreciate if people watching this bug could fill in their findings with versions of macOS not listed yet for the following command:

mdls --name kMDItemFSName /path/to/LibreOffice.app

It should report »kMDItemFSName = "LibreOffice.app"« (no directories, and .app extension independent of the "show file extensions" setting in finder.

tested good: 
10.11 (comment from SveDoc)
10.14 (myself)
10.16/11 (myself)

Please comment with your results if you can test on a different version or (and especially in that case) if you get a different result. Feel free to include additional confirmation for ones listed by other users, but no need for comments that don't add new versions of macOS to that list.
Comment 84 ioannis 2021-03-15 15:52:51 UTC
Dear Christian,

I tried the command line you mentioned, please see the result bellow:
[MBP-de-Ioannis:~ ioannis$ mdls --name kMDItemFSName /path/to/LibreOffice.app
/path/to/LibreOffice.app: could not find /path/to/LibreOffice.app.

Otherwise attempt to install language pack in French failed :

/Applications/LibreOfficeDev.app/Ce n'est pas une installation valide de LibreOfficeDev 7.0.

Exécutez de nouveau l'installeur et choisissez une version valide de 7.0 LibreOfficeDev

running in this configuration:

Version: 7.0.6.0.0+
Build ID: 1ab766f0d455058e0433144acceca2d23451eca0
CPU threads: 8; OS: Mac OS X 10.12.6; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Calc: threaded

once with displayed file extensions in the finder and once not displayed

and both LibreOffice and language pack downloaded there:

https://dev-builds.libreoffice.org/daily/libreoffice-7-0/MacOSX-x86_64@tb81-
TDF/2021-03-14_07.03.24/



Same happened with LO 7.1.3.0.0

https://dev-builds.libreoffice.org/daily/libreoffice-7-1/MacOSX-x86_64@tb81-TDF/2021-03-15_07.05.48/

I hope this can help in some extend.
KR
ioannis


(In reply to Christian Lohmaier from comment #83)
> Thanks for having a look - cannot test with all versions of macOS, so I just
> hope that the new patch will work independent of any user settings and on
> all supported versions of macOS.. patch prepared with that changed here:
> https://gerrit.libreoffice.org/c/core/+/112385 
> 
> Would appreciate if people watching this bug could fill in their findings
> with versions of macOS not listed yet for the following command:
> 
> mdls --name kMDItemFSName /path/to/LibreOffice.app
> 
> It should report »kMDItemFSName = "LibreOffice.app"« (no directories, and
> .app extension independent of the "show file extensions" setting in finder.
> 
> tested good: 
> 10.11 (comment from SveDoc)
> 10.14 (myself)
> 10.16/11 (myself)
> 
> Please comment with your results if you can test on a different version or
> (and especially in that case) if you get a different result. Feel free to
> include additional confirmation for ones listed by other users, but no need
> for comments that don't add new versions of macOS to that list.
Comment 85 Henner Eurich 2021-03-16 09:19:50 UTC
(In reply to Christian Lohmaier from comment #83)
> Thanks for having a look - cannot test with all versions of macOS, so I just
> hope that the new patch will work independent of any user settings and on
> all supported versions of macOS.. patch prepared with that changed here:
> https://gerrit.libreoffice.org/c/core/+/112385 
> 
> Would appreciate if people watching this bug could fill in their findings
> with versions of macOS not listed yet for the following command:
> 
> mdls --name kMDItemFSName /path/to/LibreOffice.app
> 
> It should report »kMDItemFSName = "LibreOffice.app"« (no directories, and
> .app extension independent of the "show file extensions" setting in finder.
> 
> tested good: 
> 10.11 (comment from SveDoc)
> 10.14 (myself)
> 10.16/11 (myself)
> 
> Please comment with your results if you can test on a different version or
> (and especially in that case) if you get a different result. Feel free to
> include additional confirmation for ones listed by other users, but no need
> for comments that don't add new versions of macOS to that list.

The command returned "could not find /path/to/LibreOffice.app." on my MacBook late 2008 (OSX 10.11.6, LibreOffice 7.1.1.2); languagepack german does not install. Same with 7.0.5. At last I installed the language files manually, which was no joy. The "show file extensions" setting makes no difference on my machine. The problem first occured, after I updated to 7.1.1.2. Former versions of languagepack installed fine on same system. But going back to 7.0.5 did not solve the problem, as mentioned above. 
Idea: Maybe it has to do with a preference-file, that was written when updating to 7.1.1, so that all further languagepack installations fail?
Comment 86 Christian Lohmaier 2021-03-16 14:58:06 UTC
sorry for not being clear. /path/to/LibreOffice.app needs to be adjusted for the actual path you placed the LibreOffice.app.

If you put it into the global Applications folder, use /Applications/LibreOffice.app instead.

If you're using a daily build, also user LibreOfficeDev.app accordingly. (e.g. /Applications/LibreOfficeDev.app)
Comment 87 Commit Notification 2021-03-16 14:59:49 UTC
Christian Lohmaier committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/daa162c20f4c7d61edc217ed44cb2854652a63ec

tdf#134607 use kMDItemFSName instead of _kMDItemDisplayNameWithExtensions

It will be available in 7.2.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 88 Commit Notification 2021-03-17 10:05:08 UTC
Christian Lohmaier committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/00ce3c5c8238035dc0c470e54f055b2406bffd64

tdf#134607 use kMDItemFSName instead of _kMDItemDisplayNameWithExtensions

It will be available in 7.0.6.

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

Affected users are encouraged to test the fix and report feedback.
Comment 89 Commit Notification 2021-03-17 10:05:31 UTC
Christian Lohmaier committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/78f69c686c9f8b40fbd183dde71e94d4d7a729ab

tdf#134607 use kMDItemFSName instead of _kMDItemDisplayNameWithExtensions

It will be available in 7.1.3.

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

Affected users are encouraged to test the fix and report feedback.
Comment 90 Commit Notification 2021-03-17 16:53:40 UTC
Christian Lohmaier committed a patch related to this issue.
It has been pushed to "libreoffice-7-1-2":

https://git.libreoffice.org/core/commit/40ae5790249811b38f6fafbda5f1396fdb12e996

tdf#134607 use kMDItemFSName instead of _kMDItemDisplayNameWithExtensions

It will be available in 7.1.2.

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

Affected users are encouraged to test the fix and report feedback.
Comment 91 keyopen 2021-03-19 17:23:23 UTC
I have the same problem with Mac Os 10.11.6 (El Capitan). As workaround I have used the previous LibreOffice_7.0.4_MacOS_x86-64_langpack_it and it works.
Comment 92 [REDACTED] 2021-03-22 12:21:35 UTC
*** Bug 141170 has been marked as a duplicate of this bug. ***
Comment 93 steve 2021-03-23 10:12:14 UTC
@keyopen Could you install LibreOffice nightly build and see if the problem persists using that build:
https://dev-builds.libreoffice.org/daily/master

You should able to install LanguagePack as expected using that build.
Comment 94 Philippe Tharin 2021-03-23 11:12:34 UTC
Thanks, today's version LibreOfficeDev_7.2.0.0.alpha0_MacOS_x86-64.dmg and langpack_en (2021-Mar-22) installs correctly.
Comment 95 Xisco Faulí 2021-03-25 14:57:41 UTC
(In reply to Philippe Tharin from comment #94)
> Thanks, today's version LibreOfficeDev_7.2.0.0.alpha0_MacOS_x86-64.dmg and
> langpack_en (2021-Mar-22) installs correctly.

Thanks for checking. Le'ts close it as VERIFIED FIXED
Comment 96 Nerd Bert 2021-04-02 14:55:24 UTC
All that what I saw on this page didn´t work for me (Catalina, LibreOffice 7.1.2.2 and de-Languagepack)

So I tried a different workaround, that at least works for me. I copied the language files by hand. Hope it helps you too

Steps, after you installed libreOffice:

- Download Language-Pack of your choice that has exactly the same release as your libreoffice release
- Open it in Finder (start it, it will mount the volume but don´t do anything else)
- Now open terminal and create a folder, I named it LP: 
- mkdir LP
- cd LP
- Check, what your language is and change (de) in next step to your language-letter:
- cp -pr /Volumes/LibreOffice\ de\ Language\ Pack/ .
- cd cd LibreOffice\ Language\ Pack.app/Contents/Resources
- tar -xzf tarball.tar.bz2
- cd Contents/Resources
- Now we copy all that stuff to the folder of the LibreOffice-Application. In my case its located in /Applications/LibreOffice.app:
- cp -pr . /Applications/LibreOffice.app/Contents/Resources
- go to that folder: 
- cd /Applications/LibreOffice.app/Contents/Resources
- Now we need to set the rights of the group to right value
- chgrp -R admin .

Start your LibreOffice at enjoy it in your language

Cheers,
Nerd Bert
Comment 97 fc761 2021-04-29 22:53:38 UTC
Idem on 
Version: 7.1.2.2 / LibreOffice Community
Build ID: 8a45595d069ef5570103caea1b71cc9d82b2aae4
CPU threads: 2; OS: Mac OS X 10.11.6; UI render: default; VCL: osx
Locale: fr-FR (fr.UTF-8); UI: en-US
Calc: threaded

Test also with LibreOffice Language Pack in the App Folder.
And with or without extension name

Sorry, this is the first report for me.
So, there's probably not a lot of new information, just confirmation that's it's still not working on last version of LO, and old version of MacOS
Comment 98 Frederic G. MARAND 2021-08-24 20:04:09 UTC
Problem is here again in 7.1.5.2

$ echo $LANG
fr_FR.UTF-8
$
$ uname -a
Darwin FGM-GUI15.local 20.6.0 Darwin Kernel Version 20.6.0: Wed Jun 23 00:26:31 PDT 2021; root:xnu-7195.141.2~5/RELEASE_X86_64 x86_64
$
$ mdls --name kMDItemDisplayName --name kMDItemVersion /Applications/LibreOffice.app
kMDItemDisplayName = (null)
kMDItemVersion     = (null)
$
$ mdfind "kMDItemContentType == 'com.apple.application-bundle'" | grep Libre
$

Message during Language pack install (without the quotes), in a "osascript" app:
- "Non listé (choississez l'emplacement lors d'une étape supplémentaore"
- then 
  - "/Applications/LibreOffice.app/Ce n'est pas une installation valide de LibreOffice 7.1."
  - "Executez de nouveau l'installeur et choisissez une version valide de 7.1 LibreOffice"
  - "Installer" button
Comment 99 steve 2021-08-25 10:31:21 UTC
After discussing with cloph the remaining problem of mdls reporting no info or null value is a bug in macOS. That aspect can only be fixed on Apples side. Feel free to report the problem to Apple using macOS Feeback Assistant to make them aware of the issue.
Comment 100 Arkadiusz Miśkiewicz 2021-09-01 18:35:45 UTC
But md* (mdfind mainly) tools use spotlight and you can have spotlight disabled. 

Here I have spotlight disabled and thus md* won't be able to find anything new that is not already indexed by spotlight.


arekm@amb ~ % mdutil -s /Applications/
/System/Volumes/Data/Applications:
	Indexing disabled.

And indeed:

arekm@amb ~ % mdfind "kMDItemContentType =='com.apple.application-bundle' && kMDItemDisplayName == 'LibreOffice.app'"
arekm@amb ~ % mdls /Applications/LibreOffice.app
kMDItemFSContentChangeDate = 2021-08-16 23:51:29 +0000
kMDItemFSCreationDate      = 2021-08-16 23:51:29 +0000
kMDItemFSCreatorCode       = ""
kMDItemFSFinderFlags       = 0
kMDItemFSHasCustomIcon     = 0
kMDItemFSInvisible         = 0
kMDItemFSIsExtensionHidden = 0
kMDItemFSIsStationery      = 0
kMDItemFSLabel             = 0
kMDItemFSName              = "LibreOffice.app"
kMDItemFSNodeCount         = 1
kMDItemFSOwnerGroupID      = 80
kMDItemFSOwnerUserID       = 501
kMDItemFSSize              = 1
kMDItemFSTypeCode          = ""


Why not iterate over /Applications/*.app (or just check /Applications/LibreOffice*.app), check interesting parts + still do mdfind solution, so there are more changes to get this working?
Comment 101 Dominique Quatravaux 2023-01-16 14:38:00 UTC
As of today, it looks like the proper `mdfind` query is

mdfind "kMDItemDisplayName == 'LibreOffice' && kMDItemContentType =='com.apple.application-bundle'"

⚠ This will only succeed after FileVault has had a chance to validate your installation of LibreOffice — i.e. you have to run it once. If you don't, the symptom looks a lot like 134607 all over again:

mdls --name kMDItemDisplayName --name kMDItemVersion /Applications/LibreOffice.app
kMDItemDisplayName = (null)
kMDItemVersion     = (null)
Comment 102 Yves 2023-03-31 17:37:50 UTC
On MacOS 10.14.6 with LibreOffice Community 7.5.1:
$ cd
$ mdls --name kMDItemDisplayName --name kMDItemVersion /Applications/LibreOffice.app
kMDItemDisplayName = "LibreOffice.app"
kMDItemVersion     = (null)
$ mdfind "kMDItemDisplayName == 'LibreOffice' && kMDItemContentType =='com.apple.application-bundle'"
$ whoami
nonadminuser
$ ls -la /Applications/LibreOffice.app
total 0
drwxr-xr-x@   3 nonadminuser  admin    96 Feb 23 02:35 .
drwxrwxr-x+ 114 root  admin  3648 Mar 28 16:32 ..
drwxr-xr-x@   9 nonadminuser  admin   288 Feb 23 03:03 Contents

Enabling or disabling show all file extensions is not changing.
Running with user account and user account with admin priviledges does not change. Please note that all applications where installed with non admin user typing name/password of admin user in GUI.

So issue is still open for me. Why not create simple bash script in package that allows manual unzip? Patch does seem to do no more than exploding tarball.tar.bz2 into existing installation.
Comment 103 Uwe Altmann 2023-05-28 12:45:39 UTC
I tried several versions, also running in the problem. Last one working as expected here (with "Show suffixes" enabled) was 7.4.5 and 7.5.1
From what I found out: The app *must* be named "LibreOffice" - something like "LibreOffice7.5.2" won't work at all (but did in the past).
So installing the app, run "sudo codesign -vvv --deep --strict /Applications/LibreOffice.app" and then the LangPack installer worked properly. (No clue if codesign is necessary, but it helped in the past.) 

(MacOS Intel 12.6.5.)