[whatwg] Proposal:Improve internationalization in the autocomplete attribute

[Albert Bodenhamer]

On Thu, Jun 27, 2013 at 6:04 AM, Lara Rennie <lararennie at google.com> wrote:

> Sorry about the slow response, I was out on holiday.
>
> Re the CEDEX: it is a postal-code like thing, but it can't go in the
> postal-code field, or formatting would be bizarre; as pointed out, it
> should go after the locality field. However, if it was entered in the
> locality field, certain systems may complain about validation, anyone
> interested in aggregating data will start to get a lot of duplicate
> localities etc.
>
> It's also not just France - many ex-French colonies use this too.
>
> The Google Address Widget does actually accept CEDEX as a separate field;
> but you won't see this in most use-cases, because often the widget is used
> to collect a physical address (and then they disallow it), or it's used to
> give an address to a credit-card company (who are US based, and don't
> understand it or want things they don't understand...)
>

Thanks Lara.  So if browsers ask for CEDEX as a separate optional field and
then append it to "locality" when filling would that be acceptable?  I
think that's where the spec is right now.


>
> Re the physical vs. mailing: This is not for postal addresses, but more in
> the case of "I want to go somewhere in real life" -> in this case, we don't
> want the military "states" to be allowed, or PO Box 123 addresses. I would
> assume that the user, when setting up their addresses, would indicate
> whether they do or do not represent a physical location (assuming that a
> user can set up multiple addresses - it sounds like they can, based on the
> shipping vs. billing things)
>

This sounds like something a browser could do if they wanted, but that
doesn't need to be part of the spec.


>
>
> 2013/6/18 Albert Bodenhamer <abodenha at chromium.org>
>
>> Thanks Ian.  Comments below.
>>
>>
>> On Mon, Jun 17, 2013 at 4:27 PM, Ian Hickson <ian at hixie.ch> wrote:
>>
>>>
>>> I was working on bug 22286, and noticed that this e-mail was relevant:
>>>
>>> On Tue, 11 Jun 2013, Albert Bodenhamer wrote:
>>> >
>>> > Address lines:
>>> > Currently: Recommended handling for addresses is currently as a single
>>> > line.  Alternatively, sites can ask for address lines 1-3 but this is
>>> > discouraged.
>>> > Problem: Single line doesn't work well for all regions. Some areas
>>> have 5
>>> > lines for an address and might have more.
>>> > Proposal: If address is requested as a single line newlines should be
>>> > preserved when filling. Stop discouraging the use of address-lines.
>>> Support
>>> > more than 3 lines for address.  Potentially, address-lineX where X can
>>> be
>>> > 1-9.
>>>
>>> Of these options, a multi-line "street-address" seems like the most
>>> reasonable, so I've gone with that.
>>>
>>
>> Cool.
>>
>>
>>>
>>>
>>> > Address 'locality':
>>> > Problem: Some regions have the concept of a "post town".  It's
>>> currently
>>> > unclear how this should be requested.
>>> > Proposal: Add "post town" to the list of expected localities in the
>>> > description to make it more clear how this should be requested.
>>>
>>> Done.
>>>
>>>
>>> Sounds good.
>>
>>
>>> > Address CEDEX codes:
>>> > Problem: They don't fit well into the "postal-code" field and are often
>>> > handled as a separate entity.
>>> > Proposal: Add a field name for CEDEX code.
>>>
>>> Can you elaborate on this? The Wikipedia page for French postal
>>> addresses suggests that the CEDEX code is in fact the postal code, much
>>> like a PO Box number in the US is technically part of the 9-digit ZIP
>>> code, but that "CEDEX" is appended to the address' locality field.
>>>
>>
>> Lara, can you add more context here?  You'd said that CEDEX doesn't
>> really fit into postal code, but I don't understand why.
>>
>>
>>>
>>>
>>> > Address: Physical vs mailing address
>>> > Problem: It might be desirable to be able to specify that a physical
>>> > address (an actual location) is expected rather than a mailing address
>>> (eg
>>> > a PO box).
>>> > Proposal: Open to suggestions.
>>>
>>> What's the use case?
>>>
>>
>> IMO this is a nice-to-have.  Lara may disagree.
>>
>> The intent is that if the site needs a physical address it can specify
>> that in the request.  For example, if a shipper can't do PO box, singing
>> telegrams, etc.  I think this is something the user should be able to
>> decide from context when selecting an address, but having extra constraints
>> would be convenient.
>>
>>
>>>
>>>
>>> > Phone:
>>> > Problem: The detail sections for phone number are very US-centric.  The
>>> > spec discourages the use of the detail sections as a result, but sites
>>> may
>>> > want to get phone number broken into chunks.
>>> > Proposal: Consider adding additional detail sections to reduce the US
>>> bias.
>>>
>>> I'd much rather just drop the detailed sections entirely. People really
>>> shouldn't be using them, in any region.
>>>
>>
>> Sounds good to me.  I haven't seen anyone wanting to break things apart
>> yet.  We can discuss further if someone has an actual use case.
>>
>> Thanks.
>>
>>
>>>
>>> --
>>> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>>> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
>>> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>>>
>>
>>
>>
>> --
>> Albert Bodenhamer | Software Engineer | abodenha at chromium.<abodenha at google.com>
>> org
>>
>
>


-- 
Albert Bodenhamer | Software Engineer | abodenha at chromium.<abodenha at google.com>
org