Hi, I'm using GNU Guix as my package manager/distribution and would like to package the language packs. It seems like on traditional distributions such as Debian, the data files goes to a global place such as: /usr/lib/libreoffice/program/resource/fr, with additional files put under /usr/lib/libreoffice/share. Guix is a functional package manager, and for this reason it does not follow the file hierachy standard (FHS) and its conventional locations such as /usr/lib. Instead, each package gets installed to its own prefix, e.g. my libreoffice lives at /gnu/store/4z2gglhrzr5w6myw6la86s7lw50zlwml-libreoffice-7.5.4.2, and a user profile is assembled under ~/.guix-profile, e.g. I have: $ ll ~/.guix-profile/lib/libreoffice/ total 2296 -r--r--r-- 7 root root 1842305 31 déc. 1969 CREDITS.fodt dr-xr-xr-x 1 root root 92 31 déc. 1969 help/ -r--r--r-- 7 root root 233913 31 déc. 1969 LICENSE -r--r--r-- 7 root root 263307 31 déc. 1969 LICENSE.html -r--r--r-- 1 root root 3706 31 déc. 1969 NOTICE dr-xr-xr-x 1 root root 68 31 déc. 1969 presets/ dr-xr-xr-x 1 root root 7894 31 déc. 1969 program/ dr-xr-xr-x 1 root root 24 31 déc. 1969 readmes/ dr-xr-xr-x 1 root root 442 31 déc. 1969 share/ Is there currently a mechanism in LibreOffice to be able to locate them in such an environment? Typically, what is used in Guix for that are environment variables. The use on an environment variable such as LO_LOCPATH would provide the most flexible means of specifying the language packs data location and could be made to work across multiple profiles. Alternatively, if LibreOffice locates the language pack data files relatively to itself, this could work in a given profile where libreoffice is installed along its language packs. For example, LibreOffice could detect it is at /home/maxim/.guix-profile/bin/libreoffice; and try to access its language packs relatively via "../share/libreoffice/language-packs (or some other other default path). I can volunteer to add support for the new LO_LOCPATH environment variable, if that seems reasonable. Thanks!
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. 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.) Something like that is not currently supported. There would apparently be some design space how LibreOffice could be taught to look into further places (environment variables, well-known paths, whatever...). A related issue is issue 129177.
Hi, > --- Comment #1 from Stephan Bergmann <sbergman at redhat dot 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
(In reply to maxim.cournoyer from comment #2) > 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? The easiest way to get an idea here is probably to look at how the deliverables for a version of upstream LibreOffice like <https://downloadarchive.documentfoundation.org/libreoffice/old/7.6.2.1/> are split up for the various platforms. For deb and rpm, you see that both helppacks and langpacks are individually split out for all the languages, and you can look into their content to see what exactly gets split out and where it ends up in the (monolithic) installation. (mac and win are each a bit different: I think for mac we bundle the help content in the langpacks, and I think for win we bundle all the language's non-help content directly in the main msi.)
As I understand this ticket, it is a enhancement request to add an environment variable[1] that would point to the language pack location, is that right? Cloph, any thoughts on the topic? [1] https://wiki.documentfoundation.org/Development/Environment_variables
Dear maxim.cournoyer, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear maxim.cournoyer, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp