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] |
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
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] |