[perl #134187] Turkic casing not working in freebsd

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

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