James Coleman <jtc331@gmail.com> writes: > On Sat, Mar 7, 2020 at 9:31 PM Tom Lane <tgl@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.
Do you get different results from "date" depending on the locale? I get
$ LANG=C date Sat Mar 7 21:44:24 EST 2020 $ LANG=tr_TR.utf8 date Cts Mar 7 21:44:26 EST 2020
$ LANG=C date Sun Mar 8 09:27:50 EDT 2020 $ LANG=tr_TR.utf8 date Paz Mar 8 09:27:54 EDT 2020 $ LANG=tr_TR date Sun Mar 8 09:27:57 EDT 2020
I'm curious if you get something different for that last one (no utf8 qualifier).
on my Fedora 30 box.
Another possibility perhaps is that you have partial locale settings in your environment that are bollixing the test. Try
$ env | grep ^LANG
This gives me:
LANG=en_US.UTF-8 LANGUAGE=en_US
$ env | grep ^LC_
Nothing for this.
If there's more than one relevant environment setting, and they don't all agree, I'm not sure what would happen with our regression tests.
There's LANG and LANGUAGE but they look like they effectively agree to me?
BTW, what platform are you using anyway?
ElementaryOS 5.1 Hera, which is built on top of Ubuntu 18.04.3 LTS (and Linux 4.15.0-72-generic).
This suggests I have the standard Ubuntu Turkish language packages installed:
$ dpkg -l | grep language-pack-tr ii language-pack-tr 1:18.04+20180712 all translation updates for language Turkish ii language-pack-tr-base 1:18.04+20180712 all translations for language Turkish
