After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 202133 - Address entry via free-form text only works for US addresses
Address entry via free-form text only works for US addresses
Status: RESOLVED DUPLICATE of bug 250483
Product: evolution
Classification: Applications
Component: Contacts
pre-1.5 (obsolete)
Other other
: Normal trivial
: Future
Assigned To: Mike Kestner
Evolution QA team
: 200471 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2001-04-07 21:56 UTC by Richard Zach
Modified: 2004-04-15 16:17 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Richard Zach 2001-04-07 21:56:56 UTC
The conversion of free-form addresses in the address text box to address
fields (city, state, zip, etc) only works for US addresses.

To reproduce:
- New contact
- In the address box, type

1 High Street
London WC1
England

- click "Address" button

Actual result: <address> = "1 High Street", <address2> = "
London WC1 United Kingdom"
Expected result: <addess> = "1 High Street", <city> = "London", <ZIP code>
= "WC1", <country> = "England">

(similar things happen with US addresses if you don't separate city and
state with a comma).

Here's a possible algorithm:

- set <address> to the text in the first line
- from bottom, find first line that contains any numbers (this contains a
zip code)
- the zip code is either the maximum trailing or the maximum leading string
which contains any numbers (it's either "city state zip" or "city zip" or
"state zip" or "zip city", possibly with commas somewhere). I believe even
in UK/Canadian post codes each part contains at least one number, e.g, "WC1
1TN").  Note that you could have something like "D 57654 Berlin" (in which
case "D 57654" is the ZIP, and something like "75004 Paris cedex 05" or
"CZ-5432 Prague 8" (so numbers on both ends mean the initial part is the
ZIP). So I suppose do this:

From right, search for first all-alpha word. The part behind it is X. Then
match all alpha-only words, that part is Y. The part remaining on the left
is Z. If Z is empty, zip = X, continue processing Y; otherwise zip = Z,
continue processing YX.

- Y is either "city, state" or "city" or "state". So if there's a comma
with strings not containing numbers on either side we know it's city and
state. Otherwise: if there are two lines below, they are <state> and
<country>. If there's only one line below, it could be either the
state/province or the country.

This obviously won't work for all cases, but would probably be better than
what it does now.  In particular, it will screw up in Canada, where you
could have either one of the following:

Montreal HF3 HT3
Quebec

Montreal
Quebec HF3 HT3 

Montreal
Quebec
Canada HF3 HT3
Comment 1 Richard Zach 2001-04-08 23:07:48 UTC
Found a good reference webpage:

http://www.columbia.edu/kermit/postal.html

It shows that the issue is pretty complicated.
Comment 2 Chris Lahey 2001-05-11 21:20:13 UTC
*** bug 200471 has been marked as a duplicate of this bug. ***
Comment 3 Luis Villa 2001-06-26 18:19:40 UTC
I apologize for the spam; re-setting all target milestones to 'future'
in preparation for evolution 1.0. If you have any questions, please feel
free to write louie@ximian.com.
Comment 4 André Klapper 2004-04-15 16:17:37 UTC
i mark this as a part of meta bug 250483...

*** This bug has been marked as a duplicate of 250483 ***