develooper Front page | perl.perl5.porters | Postings from June 2019

[perl #134187] Turkic casing not working in freebsd

Thread Previous
From:
Karl Williamson via RT
Date:
June 25, 2019 15:07
Subject:
[perl #134187] Turkic casing not working in freebsd
Message ID:
rt-4.0.24-18037-1561475213-922.134187-15-0@perl.org
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
-- 
Karl Williamson

---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=134187

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About