On Sun, Mar 8, 2020 at 7:17 AM Juan José Santamaría Flecha < juanjo.santama...@gmail.com> wrote:
> > > On Sun, Mar 8, 2020 at 3:48 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > >> James Coleman <jtc...@gmail.com> writes: >> > On Sat, Mar 7, 2020 at 9:31 PM Tom Lane <t...@sss.pgh.pa.us> wrote: >> >> Looks like you may not have Turkish locale installed? Try >> >> locale -a | grep tr_TR >> >> > Hmm, when I grep the locales I see `tr_TR.utf8` in the output. I assume >> the >> > utf8 version is acceptable? Or is there a non-utf8 variant? >> >> Hmm ... I'm far from an expert on the packaging of locale data, but >> the simplest explanation I can think of is that the tr_TR locale exists >> to some extent on your machine but the LC_TIME component of that is >> missing. >> > > AFAICS, the locale 'tr_TR' uses the encoding ISO-8859-9 (LATIN5), is not > the same as 'tr_TR.utf8'. > The test name implies it's about utf8, though, which makes me wonder if the test should be testing utf8 instead? That being said, a bit more googling based on your node about the proper ISO encoding turned up this page: https://unix.stackexchange.com/a/446762 And I confirmed that the locale you mentioned is available: $ grep "tr_TR" /usr/share/i18n/SUPPORTED tr_TR.UTF-8 UTF-8 tr_TR ISO-8859-9 So I tried: echo tr_TR.ISO-8859-9 >> /var/lib/locales/supported.d/local # In a root session sudo dpkg-reconfigure locales That didn't seem to fix it, though `locale -a` still only lists tr_TR.utf8, so I'm still at a loss, and also unclear why a test names utf8 is actually relying on an ISO encoding. James
