[perl #134187] Turkic casing not working in freebsd

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

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

• [perl #134187] Turkic casing not working in freebsd by Karl Williamson via RT
• [perl #134187] Turkic casing not working in freebsd by Tony Cook via RT
• [perl #134187] Turkic casing not working in freebsd by Karl Williamson via RT