CiviCRM is international and has done a lot to make its user interface available and relevant to people in different countries. There's a wiki page about UK localisation which goes so far. However, there's more to do, and here's how I did it for UK addresses.
CiviCRM allows the user to specify what order address fields should be displayed in. Great! However for some reason it then has a function which enforces a certain layout of these fields, grouping country and state_province (UK: county), and grouping city and postal_code.
This makes data entry counterintuitive, we want to enter city (i.e. postal town), state_province (i.e. county), postal_code, then country but instead we're offered city, postal_code, country then state_province (county).
Step 1: remove the layout-focussed grouping from the BAO class:
Step 2: provide missing templates
The address template splits the address into bits, and we've just gotten rid of a couple of the standard ones in favour of a more atomic aproach, so we need to provide templates for city, state_province, postal_code and country. We can do this in our customised templates folder, at templates/CRM/Contact/Form/Edit/Address/city
These all follow the same format, here's an example for city:
Note that I have done two things differently
- added meaningful class names to containers. I wish CiviCRM would do this as standard (esp with custom fields) as it enables much more flexibility for the .extra.tpl files and CSS changes.
- replaced a table there for layout of two fields side-by-side (ouch) with a div; all fields are now one after the other. This also enabled me to remove the inline CSS removing the padding from the parent <td>.