Bug 129177 - macOS: Change the language pack installation to not modify the .app bundle
Summary: macOS: Change the language pack installation to not modify the .app bundle
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All Mac OS X (All)
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: target:7.0.0
Keywords:
Depends on:
Blocks: MacOS-Wishlist 132025
  Show dependency treegraph
 
Reported: 2019-12-04 13:10 UTC by Emir Sarı
Modified: 2020-06-07 13:01 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Emir Sarı 2019-12-04 13:10:37 UTC
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:
Comment 1 eisa01 2020-05-03 08:44:09 UTC
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
Comment 2 Tor Lillqvist 2020-05-06 16:09:38 UTC
Working on a change now to make it possible to install language packs in the user "profile".
Comment 3 Tor Lillqvist 2020-05-08 16:31:04 UTC
The first patch on the long road to implement this is (stalled) at https://gerrit.libreoffice.org/c/core/+/93618
Comment 4 Tor Lillqvist 2020-05-08 16:32:09 UTC
(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).)
Comment 5 Tor Lillqvist 2020-05-11 14:24:42 UTC
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).
Comment 6 Commit Notification 2020-05-18 16:52:45 UTC
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.
Comment 7 Emir Sarı 2020-05-18 19:02:33 UTC
Thank you Tor for your work on this! This will hopefully get rid of a big burden, and ease LO maintenance.
Comment 8 Commit Notification 2020-05-18 20:53:41 UTC
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.
Comment 9 Tor Lillqvist 2020-05-19 13:22:07 UTC
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.