[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Address formatting functionality


On 05/07/2012 06:10 PM, Chris Travers wrote:

Structure is an important problem with addresses generally.  We think of addresses as being structured and they are, but they aren't structured the same way everywhere.  Consider the Nicaraguan addressing system, for example, where you have no street names and instead reference places relative to landmarks and directions (and some directions are location-dependent, like "El Calvario 1c al lago 1/2c Abajo" (i..e start at El Calvario, go one block towards the lake, and 1/2 block down, i.e. West).  Also in Ecuador you have cross streets (1889 Manosca #105 y Occidental, Occidental here is the nearest cross-street) as a part of a well-formed address.

(I wasn't sure about the Nicaraguan address problem until I checked web sites of restaurants in Nicaragua for their addresses.  See the address at the bottom of http://www.restaurantedoncandido.com/).

In general these pose problems as I see it.  The simple way to address this is just to put the whole address in a text field except for the country.  Of course if you do this it becomes hard to do reporting on this by post code or city, or province/state.

This is part of the reason why we adopted the idea of three free-form lines along with city, province, post-code, and country.  As I understand it xNAL allows this sort of structure, and I'd prefer to keep it simple (take a look at some of the examples).

Of course these areas are not ordered the same way in different places so I think the key question is on formatting of the fields we use at this point.


... That's how Drupal's addressfield is handling it. Looks like really only 2 free-form lines, stored as "thoroughfare" and "premise", and then city, state, postal code, country stored in fairly consistent fields.

Addressfield is starting with a default layout, and then for a particular list of countries, changing the sequence and/or hiding postal code, city, state to match local conventions.

I'm sure that's not a complete list of particular country exceptions, but it looks like they're just doing a brute-force rearrangement/hiding of fields based on the local specifics that have been reported... And seems like a great place to start for LSMB...

Hmm. I also see an example module for extending the validation, with a complete city/canton/postal code validation routine for Switzerland...

John Locke