Oddities in the Importing of Mailing Lists
The largest section of my codebase is devoted to the parsing of mailing lists. It would be a rather small portion of the overall code if people were consistent, but people are anything but consistent when it comes to how they organize their mailing lists.
For example, the first time that most people get an international address on their list, their system breaks down, because they don’t have a “country” column. The strange thing is that it doesn’t occur to most people to just add a country column, and put the name of the country in that column.
What most people do is move the city, state/province, and postal code to the “street 2” line (if they have one), and put the country in the city or zip column. If they don’t have a “street 2”, then the city, state/province, and postal code end up in the city column (best case), and country ends up in the zip column.
Then you come across the educated folks who know that in a variety of countries (e.g. Germany), the numeric postal code comes before the city, rather than after. In that case, as a favor to whoever’s doing their mailings, they put the postal code in the city column, the city in the state column, and the country in the zip code column. That way, you can still merge “City State Zip” in that order, and it shows up more or less properly.
Except that my code knows about various countries’ address formats, and already does that swap, with the result that, in this case, the country would end up in the middle of the address.
Sorting all of that out and getting things back in the right fields involves no small bit of code, especially when all of this is being done automatically, and I’ve become a whole lot more familiar with the postal quirks of dozens of countries over the past few years as a result. :-)
Oh, and don’t get me started on the people who know that in Chinese, you write the address from most-general to most-specific, instead of the other way around. (You don’t do that for Chinese addresses that are written in English, but most people, if they know the former, don’t know the latter.) When the name of the person who’s receiving the letter shows up in the zip code column, all hope is lost.
Still, most of the time, the software is able to import mailing lists without a hitch, nowadays. I’m quite proud of it, all told.
And yet, there’s still the occasional list that causes the program to die a horrible death. Such as the one that came in yesterday, which has a first name, spouse, and last name field (which I’m ready for — take first, add “and” and spouse, and append last).
In this list, when the person listed churches, he put the entire name of the pastor in the first name field, which also isn’t that big a deal, and the software can cope with it — split out the words in the first name field and apply them to title, last, and suffix based on patterns established by many tens of thousands of other addresses. Apply the “and spouse” rule after that.
Unfortunately, he then put the entire name of the associate pastor in the spouse field, which just doesn’t work, even beyond the mental imagery associated with that choice of columns. And never mind that some of the names are going to run off the edge of the envelope (e.g. when several members of the missions committee are listed as the last name).
Alas, some things still need to be done by hand.
