From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95685 invoked by alias); 21 Jul 2015 09:37:39 -0000 Mailing-List: contact libc-locales-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-locales-owner@sourceware.org Received: (qmail 53461 invoked by uid 89); 21 Jul 2015 09:22:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: smtp.gentoo.org Date: Tue, 21 Jul 2015 09:37:00 -0000 From: Mike Frysinger To: keld@keldix.com Cc: Marko Myllynen , GNU C Library , libc-locales@sourceware.org Subject: Re: [PATCH] Use Unicode code points for country_isbn Message-ID: <20150721092217.GG12267@vapier> Mail-Followup-To: keld@keldix.com, Marko Myllynen , GNU C Library , libc-locales@sourceware.org References: <5571B8C2.8000108@redhat.com> <20150609071130.GA26925@domone> <5576BC13.5020001@redhat.com> <20150721081840.GE12267@vapier> <20150721084006.GB29742@www5.open-std.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dWYAkE0V1FpFQHQ3" Content-Disposition: inline In-Reply-To: <20150721084006.GB29742@www5.open-std.org> X-SW-Source: 2015-q3/txt/msg00027.txt.bz2 --dWYAkE0V1FpFQHQ3 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 1997 On 21 Jul 2015 10:40, keld@keldix.com wrote: > On Tue, Jul 21, 2015 at 04:18:40AM -0400, Mike Frysinger wrote: > > On 09 Jun 2015 13:12, Marko Myllynen wrote: > > > On 2015-06-09 10:11, Ond??ej B=C3=ADlka wrote: > > > > On Fri, Jun 05, 2015 at 05:57:06PM +0300, Marko Myllynen wrote: > > > >> make country_isbn definitions consistent across locales by using > > > >> Unicode code points not numerals everywhere. The code in > > > >> locale/categories.def and locale/programs/ld-address.c already > > > >> handles strings. > > > >> > > > >> Please apply. > > > > > > > > Possible but why, when these are numbers which are easier to read t= han > > > > strings? > > >=20 > > > that's true, and I don't feel too strongly about this, but currently > > > some locales are using numbers and some are using Unicode code points= so > > > there's a bit of inconsistency, also it's not that hard to read these > > > once one sees that e.g. 12 becomes "" i.e. only the last > > > digit matters. > >=20 > > i find many of the U markers pointlessly obscure, especially when they'= re used > > for characters that are in the ASCII standard. if we're standardizing = on UTF8 > > encodings in general, why can't we convert these files as well ? keep = in mind > > that i'm ignorant of the tooling around these files ;). >=20 > The use of Unicode points helps making the locales portable, eg. > when crosscompiling for different architectures, including embedded syste= ms, ebcdic > systems, utf-16 systems and utf8 systems, when you are on a different hos= t platform. i'm referring to the tools we use -- either inside of the source repo (i.e. ones we wrote/maintain), or external ones that operate on our files directly (i.e. gcc). what actual problems do you see here ? vague references like "cross-compiling is magic" aren't really that interesting. keep in mind we already use (and agreed to standardize on) UTF8 in things like *.c and *.h and ChangeLog and READMEs and info pages. -mike --dWYAkE0V1FpFQHQ3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVrg9JAAoJEEFjO5/oN/WBNzAQAJ08v87JMWzMFUmOmwViShnw PCp/CwJJOR4wmzLFn/5p1uxw8fyNmrf8H2SPxVq6bw+L9oiyhMhg61vCvBA3DKUT R3yS0bouWu4YWyJ8/yfE5OrPINbezKdYKUJ1QWtPtGhPHGbApF7dMOQkagV0UyXw LL9dAQkQIoqvOPTRCa1i8y0d+5W5lPUiA0AwjcMz+qLQqZ5h69yR0Eth1FbKu1sy MENWL+YcN2EYrlfYAH9FwblxncFLGURKiQskm2SCaG/uBiG5QOzp/ePUyZNHbnLM vM4h+3QY2KKJkm7wlaEU6hQnw9Blo4nSWjZ7YN7fCWmhdcb2TZ6vCkgETXkbD6ur JABPfK8VT4UD9FZ/LoQBTQY8h7LKeOTMx3TvDOtjXwvj8ENhdwenfyafk2X1DvV9 v07R71exOWQ3gyHSw7d0SAe073UG4IsJX2sYIoS7XnMH0W08+vuspBzsrtaSe5Qt tWhv+StlxYKBhpPV65PTphKbvVqIBYm06BzhLGQ9sF+yBZB0llTkqMtMFnxiGkKS nXYsPbgXIYX2Gy2Jg4bV6uXo2OLYM8hHS4MT0ILnChquCeK+wHIWFvfXutMLVD+5 mfN4Mi1rgnrjQC3l+vGWLH3QFKqSboKF92vL/aMOI8JqLYDkJusY653F8vWVbru4 UtN49jmAZGcSWJLijj3I =JSop -----END PGP SIGNATURE----- --dWYAkE0V1FpFQHQ3--