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.
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
Sorry, my last comment was meant for https://bugs.documentfoundation.org/show_bug.cgi#add_comment. I'll copy it there.