On Tue, 2023-11-21 at 09:35 +1300, Thomas Munro wrote:
> > I don't have Windows to test, but wouldn't the problem be avoided if
> > people created their cluster with "--locale=tr-TR"? If yes, EDB's
> > Windows installer should be modified to use the correct locale names.
> > Is anybody from EDB reading this?
>
> That would have the same effect as that patch. I believe that is the
> right thing to do, but I am not sure about one detail: the lack of
> encoding on the end of the name. Does the encoding remain the same as
> the traditional one for that language, and stable, or when you haven't
> explicitly named it, might it depend on the registry/control panel
> "ACP", that could in theory change? If it does, what happens? Should
> we put it on the end to pin it down? When we tried that it had some
> effect, but didn't seem to have the expected [by me] effect on ctype
> (eg case conversion of the famous Turkish i); it appears that having
> ACP != LC_TYPE gives some Frankenstein behaviour, but I don't
> understand it, and I think you'd also want to determine in which cases
> strcoll_l() is behaving sensibly with various combinations. This may
> all be pre-existing stuff well understood by people who worked on the
> Windows port? I don't have Windows to test.
I see and share the uncertainty. But isn't tr-TR.1254 the same as
Turkey_Türkiye.1254? In other words, if we just used the short,
standardized locale names and left the encoding suffixes (with their
potential Frankenstein behavior) as they are now, would the situation
be any worse than it is now? We could forgo using the mutable locale
names and leave the encoding mystery for a better day.
Yours,
Laurenz Albe