Front page | perl.perl5.porters |
Postings from July 2019
[perl #134187] Turkic casing not working in freebsd
Thread Next
From:
Tony Cook via RT
Date:
July 1, 2019 01:48
Subject:
[perl #134187] Turkic casing not working in freebsd
Message ID:
rt-4.0.24-17610-1561945697-949.134187-15-0@perl.org
On Wed, 26 Jun 2019 22:14:52 -0700, khw wrote:
> 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.
Something like this?
Tony
---
via perlbug: queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=134187
Thread Next
-
[perl #134187] Turkic casing not working in freebsd
by Tony Cook via RT