search

void-linux / void-packages

The Void source packages collection
https://voidlinux.org
Other
2.59k stars 2.15k forks source link

Localization files in /usr/lib/locale #27491

Closed ericonr closed 2 years ago

ericonr commented 3 years ago

The correct localedir is /usr/share/locale, which is respected on all glibc packages. Unfortunately, on musl some packages perform their own detection of what localedir to use, due to some really weird mechanisms, and end up putting those files into /usr/lib/locale. Since locale data isn't arch specific, it should be stored in /usr/share. For multilib systems, this also makes it so locale data only has to be installed once, in /usr/share, by the native package.

@q66 scraped his repo for packages with files in /usr/lib/locale, which should be fixed, unless there are specific circumstances (pcsx2 is one such example, since it can't be installed at all on 64-bit systems).

newbluemoon commented 3 years ago

I did have a look at geeqie and assume most of the listed packages above share the same issue. It seems the problems lies in /usr/share/aclocal/glib-gettext.m4, line 275:

      AC_TRY_LINK(, [extern int _nl_msg_cat_cntr;
             return _nl_msg_cat_cntr],
        [CATOBJEXT=.gmo 
             DATADIRNAME=share],
        [case $host in
        *-*-solaris*)
        dnl On Solaris, if bind_textdomain_codeset is in libc,
        dnl GNU format message catalog is always supported,
            dnl since both are added to the libc all together.
        dnl Hence, we'd like to go with DATADIRNAME=share and
        dnl and CATOBJEXT=.gmo in this case.
            AC_CHECK_FUNC(bind_textdomain_codeset,
          [CATOBJEXT=.gmo 
               DATADIRNAME=share],
          [CATOBJEXT=.mo
               DATADIRNAME=lib])
        ;;
        *-*-openbsd*)
        CATOBJEXT=.mo
            DATADIRNAME=share
        ;;
        *)
        CATOBJEXT=.mo
            DATADIRNAME=lib
        ;;
        esac])

Musl doesn’t have _nl_msg_cat_cntr, the test fails, and so CATOBJEXT is set to .mo.

Then in line 451:

if test "x$CATOBJEXT" = "x.mo" ; then
  localedir=`eval echo "${libdir}/locale"`
else
  localedir=`eval echo "${datadir}/locale"`
fi

So the translations are put into libdir. Even adding --localedir=/usr/share/locale to configure_args didn’t change this.

The easiest way to solve this might be to patch glib-gettext.m4 and just change ${libdir}/locale to ${datadir}/locale in line 452. However, no idea if there might me side effects. ;)

newbluemoon commented 3 years ago

Patching glib-gettext.m4 (alone) might not be that good an idea because it would require the package to regenerate the configure script which needs all the automake stuff added to hostmakedepends etc. It works for geeqie because it has to run an autogen.sh in pre_configure() and does it anyway.

Would a configure hook scanning for localdir in configure scripts be any good?

sgn commented 3 years ago

Maybe link to libintl unconditionally on musl? (I don't like this idea, though)

ericonr commented 3 years ago

I'm very much against forcing libintl when it isn't necessary...

@newbluemoon I believe --with-localedir was reported to work...

newbluemoon commented 3 years ago

At least for geeqie --with-localedir doesn’t work either. If it would it could just be added to common/environment/configure/gnu-configure-args.sh...

ericonr commented 3 years ago

--with-locale-dir, actually. Sorry for the confusion.

newbluemoon commented 3 years ago

No, doesn’t work with geeqie; AM_GLIB_DEFINE_LOCALEDIR doesn’t check if $localedir is already set – it just overwrites it regardless. But that might not be the case with the other packages; they might have added some more checks. I’ll do some testing.

q66 commented 3 years ago

--with-locale-dir is specific to xfce stuff

sgn commented 3 years ago

--with-locale-dir doesn't work for Thunar 4.16.1.

It's --with-locales-dir with an s after locale

newbluemoon commented 3 years ago

I tried geeqie, dia, and leafpad. There $localedir is always hardcoded in the end. I have some fixes on a per package basis ready for those, but maybe a general approach is desired (maybe thats only feasible for the Xfce stuff)?

q66 commented 3 years ago

the m4 files causing this should be fixed either way since they may be used for user built stuff and we don't want that in there either

and then for packages we need to fix it on per-package basis (I see no other way) and introduce a pkglint check to add /usr/lib/locale into forbidden directories (except for glibc-locales)

sgn commented 3 years ago

For xfce4 stuff, it's defined by XDT_I18N from xfce4-dev-tools, it can be fixed by --with-locales-dir=/usr/share/locale. For other stuffs, I don't think we can fix in general, except patching /usr/share/aclocal/glib-gettext.m4 from glib-devel and run autoreconf -fi for all problematic packages.

q66 commented 3 years ago

so we should fix xfce4-dev-tools as well as glib-devel, then for xfce4 packages apply --with-locales-dir, for the others we can probably patch the right pattern in their configure scripts, don't have to necessarily re-generate everything

sgn commented 3 years ago

Doing this and now I realized that we should just

vsed -i '/localedir =/s,=.*,= /usr/share/locale,' po/Makefile.in.in
ericonr commented 3 years ago

@sgn that only fixes install location, not where the programs will search for locale data.

If anything, my fix from #27511 might work better.

sgn commented 3 years ago

We need to run autoreconf -fi for:

-DPACKAGE_LOCALE_DIR=\"$(localedir)\"           \

Actually, we need both. Run autoreconf -fi to have the macro defined correctly, and sed to correct installation directory. I'll eject non-XFCE change for now.

sgn commented 3 years ago

I ended up patching more into glib https://github.com/void-linux/void-packages/pull/27558/commits/b5a894c02b2d3c5db86d8e5b4d804545bdd7c83c

q66 commented 3 years ago

we just need to patch configure scripts... (instead of full autoreconf)

Programmierschmied commented 3 years ago

Gimp patch by ericonr worked for me in #29970

sgn commented 3 years ago

I think everything has been done?

ericonr commented 3 years ago

It seems gtk+ has no locale files at all? Why was it in that list? (or did we accidentally remove its locales?)

I guess the plan is to make usr/locale an error now?

ericonr commented 3 years ago

Or not, pcsx2 requires those files (we could add an override tho)

github-actions[bot] commented 2 years ago

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.