Package: libc6
Version: 2.28-10
Severity: normal

As discussed in https://bugs.debian.org/931139 and
https://bugs.debian.org/924657 glibc has a cache of already
loaded gettext translations that gets invalidated (by incrementing
_nl_msg_cat_cntr) in setlocale(3), bindtextdomain(3) and textdomain(3)
but not uselocale(3). This seems like an oversight.  No matter how the
locale gets changed, the cache should be invalidated.

The attached test case demonstrates this.  When called without arguments,
it uses uselocale(3) so the first translation gets used for all the
languages. This is the "buggy" behaviour.

When called with any arguments, it uses setlocale(3) and works as
intended, outputting the string in three different languages.

The issue is only visible when using the LANGUAGE environment variable
to select the translation. Using LC_MESSAGES, LANG or LC_ALL hides
the issue. This is because LC_*/LANG affect the locale value that is
used to compute the cache hashing key inside glibc (in DCIGETTEXT()),
while LANGUAGE doesn't.

Any insight would be welcome. I can take this upstream but would of
course be happy for the maintainers to do that :)

Thanks for your work on Debian,

on Fri, 5 Jul 2019 14:23:09 +0300 Niko Tyni <ntyni@debian.org> wrote:

  [..........]

For the R project (https://www.R-project.org/) we've stumbled over
this issue as well in our bugzilla
https://bugs.r-project.org/show_bug.cgi?id=18055 and work around it by
calling setlocale(3) just for the sake of cache flushing.

So yes, we'd also be happy if this was eventually fixed in the
gettext-library implementations.