Bug 157713 - User-configuration location for language packs (new environment variable?)
Summary: User-configuration location for language packs (new environment variable?)
Status: NEEDINFO
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-04-24 03:15 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
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