There is a project that I think is designed to bring all the localization issues under 1 umbrella but I wanted to discuss a specific issue thats arisen in a side extension Ia am working on to get some input on working through it.  

I am discovering that the Australian Address system is actually more unique than I thought.

The australian standard is:

http://auspost.com.au/media/documents/Appendix-01.pdf

Basically it is 

• Name of Addressee (mandatory)
• Reference Line (optional)
• Street address, Box number, or Locked Bag number (mandatory)

• Locality name or the name of the office of delivery (mandatory), State or Territory abbreviation(Mandatory),  The postcode (mandatory) (all on the last line

Obviously the contact.location archetype was designed around this (the suburb is the locality)

So thats ok but then we look overseas and things get interesting.

taking our closest neighbour

NZ

https://www.nzpost.co.nz/sites/default/files/uploads/shared/standards-guides/adv356-address-and-layout-guide.pdf

Mr H G Guy (Recipient)(mandatory)
195A Halifax Street North (Street)(mandatory)
Tahunanui (Suburb)(optional except sometimes its mandatory)
Nelson 7011 (Town, Postcode)(mandatory)

The suburb is mandatory if the suburb name is in common use
for the address.
You can leave out central city suburbs (eg. ‘Auckland Central’).
Don’t use the name of a complex site, such as a university or
retirement village, for the suburb unless it’s commonly used
as a suburb, such as ‘Trentham Military Camp’.
• Use the correct town or city name – for example ‘Lower Hutt’
for a Lower Hutt address, rather than ‘Wellington’.
For a full list refer to www.nzpost.co.nz
• If the suburb name isn’t commonly used, leave it out.

Clear as mud right - but the important differential is NZ breaks it self into Towns not states for postal reasons.  

So we use the Town as the state name right? but then the archetype doesnt look right? perhaps we should rename the contact archetype field for state to locality?

we use the word state hardwired into the code so it isnt as easy as just a rename at the arcehtype level.  This is set into many of the address functions 

Ok so moving forward looking at USA.

They use

• Reference Line (Optional)
• Name of Addressee or Company (mandatory)
• Address Line - but the Unit is after the street....(mandatory)
• City Name, State, ZIP + 4 (City Name, State and Post Code)(mandatory)

The post code is not directly correlated with City Name, I think at best guess its a many-many relationship with all falling under the same state.

So we could translate or suburb to become the city name and the state becomes the locality.  

relationships between state and zipcode and state and cityname, ZIP code is actually a finer detail setting than the CITY, but I am not sure if there is a possibilty of a zip code having multiple cities (if it lies across a town border)

The Uk gets even more complicated at some point if you dont use these addresses all the time you just type the whole lot into the address field and ignore state, suburb and postcode

There are 1.7million postcodes in the UK. UK doesnt use counties but they use Cities, and then villages in address formats.

I think the point I make is maybe a slight change to the default contact archetype might be wise atleast localizing the database values ie

<node name="postcode" path="/details/code"
      type="java.lang.String" minCardinality="0" readOnly="false">
</node>

You can leave the node name alone the point is node can be renamed based on localization.

<node name="state" path="/details/locality"
      type="java.lang.String" minCardinality="0">
    <assertion name="lookup">
        <property name="type" value="targetLookup"/>
        <property name="relationship"
                  value="lookupRelationship.countryLocality"/>
        <property name="value" value="/details/country"/>
        <errorMessage>An error message</errorMessage>
    </assertion>
</node>

Eg you could rename State to Town for the Uk system.

<node name="suburb" path="/details/area"
      type="java.lang.String" minCardinality="0">
    <assertion name="lookup">
        <property name="type" value="targetLookup"/>
        <property name="relationship"
                  value="lookupRelationship.localityArea"/>
        <property name="value" value="/details/locality"/>
        <errorMessage>An error message</errorMessage>
    </assertion>
</node>