Created attachment 38594 [details] [review] make Indian UTF-8 aliases uppercased There are a bunch of trivial Indic locale aliases currently in locale.alias.pre like: ar_IN.UTF-8: ar_IN.UTF-8 which I suppose should either be dropped or changed into: AR_IN.UTF-8: ar_IN.UTF-8 The attached patch does the latter (though I have yet to come across a real-life system actually using uppercase locales on Linux at least). So happy to submit another patch to remove them instead if that is the right thing.
Please send this to the mailing list xorg-devel@lists.x.org, else it rot in bugzilla forever.
from my mail to the list: Date: Thu, 14 Apr 2011 12:01:22 +0100 From: Daniel Stone <daniel@fooishbar.org> To: Alistair Leslie-Hughes <leslie_alistair@hotmail.com> Cc: xorg-devel@lists.x.org, petersen@redhat.com Subject: Re: [PATCH libX11] cleanup trivial Indic UTF-8 aliases uppercasing lang. #30112 Message-ID: <20110414110122.GD9710@fooishbar.org> Hi, On Tue, Apr 12, 2011 at 08:18:38PM +1000, Alistair Leslie-Hughes wrote: > From: Jens Petersen <petersen@redhat.com> > Date: Fri, 10 Sep 2010 16:00:52 +1000 > Subject: [PATCH] cleanup trivial Indic UTF-8 aliases uppercasing lang > > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=30112 > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair@hotmail.com> > --- > nls/locale.alias.pre | 38 +++++++++++++++++++------------------- > 1 files changed, 19 insertions(+), 19 deletions(-) > > diff --git a/nls/locale.alias.pre b/nls/locale.alias.pre > index 65b3dd0..d03b18b 100644 > --- a/nls/locale.alias.pre > +++ b/nls/locale.alias.pre > @@ -51,7 +51,7 @@ ar_EG.iso88596: ar_EG.ISO8859-6 > ar_EG.ISO-8859-6: ar_EG.ISO8859-6 > ar_EG.utf8: ar_EG.UTF-8 > ar_IN.utf8: ar_IN.UTF-8 > -ar_IN.UTF-8: ar_IN.UTF-8 > +AR_IN.UTF-8: ar_IN.UTF-8 > ar_IQ: ar_IQ.ISO8859-6 > ar_IQ.iso88596: ar_IQ.ISO8859-6 > ar_IQ.ISO-8859-6: ar_IQ.ISO8859-6 Err, I've never seen an upper-case locale name (as opposed to character set modifier). As you can see from the RHS, 'UTF-8' is a valid character set modifier, as is 'utf8'. So, I don't think there's any problem here. Cheers, Daniel
(In reply to comment #2) > Err, I've never seen an upper-case locale name (as opposed to character > set modifier). As you can see from the RHS, 'UTF-8' is a valid > character set modifier, as is 'utf8'. So, I don't think there's any > problem here. So then should they just be removed as suggested in comment 0 ? Seems pointless to have them alias to themselves.
> --- Comment #3 from Alan Coopersmith <alan.coopersmith@oracle.com> 2011-04-14 12:29:55 PDT --- > (In reply to comment #2) > > Err, I've never seen an upper-case locale name (as opposed to character > > set modifier). As you can see from the RHS, 'UTF-8' is a valid > > character set modifier, as is 'utf8'. So, I don't think there's any > > problem here. > > So then should they just be removed as suggested in comment 0 ? > Seems pointless to have them alias to themselves. > yes, imo.
On Wed, Apr 27, 2011 at 12:32:07AM -0700, bugzilla-daemon@freedesktop.org wrote: > --- Comment #4 from Julien Cristau <jcristau@debian.org> 2011-04-27 00:32:07 PDT --- > > --- Comment #3 from Alan Coopersmith <alan.coopersmith@oracle.com> 2011-04-14 12:29:55 PDT --- > > (In reply to comment #2) > > > Err, I've never seen an upper-case locale name (as opposed to character > > > set modifier). As you can see from the RHS, 'UTF-8' is a valid > > > character set modifier, as is 'utf8'. So, I don't think there's any > > > problem here. > > > > So then should they just be removed as suggested in comment 0 ? > > Seems pointless to have them alias to themselves. > > yes, imo. Sorry, I'd missed commenting in the bug. Yeah, that sounds pretty daft.
commit 566ceaf5a92c721ac7155528e4d0d2e5cbef023f Author: Jeremy Huddleston <jeremyhu@apple.com> Date: Sun Oct 9 02:25:50 2011 -0700 Remove self-resolving aliases https://bugs.freedesktop.org/show_bug.cgi?id=30112 Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.