Front page | perl.perl5.porters |
Postings from June 2019
[perl #134187] Turkic casing not working in freebsd
Thread Next
From:
Karl Williamson via RT
Date:
June 27, 2019 05:14
Subject:
[perl #134187] Turkic casing not working in freebsd
Message ID:
rt-4.0.24-17571-1561612492-1411.134187-15-0@perl.org
On Wed, 26 Jun 2019 18:49:08 -0700, tonyc wrote:
> On Tue, 25 Jun 2019 08:06:53 -0700, khw wrote:
> > On Tue, 18 Jun 2019 03:15:54 -0700, tonyc wrote:
> > > On Tue, Jun 18, 2019 at 11:36:49AM +0200, E. Choroba wrote:
> > > > On Mon, 17 Jun 2019, Tony Cook via RT wrote:
> > > > > I think the problem is how you define what is a "turkic locale".
> > > > >
> > > > > Choroba appears to assume that just because you can
> > > > > setlocale(LC_ALL, "tr_TR.UTF-8") you have a Turkic locale, but at
> > > > > least for NetBSD and Alpine Linux, this isn't true, both accept
> > > > > pretty much any locale name and return one of two locales.
> > > > >
> > > > > Perl on the other hand doesn't care about the name, only that the
> > > > > locale behaves like a Turkic locale, and the FreeBSD "tr_TR.UTF-
> > > > > 8"
> > > > > doesn't.
> > > >
> > > > OK, I understand. Now, if there were a script that someone wrote
> > > > that
> > > > depended
> > > > on turkic locale casing, how could they verify that it works?
> > > > Something like
> > > >
> > > > use POSIX 'locale_h';
> > > > use locale;
> > > > my $turkic_locale = 'tr_TR.UTF-8';
> > > > $turkic_locale eq setlocale(LC_ALL, $turkic_locale)
> > > > or die "Turkic locale not supported\n";
> > > >
> > > > Does it work at all? And even if it does, is there a better way?
> > >
> > > I don't think so. IIRC NetBSD will save the name so other parts of
> > > the system can use it, even if libc largely ignores it.
> > >
> > > I think the only way is to check whether it behaves like a Turkic
> > > locale - ie. whether the special i/I casing happens.
> > >
> > > Tony
> >
> > The way it works currently is if perl detects that the locale is
> > intended to be a turkic one, by checking its native handling of i and
> > I, it shifts into turkic locale rules everywhere. This is done
> > without regard to the locale name. I thought for a bit to shift into
> > those locale rules if the locale name also indicated that it was
> > intended to be a turkic locale, even if the underlying locale rules
> > don't correspond. The problem with this is that the native (non-
> > turkic) handling would leak through in places. The only ones I can
> > think of just now are in collation (comparing two strings for
> > ordering) and in things in the POSIX module. So, I'm thinking
> > documentation revision is the best way to handle this
>
> Maybe something like the attached?
>
> Tony
That's a good start but I'd add a follow-on sentence, like
Some platforms will accept a locale name of "tr_TR.UTF-8", but the locale doesn't really behave like a Turkic one would. On such platforms, Perl also doesn't follow Turkic rules.
--
Karl Williamson
---
via perlbug: queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=134187
Thread Next