Description: Currently LO uses a custom script to install new localisations. This is less than ideal and causes issues with macOS system Gatekeeper and newly introduced security measures in macOS. Although currently these bugs are fixed, there's no guarantee that new bugs won't spawn in the future. One possible solution would be making the language packs as .oxt extensions. These files do not compromise the integrity of LO as an application, and can easily be managed through the Extension Manager. Steps to Reproduce: Try to install a new language via the currently provided language packs. Actual Results: ... Expected Results: ... Reproducible: Always User Profile Reset: No Additional Info:
I guess this is a very valid improvement, as this is just a suggestion I'm going to make it generic. There are some other possible work-arounds too (e.g., actually shipping all the localisations) It would likely be a blocker for bug 132025
Working on a change now to make it possible to install language packs in the user "profile".
The first patch on the long road to implement this is (stalled) at https://gerrit.libreoffice.org/c/core/+/93618
(And no, my approach does not use extensions (.oxt) at all. Language packs need to be specific to LibreOffice versions (at least major and minor version number, possibly also micro).)
Using the extension mechanism for this would be fairly complicated as the dictionary that is included in a langpack itself is technically an extension... (for instance in the French langpack for macOS there is the directory Contents/Resources/extensions/dict-fr).
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/74597acc9318177a0266535b5387dba35305171a tdf#129177: Allow extensions to specify also maximum LibreOffice version It will be available in 7.0.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.
Thank you Tor for your work on this! This will hopefully get rid of a big burden, and ease LO maintenance.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2d2f00bd499d69a91eda99f31910c3998b560e86 tdf#129177: Turn on --enable-readonly-installset unconditionally for macOS It will be available in 7.0.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.
Fixing this in code seems to be a very large and complicated task. I strongly suggest that TDF simply stops distributing separate language packs for macOS, as they by definition are a broken concept, as they modify the destination app bundle. Instead TDF should start distributing a build that bundles all dictionaries and the translations (and autotexts, etc) for only the languages that have a "good enough" coverage of the UI translation. Note that bundling the help texts seems to be pointless as the code always uses the web-based help anyway on macOS (if the default browser is Safari, which it surely is for a large majority of macOS users). In addition, single-language dmgs could also be distributed, as now, for those that need just one language and are tight on disk space. But I am not even a member of the TDF. Just saying my opinion.