Description:
This is my first bug report, so please forgive me if there is something not properly filed. 
This report is a mixture of an issue and an enhancement request, so it was not clear to me how to file this report. 

A few details:
The macOS version of LibreOffice has only the EN language built-in. This applies to both architectures, Apple Silicon and Intel. LibreOffice is properly signed and notarized with a Apple Developer ID certificate, means anyone is able to drag&drop LibreOffice to the /Applications folder and open it right away without security warnings. 
The issue starts when installing a language pack: the language pack content is placed inside the LibreOffice bundle in /Applications, which breaks the app signature. 
On the most recent macOS versions, the language pack installation will only work when specific steps are followed during LibreOffice installation: Drag LibreOffice to /Applications => open LibreOffice and close it again => install the language pack => open it again and LibreOffice will start in the desired language. 
This is not just a cosmetic issue, it's a violation of how app signatures, code signing and app security is handled on the macOS platform. 
The reason why this works only in this specific order is how app signatures work in macOS and how Gatekeeper protects from modifications: 
https://support.apple.com/en-us/guide/security/secf826eff27/web

A short summary: Gatekeeper will check every app typically once - during the first launch (there are a few cases where Gatekeeper regularly checks signatures etc, but let's keep it simple for this example). When the app signature is ok, Gatekeeper will allow the app to be opened. Installing a language pack BEFORE the app is started at least once will force Gatekeeper to deny app launch and move the app to Trash because "it is damaged". From a technical perspective, this is totally correct as the signature is messed up because contents of the LibreOffice app bundle are modified. There is no way for Gatekeeper to determine if the app was modified by an attacker, by an admin or whoever. 
When talking about mass deployments, this is also a problem as enterprises typically allow only properly signed and notarized software to run on managed Macs. As a consequence, language pack installations may lead into unnecessary discussions.

This is the "bug" part of this request. Now to the enhancement request:
There is a pretty easy fix for this issue: include all language packs into the LibreOffice bundle BEFORE LibreOffice is signed and sent to notarization. This would not only resolve the mentioned issue above but also smoothens UX during LibreOffice installation on macOS, as all languages are already included. For enterprise deployments, this would also get some benefits, especially for enterprises that rely on other languages than English. 
IMHO, the few Megabytes that LibreOffice will grow by including all language packs is bearable compared to the benefits (proper signatures, better UX, better mass deployment). 

Steps to Reproduce:
1. Download LibreOffice and the language pack
2. Drag&Drop LibreOffice to /Applications
3. Install the language pack (no matter which one)
4. Open LibreOffice to get "App is damaged an needs to be moved to Trash"

Actual Results:
App signature is broken due to language pack installation

Expected Results:
LibreOffice includes all language packs and signatures don't get currupted due to language pack installation


Reproducible: Always


User Profile Reset: No

Additional Info:
Version: 26.2.0.3 (X86_64)
Build ID: afbbd0df0edb6d40b450b0337ac646b0913a760c
CPU threads: 4; OS: macOS 15.7.3; UI render: Skia/Raster; VCL: osx
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded