Bug 157713 - User-configuration location for language packs (new environment variable?)
Summary: User-configuration location for language packs (new environment variable?)
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Localization (show other bugs)
Version:
(earliest affected)
7.6.2.1 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Language-Help-Packs
  Show dependency treegraph
 
Reported: 2023-10-12 03:36 UTC by maxim.cournoyer
Modified: 2024-05-25 03:28 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 maxim.cournoyer 2023-10-12 03:36:30 UTC
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!
Comment 1 Stephan Bergmann 2023-10-12 15:27:01 UTC
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.
Comment 2 maxim.cournoyer 2023-10-13 15:04:00 UTC
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
Comment 3 Stephan Bergmann 2023-10-13 15:23:45 UTC
(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.)
Comment 4 Stéphane Guillou (stragu) 2023-10-26 13:43:36 UTC
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
Comment 5 QA Administrators 2024-04-24 03:15:21 UTC Comment hidden (obsolete)
Comment 6 QA Administrators 2024-05-25 03:28:21 UTC
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