Project

General

Profile

Actions

Bug #13423

open

gettext does not find the message catalogs of programs installed by the user

Added by Bruno Haible over 2 years ago. Updated over 2 years ago.

Status:
New
Priority:
High
Assignee:
Category:
Internationalisation
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:

Description

The gettext() function in libc does not find the message catalogs of programs that a user has installed with a --prefix option. It only finds the message catalogs of programs that are installed by the OS (under /usr).

How to reproduce:
1. Unpack the attached hello.tar.gz.
2. tar xfz hello.tar.gz
3. cd hello
4. gcc -Wall hello.c -o hello
5. ./hello
Expected output: Bonjours les gamins!
Actual output: Hello guys!

A truss ./hello 2>&1 | fgrep hello.mo command reveals that gettext() from libc is looking for
<LOCALEDIR>/fr_FR.UTF-8/LC_MESSAGES/<domain>.mo

But packages that install GNU .mo files do so
1) in directories that are not specific to the locale encoding
(because .mo files are converted to the actual locale encoding
in memory, see usr/src/lib/libc/port/i18n/gettext_gnu.c function do_conv),
2) in directories that are not specific to the territory, if
that makes sense. For example, French is the same in France and
in most of Africa, therefore there is only one French message
catalog, and it is stored in <LOCALEDIR>/fr/LC_MESSAGES/<domain>.mo .

So, gettext() needs to try fallbacks
1) by removing the locale encoding suffix,
2) by removing the territory.

Solaris 11.0 to 11.3 gets this half right: it looks in
<LOCALEDIR>/fr_FR.UTF-8/LC_MESSAGES/<domain>.mo
<LOCALEDIR>/fr.UTF-8/LC_MESSAGES/<domain>.mo

Solaris 11.4 gets it right: it looks in
<LOCALEDIR>/fr_FR.UTF-8/LC_MESSAGES/<domain>.mo
<LOCALEDIR>/fr.UTF-8/LC_MESSAGES/<domain>.mo
<LOCALEDIR>/fr_FR/LC_MESSAGES/<domain>.mo
<LOCALEDIR>/fr/LC_MESSAGES/<domain>.mo

The same change should be done in OpenIndiana.

Otherwise, the only workarounds are:
- The user who installs a program with --prefix=PREFIX has to create symlinks in PREFIX/share/locale/ (lots of symlinks!).
- Or install GNU gettext, and let the programs use gettext() from GNU libintl instead of from libc.

Setting NLSPATH is not a valid workaround, because POSIX says in https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html :
"Setting NLSPATH to override the default system path produces undefined results in the standard utilities and in applications with appropriate privileges."


Files

hello.tar.gz (505 Bytes) hello.tar.gz Test case Bruno Haible, 2021-01-01 01:29 PM
Actions #1

Updated by Bruno Haible over 2 years ago

The same bug exists in OmniOS release 2020-11-02.

Actions

Also available in: Atom PDF