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 macOS (All)
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: target:7.0.0
Keywords:
Depends on:
Blocks: macOS-UI-polish 43894 132025
  Show dependency treegraph
 
Reported: 2019-12-04 13:10 UTC by Emir Sarı
Modified: 2023-10-26 13:43 UTC (History)
4 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 How can I remove my account? 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 How can I remove my account? 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 How can I remove my account? 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 How can I remove my account? 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 How can I remove my account? 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.
Comment 10 maxim.cournoyer 2023-10-13 15:02:12 UTC
Hi,

> --- Comment #1 from Stephan Bergmann <sbergman@redhat.com> ---
> First off, an upstream LibreOffice installation is always self-contained in a
> single location and fully relocatable.  The soffice executable finds all the
> installation's files relative to itself.  Some Linux distros might lay this out
> differently, with their downstream LibreOffice installations distributed in
> some way into the distro's file system hierarchy, but that is strictly a
> downstream issue beyond the scope of upstream LibreOffice here.

This is useful information, thank you!

> If I understand you correctly, what you seek is that a LibreOffice installation
> at e.g. ~/.guix-profile/lib/libreoffice/ would not only look for certain
> locale-specific files under
> ~/.guix-profile/lib/libreoffice/{program/resource/,share/}, but also under say
> ~/.guix-profile/lib/libreoffice-langpack-fr/{program/resource/,share/}.  (And
> if that understanding is not correct, please be more specific in the
> description of your actual issue.)

I'm only getting started looking at packaging the language packs of
LibreOffice for GNU Guix, so I'm not sure what are the requirements
yet -- I was only looking at how things are done in Debian and
commenting about their layout.

Given that soffice is capable to find things relatively to its own
location, unless it de-references symbolic links (heavily used by Guix
profiles), it should be able to find language pack data if I put such
data at the expected location.

Which brings me to the question: what is the expected location for
language pack data; what is the recommended layout?  Is there a place I
can read more about it (actual documentation or sources) ?

And do these language packs contain both the translation of the
LibreOffice applications themselves (e.g. the menus and button texts) as
well as the offline help?

Thank you for your time,

Maxim
Comment 11 maxim.cournoyer 2023-10-13 15:03:11 UTC
Sorry, my last comment was meant for https://bugs.documentfoundation.org/show_bug.cgi#add_comment.  I'll copy it there.