i18n address editing in chrome://settings/autofillEditAddress.

chrome/browser/resources/options/autofill_edit_address_overlay.html

 <div id="autofill-edit-address-overlay" class="page" hidden>
   <div class="close-button"></div>
   <h1 id="autofill-address-title"></h1>
   <div class="content-area">
-    <div>
-      <div id="autofill-name-labels">
-        <span i18n-content="autofillFirstNameLabel"></span>
-        <span i18n-content="autofillMiddleNameLabel"></span>
-        <span i18n-content="autofillLastNameLabel"></span>
-      </div>
-    </div>
-    <div>
-      <list id="full-name-list"></list>
-    </div>
-
-    <label class="settings-row">
-      <div i18n-content="autofillCompanyNameLabel"></div>
-      <input id="company-name" type="text">
-    </label>
-
-    <label class="settings-row">
-      <div i18n-content="autofillAddrLine1Label"></div>
-      <input id="addr-line-1" type="text">
-    </label>
-
-    <label class="settings-row">
-      <div i18n-content="autofillAddrLine2Label"></div>
-      <input id="addr-line-2" type="text">
-    </label>
-
-    <div class="input-group settings-row">
-      <label>
-        <div i18n-content="autofillCityLabel"></div>
-        <input id="city" type="text">
-      </label>
-
-      <label>
-        <div id="state-label"></div>
-        <input id="state" type="text">
-      </label>
-
-      <label>
-        <div id="postal-code-label"></div>
-        <input id="postal-code" type="text">
-      </label>
+    <div id="autofill-edit-address-fields">
     </div>
 
     <div class="settings-row">
       <label>
         <div i18n-content="autofillCountryLabel"></div>
-        <select id="country"></select>
+        <select class="country" field="country"></select>
       </label>
     </div>
 
     <div class="input-group settings-row">
       <div>
         <div i18n-content="autofillPhoneLabel"></div>
-        <list id="phone-list"
-            i18n-values="placeholder:autofillAddPhonePlaceholder"></list>
+        <list class="phone-list" field="phone"
+              i18n-values="placeholder:autofillAddPhonePlaceholder"></list>
       </div>
 
       <div>
         <div i18n-content="autofillEmailLabel"></div>
-        <list id="email-list"
-            i18n-values="placeholder:autofillAddEmailPlaceholder"></list>
+        <list class="email-list" field="email"
+              i18n-values="placeholder:autofillAddEmailPlaceholder"></list>
       </div>
     </div>
-
   </div>
 
   <div class="action-area button-strip">
     <button id="autofill-edit-address-cancel-button" type="reset"
         i18n-content="cancel"></button>
     <button id="autofill-edit-address-apply-button" type="submit"
         class="default-button" i18n-content="ok" disabled></button>
   </div>
 </div>
+
+<div hidden>
+  <div id="autofill-address-row-template" class="input-group settings-row">
+  </div>
+
+  <div id="autofill-full-name-list-template">
+    <div>
+      <div class="autofill-name-labels">
+        <span i18n-content="autofillFirstNameLabel"></span>

[Evan Stade, 2014/04/25 20:02:18]

I think we should standardize the number of name fields (i.e. just have one full
name field instead of 3 name pieces here, to match the dialog)

[please use gerrit instead, 2014/04/28 15:49:44]

Done.

[Evan Stade, 2014/04/28 23:23:16]

+isherman, any opinion on this change?

[Ilya Sherman, 2014/04/28 23:43:44]

Websites will often request first, middle, and last names separately.  At the
same time, Chrome has very basic heuristics in place to parse a full name into
components.  If we offer just a single full name field, then users have no
ability to correct Chrome's mistakes if they want to.  That's not great -- it
means that Autofill will *never* work correctly for users like "Leonardo da
Vinci", or any other name that our simple heuristics fail on.

For rAc, we have the opportunity to explicitly discourage websites from asking
for tokenized names.  For regular Autofill, we have to deal with the common
legacy case.  So, I think we need to keep some way for users to correct Chrome's
tokenization of their name.  If we want a single field by default, we could do
something complex like what https://contacts.google.com does.

[Evan Stade, 2014/04/28 23:56:37]

Isn't the inverse also true? If we have multiple input fields, then Yao Ming can
add his name in chrome://settings/autofill, which will work for
autocomplete="given-name" and "family-name", but when we try to fill it into a
full name field it will come out as Ming Yao, and he can't fix that.

Also, wouldn't Leonardo da Vinci work with our heuristics? First name is the
first word (Leonardo), last name is everything else (da Vinci). But yea, Billy
Bob Thornton wouldn't work.

Seems like either way, it won't work for someone.
But data typed into a rAc dialog feeds into the legacy cases as well...

[Ilya Sherman, 2014/04/29 00:08:29]

