We suggest to have address format in LDML specification, to deal with the
cultural diversity of address. The format can be as follows:
Explanation of each tag:
addressSegments contain the address items that compose an address.
addressOrder is the order that an address should be displayed. For example,
"stcyspzpcr" means the sequence: street, city, state, zip code, country.
addressPattern contains the address order and other format information of an
address. For example, in en_US locale, there is a new line for most of the
address items, while in zh_CN locale, most of the address items are put together
consecutively. In the pattern "%st%nn%cy%nn%sp%bk%zp%nn%cr", 'st', 'cy', 'sp',
'zp', 'cr' are the same meaning as in addressOrder, while 'nn' means a new line
and 'bk' means a blank.
states are the states/provinces of the country. Each country has their own state
Blank milestone -> UNSCH per :
component=future -> unknown, all such tickets are already milestone=UNSCH
I’d be more than happy to help on this initiative. Take a look at for a similar effort I’ve been leading at PayPal. This link only shows the transport schema, but we have been working on a number of issues related to context-sensitive layout, basic validations, and transforms between basic standards, and compatibility between HTML5 autocomplete fields and Google’s libaddressinput validation data.