Problem/Motivation

Currently the information provided in the addressfield field is not localized to Peruvian addresses.

The current fields shown on the address form for Peru (country == 'PE') are: Address 1 (thoroughfare), Address 2 (premise), City (locality) and Postal Code (postal_code).

In Peru, the usual format is the following:

For Lima:

Jr. Mariategui 123 Interior 301A (thoroughfare premise)
Los Olivos (locality)
Lima 39 (postal code)

Outside of Lima:

Jr. Huascar 123 Interior 501A (thoroughfare premise)
Acobamba, Tarma (locality, sub_administrative_area)
Junín (administrative_area)

On Postal codes in Peru

Peru has official national postal codes since 2011, but it is not really common yet and it does not respect department/province/district original political division, so some districts are now split in different postal codes or join with others.

The previous way only has postal codes for Lima department Lima province districts and Callao department Callao province districts, so it does not work for the general case.

Actually I walked to a postal service office today to ask about the right way to write addresses, and they mention that the new postal codes are not really active yet. I would say that will take at least some more years to be adopted. Notice also that most people (the ones we want to use the form) does not even know that a new postal code exists.

Proposed resolution

It makes sense to use outside of Lima format, which would contain the following information:

  • Address 1, Street name and number (thoroughfare, required)
  • Address 2, internal location (premise, optional)
  • Department (administrative_area, required)
  • Province (sub_administrative_area, required)
  • District (locality, required)

With that information we can map any location in Peru.

Let's use peruvian information from ISO_3166-2 for departments (administrative_area) as the stored.

From what I have seen on other similar issues, the module only wants to know about countries administrative areas. Any other more specific information does not live here, and instead on other modules (i.e. I see addressfield_example defining the details for Switzerland).
So, I guess the best idea would be to create a Peruvian specific module project with that information (FTR, I will use INEI's ubigeo for province and district codes).

Remaining tasks

(reviews needed, tests to be written or run, documentation to be written, etc.)

  • Some maintainer review the patch

Done:

  • hide postal code
  • set administrative division as postal address
  • changes label names as proposed
  • includes information about administrative areas in Peru
  • re-arrange fields to make sense, proposed order as the list in the last section

User interface changes

The user will see a localized version of the addressfield form for Peruvian addresses instead of the generic form.

API changes

None.

#1829900: [meta] Address Field 2.x needs pluggable administrative areas and an actual API, related in the sense that this is n issue about country specific information, but I think we can do enough with current API to support Peruvian addresses using a minor patch(this issue) and a Peruvian specific module.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

marvil07’s picture

Status: Active » Needs work
FileSize
5.28 KB

Done with this patch:

  • hide postal code
  • set administrative division as postal address
  • changes label names as proposed
  • include information about administrative areas in Peru

Pending:

  • re-arrange fields to make sense, proposed order as the list in the last section
marvil07’s picture

Status: Needs work » Needs review
FileSize
5.3 KB

Here a new patch that fixes the last pending item.

pompetardo’s picture

Thanks for the patch, I was doing something similar. But I found a problem when I want to add provinces or cities that are conditional to the department selected, in the address form If I choose a department, the list is not updated. The only dropdown box that seems to trigger the update is the country one.
I added the folowing for testing in the address.inc:

if ($address['administrative_area'] == 'Lima') {
      $format['locality_block']['locality']['#options'] = array(
        ''   => t('--'),
        'Lima' => t('Lima'),
        'Cañete' => t('Cañete'),
      );
}

And when I select Lima from the administrative_area, the dropdown box doesn't appear unless I refresh the page. Of course if I put a default one without the conditional it appears.
I saw a similar question in http://drupal.org/node/1923264#comment-7202792
But it wasn't understood at all.

marvil07’s picture

@pompetardo: I understand, but sadly this is not the topic of the issue, so please let's do not discuss it here. This task is about adding the general support for Peruvian addresses. Please notice that this module only have data for country's main divisions (administrative_area). Please also notice that I mentioned that I will be creating a Peruvian specific module with extra information soon (I'll refer it here when I opened the sandbox).

BTW I also updated the remaining task, since we now need a review.

pompetardo’s picture

OK thanks, I'm interested in the module you say so I can help you if you want. I'm new to Drupal coding so I want to learn because I usually get lost in the code.

rszrama’s picture

Component: Code » Address formats
Category: bug » feature
marvil07’s picture

apropos to the update, I forgot to mention that I opened a new module to complement this patch on addressfield_peru.

marvil07’s picture

Issue summary: View changes

update remaining tasks

  • bojanz committed e6c0047 on 7.x-1.x authored by marvil07
    Issue #1950448 by marvil07: Support Peruvian addresses
    
bojanz’s picture

Status: Needs review » Fixed

Rerolled and committed the patch: http://cgit.drupalcode.org/addressfield/commit/?id=e6c0047

I had to remove this part:

+    $format['locality_block']['sub_administrative_area']['#title'] = t('Province');
+    $format['locality_block']['sub_administrative_area']['#weight'] = 2;

because there's no sub_administrative_area field anymore.
This matches what Google is doing for Chrome/Android, where the sub_administrative_area field is unused too.

In any case, your plugin is still free to add it.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.