Brazilian address

I can commit this as is, but I don't really know what it takes to have a full address in Brazil. : D

Just so we have the same understanding on what feels to include / require - are only fields that are actually required to mail something required right now? I'm not use to seeing you have to enter so much, including "neighborhood."

Patch seems to work fine as is, though, and I can commit any time.

Actually, I'm about to do some work to add the name fields in, and I don't wanna royally hose your dev repository. I'm going to commit as is and do my work, but please review based on my last comment. I'm guessing you'll need a follow-up patch to accommodate name information anyways.

Hi! I live in Brazil,
and it really needs to have some other fields

I already review the patch and according with this document http://xml.coverpages.org/XNAL-DTDs-display.html the fields are right!
So i can't see why this isn't commited, we really need this stuff :D

Cheers!

This patch needs to be rerolled.

Hi,

Here's a new patch taken today.

Please review.

Rerolling using previous if clause instead of creating a new if clause for the brazilian address .

Here's a reroll from the proper folder. Reverted changes to "Sao Paulo", since it is the proper transliteration. It is wrapped in t() and can be translated to add proper diacritics (to all states).

Is "Neighborhood" really needed? I'm from Brazil too and never sought a website asking me for it.

Although "bairro" is a usual information when you think of Brazilian addresses, I seldom see them in web forms. Damn colonialism. Supporting is a good sign, and it serves the purpose of disambiguating duplicated street names.

Sorry, i understood as "referência", but after that i realized it was "Bairro". And obviously, i agree that it should be in every form.

I had a second thought on this case and i think that we could create a specialized module for a brazilian addressfield, because that's why Addressfield module uses CTools plugin system: we can extend it without the need to patch the main module. But i agree that this patch here is a good default and should be commited, without further problems(i'm using it right now).

Any news?

I'd say breaking Brazilian Address stuff to a new module would be interesting, yet it's a matter of a follow up patch.
Let's commit this.

This should happen here #1829900: [meta] Address Field 2.x needs pluggable administrative areas and an actual API

I've been wondering whether 'dependent_locality' (a.k.a. Neighborhood) should go into the street_block or locality_block.

It doesn't look right when in locality_block, but I'm not really sure. It does affect the layout of both form and output.

Any news on commiting this!? It's very important for us Brazilians to have these fields on the form :)

Fixed some stuff on the previous patch and re-rolled it against latest -dev.

@barraponto, the street number must go together with the street address on the xNAL standard (according to rszrama in another issue). Yet, I also don't like storing them on the same field. In addition, premise is not supposed for this kind of value, even on google's schema.

@barraponto, regarding the order of the fields, I followed the Brazilian post office standard guides

Other Brazilians who used the module complained about the labels Address 1 and Address 2. It is fixed, using dependent_locality for "Neighborhood", or bairro in Portuguese. Be aware that google most times return this value as the type sublocality, yet they also have a type called neighborhood.

Other minor fixes:

• Use uppercase for PHP constants, e.g. NULL, TRUE, FALSE
• Use "elseif" in place of "else if"

re-rolled patch file following recidive's comments.

Patch works as expected, good job Weber ;)

I also tested removing the fields Full name and Company, it works fine.

How it looks like with this patch:

Edit:

View:

Thanks a lot, guys! Committed.

YAY !

No, thank you rszrama :D

@mac_weber so that's where we should send you a beer?

Great to have this field there!

Although, i came to another doubt that i think is needed to solve the "brazilian address issue": should "sub_premise" field be available too? In Brazil, is very common to have the "Street" separate from the "Number", and the integration with some payment providers in Drupal Commerce needs to improvise to handle this.

Does anybody agree?

@pedrorocha I think you should open a new issue for that.

As a quick reply: sub_premise is not meant to be used as street_number by any known format.

I don't think addressfield will change it because they are following xNAL format, but their maintainers may answer it better.

Closing as this patch is already merged.
As said on #31, a new issue should be opened.

@pedrorocha see #2059969: Add "ThoroughfareNumber" to the schema.

Just a question: How is this different from the solution given by: https://drupal.org/project/br_address ?