[whatwg] Proposal:Improve internationalization in the autocomplete attribute

[Albert Bodenhamer]

On Thu, Jul 4, 2013 at 5:05 AM, Lara Rennie <lararennie at google.com> wrote:

>
>
>
> 2013/7/2 Albert Bodenhamer <abodenha at chromium.org>
>
>> 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.
>>
>
> I don't know if the merchants would expect this? Especially if they did
> want a separate field?
>
Makes sense to me to break it out then.


> What if they are using the (open-sourced) Google Address Widget?
>

Good point.  I know Google forms use it extensively and others can too.  I
don't think it's currently marked with autocomplete attributes, but it
would be great if it were.



>
>
>>
>>
>>>
>>> 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.
>>
>
> I guess I was just meaning; if a site can use the spec to say "please
> autocomplete with a shipping address for this user" then they could also
> use it to say "please autocomplete with a physical location for this user".
> But just an idea. Just because you might have two localities: one which is
> your post-town, and one which is your actual physical location. But
> "shipping" might cover this sufficiently.
>

I don't have a strong opinion either way on this one. It sounds potentially
useful, but I don't know if it's useful enough to justify addition to 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
>>
>
>


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