This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] localedata: i18napis: update LC_ADDRESS.country_post


On 15 Jun 2016 11:00, keld@keldix.com wrote:
> On Wed, Jun 15, 2016 at 10:12:48AM +0200, Florian Weimer wrote:
> > On 06/11/2016 04:17 PM, Mike Frysinger wrote:
> > >i have no problem dropping postal_fmt & country_post from all locales and
> > >telling people to use libaddressinput.  after all, it's not like glibc has
> > >functions to format postal_fmt in the first place -- it's left up to the
> > >app to do the printf logic itself, and iirc, last time i searched, there
> > >was no one doing that.
> > 
> > GNOME uses it to determine the street/dwelling number ordering for 
> > formatting results from an Openstreetmap-related location service.
> > 
> > I posit that this is incorrect because it should use the locale of the 
> > location, and not the locale of the user.  A German address needs to be 
> > formatted according to German conventions, even if the user is using an 
> > English locale.
> 
> Indeed the address should be formatted according to German rules,
> even for an English user.
> 
> But that then needs to be programmed accordingly. Both for 
> the locale solution and the libaddressinput solution. 
> Better then use the solution we use now, where we have code that somewhat works 
> and coul be modified to work correctly.

that would require the application to do locale juggling which is a
process-wide setting.  and it'd require us to design/extend the API
to support it.  and it'd require programs to adopt new non-standard
extensions (granted, we're a GNU project as is GNOME, but let's think
bigger).

alternatively, we could direct people to an already existing & pretty
complete solution that has a much more active maintainership than us,
both in the API & the data, and is already what the Unicode consortium
(via CLDR) are directing the wider world to (and have for years at this
point).  and it is cross-platform and has multiple language bindings.

what exactly is the advantage to us trying to pick up this work ?
all i see is downsides and wasted effort on APIs that no one will
use.  and i have the history of the glibc project to show that very
few (if any one) actually cares to do all the work in keeping the
data and API fresh.  it's been 17 years since these were added to
glibc and we've pretty much gone nowhere since.
-mike

Attachment: signature.asc
Description: Digital signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]