[PATCH] localedata: i18napis: update LC_ADDRESS.country_post

[Mike Frysinger]

On 11 Jun 2016 16:41, keld@keldix.com wrote:
> On Sat, Jun 11, 2016 at 10:17:40AM -0400, Mike Frysinger wrote:
> > On 11 Jun 2016 11:00, Florian Weimer wrote:
> > > On 06/11/2016 09:27 AM, Mike Frysinger wrote:
> > > > On 11 Jun 2016 08:45, Florian Weimer wrote:
> > > >> In any case, I think it is safe to say that LC_ADDRESS.country_post is
> > > >> now obsolete.
> > > >
> > > > if we want the full country name in caps, libaddressinput provides that
> > > > too.
> > > 
> > > We need the country name in upper case in English or French.  The name 
> > > in the local language is usually insufficient (while DEUTSCHLAND will 
> > > likely be routed correctly, DÜÜTSCHLAND may work by accident, N??MSKA 
> > > only when mailing from the East, and we have German (in the country 
> > > sense) locales for all these).
> > 
> > libaddressinput provides both.  i would lean torwards using the english
> > one all the time in the assumption it has a higher chance of being routed
> > correctly more often.
> > 
> > > > however, if we want to go the route of rethinking country_post,
> > > > then we might also consider rethinking postal_fmt too.  the requirements
> > > > of the current postal systems might be too much for the current spec.
> > > > https://github.com/googlei18n/libaddressinput/wiki/AddressValidationMetadata
> > > 
> > > I doubt how glibc can provide anything useful for application use.  The 
> > > formats are extremely varied, and you need this information when posting 
> > > things internationally, so for all locales, not just the current's user 
> > > choice.
> > 
> > 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.
> 
> I don't think we should droppostal informaton, as this should be associated with the locale.

this isn't a compelling reason.  if the data isn't flexible enough to
match reality, and no one is using it, then it doesn't make sense for
us to waste time on it.

> The libaddressinput model is a wrong concepti, as it is not associated with the locale..

not really.  if you read the wiki i noted earlier, it handles reality
and provides an example:
	https://i18napis.appspot.com/address/data/CA
	https://i18napis.appspot.com/address/data/CA--fr
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20160611/e2079531/attachment.sig>