I'm not following this example.  I think you mean that the full name field
always fills as "first name + middle name + last name", whereas for some names
the family name should come first?  If so, I think that's something that we
should fix as best we can as part of the localization work.
"da" would be treated as a middle name, rather than as part of the last name.
True, and users can edit data originally entered into an rAc via the
chrome://settings/autofill UI.

[Evan Stade, 2014/04/29 00:24:41]

yes, that is what I mean.
That seems like a mistake. How often do people actually type middle names?
Probably less often than having 2-word last names at least according to my
totally unfounded guesstimates. If site (a) uses full-name and then site (b)
uses separate names, the default should be to use ALL the name from (a) on (b),
without forcing the user to navigate to chrome://settings/autofill, which
realistically is rarely if ever going to happen.

[Ilya Sherman, 2014/04/29 00:37:29]

Lots of web forms ask for a middle initial, so people type middle names
frequently.

If we think that people never go to chrome://settings/autofill, then how about
we just delete all of this code and call it a day? </strawman>

[Evan Stade, 2014/04/29 18:19:03]

Into full name fields? If the site has a middle initial field, sure, but we're
talking about a single name field.

Since you brought up the contacts.google.com example, yea, that's a pretty fancy
control. But it also has good heuristics. Somehow it gets Alex de la Hidalga
correct (Alex/de la Hidalga) and Billy Bob Thornton does something reasonable as
well (Billy/Bob/Thornton). I think we should make this a full name field, and
improve our heuristics to the contacts.google.com level of smarts.

As a side note, it parses Leonardo da Vinci as Leonardo/da/Vinci, but I can't
say I've ever actually met a da Vinci, so I don't know if this matters.
I don't think that, but I do think we should optimize for the common case of
"user never goes to chrome://settings/autofill".
This is still the bottom line for me.

Specifically, we think that websites /should/ just ask for full name. Thus if we
just ask for full name, autofill works well with good websites and poorly with
the bad sites that ask for tokenized names. On the other hand, we can ask for
tokenized names, and then autofill works well with bad websites, but not as well
with good websites.

[Ilya Sherman, 2014/04/29 18:59:20]

I definitely agree that we should improve our heuristics.
I don't understand this comment.  This CL is strictly limited to changing the
behavior of chrome://settings/autofill.  Optimizing for the common case of users
who never go to chrome://settings/autofill means this code can do literally
anything, because in the common case users won't see it.

I think that for the chrome://settings/autofill code, we should optimize for the
use cases of users who will ever actually look at chrome://settings/autofill. 
For those users, I think more control is better.
It's true that both tokenizing and recombining tokenized names are
heuristic/imperfect operations.  However, I think that combining tokens
correctly is an order of magnitude easier than tokenizing correctly.  Hence, I
think we should let users correct the case that Chrome is far more likely to get
wrong based on heuristics.

Or, if we want to be fancy, we can do what https://contacts.google.com does, and
allow users to explicitly specify both the tokenized and the non-tokenized
format for their name.

[Evan Stade, 2014/04/29 19:14:31]

Yes, this is a tangent. But it also matters to this CL in that if we make this a
full name field, the quality of our heuristics in parsing that input matters.
Lots of metrics are better to have more of. Control, consistency, simplicity,
...
If it's so much easier, why don't we do either one correctly?

[Ilya Sherman, 2014/04/29 19:25:03]

For names in English, we don't tokenize correctly, but we do recombine names
correctly (at least, AFAIK).  We don't support international names as well
because this part of the code was never internationalized.

[Evan Stade, 2014/04/30 05:25:22]

Yao Ming goes by surname-givenname in English. I'm not sure how prevalent this
is.

+        <span i18n-content="autofillMiddleNameLabel"></span>
+        <span i18n-content="autofillLastNameLabel"></span>
+      </div>
+    </div>
+    <div>
+      <list class="full-name-list" field="fullName"></list>

[Evan Stade, 2014/04/25 20:02:18]

why is this a list inside a div, whereas below you just have a list?

[please use gerrit instead, 2014/04/28 15:49:44]

No longer relevant, as we're no longer using first, middle, last template for
names.

+    </div>
+  </div>
+
+  <div id="autofill-addr-lines-template">

[Evan Stade, 2014/04/25 20:02:18]

hmm, this should be a textarea, if we are going to follow our own recommendation
to web devs.

[please use gerrit instead, 2014/04/28 15:49:44]

Done.

+    <div i18n-content="autofillAddrLinesLabel"></div>
+    <list class="addr-lines" field="addrLines"
+          i18n-values="placeholder:autofillAddAddrLinePlaceholder"></list>
+  </div>
+
+  <label id="autofill-field-template">
+    <div></div>
+    <input type="text">
+  </label>
+</div>