Re: making address formatting more flexible
Hi there! Please do not Cc: me, I read the list. On Tue, 08 Feb 2011 22:13:39 +0100, Johnny wrote: Luca Capello l...@pca.it writes: I do not think there is even a *used* standard within a single country, at least here in Switzerland I saw different layouts sometime according to where the sender lives (French/German/Italian part). And none of the examples at the UPU website uses this ISO-3166 supposed standard: http://www.upu.int/en/activities/addressing/postal-addressing-systems-in-member-countries.html This is an international problem of cooperation. If there is an International Standard, supported by an Organisation (yes, ISO was intentionally capitalised), it should be adhered to, unless there is compelling evidence to the contrary (of outstanding benefit). Fully agree. I think, in this case, it is merely a topic of custom and practice I think, and if any practice is to be adopted for an application with international usage, an internationally accepted standard should be adhered to, if at least to support and strengthen the collaborative effort, which I believe FOSS and Gnu is all about. If bbdb is going to use any country abbreviations, they should be according to ISO is my opinion. However, as far as I am aware, postcodes do not appear in ISO and should be locally (user) specified. Please note that we were not discussing about country abbreviations, but about the label for the postal code. Now that I thought a bit more about it, given that we use postcards we should use postcode and not postal code as I previously suggested. Going back to country abbreviations, FWIW BBDB-2 already adheres to the EU standard (which as I reported is not even respected by the UPU): |-+-| | file| elisp code | |-+-| | bbdb.el | `bbdb-format-address-continental' | | bbdb-com.el | `bbdb-legal-zip-codes' | | bbdb-migrate.el | ` bbdb-unmigrate-zip-codes-to-strings' | | bbdb-print.el | `bbdb-print-format-address-continental' | |-+-| Thx, bye, Gismo / Luca pgpCmVusPv07Z.pgp Description: PGP signature -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb___ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
Re: making address formatting more flexible
Luca Capello l...@pca.it writes: I do not think there is even a *used* standard within a single country, at least here in Switzerland I saw different layouts sometime according to where the sender lives (French/German/Italian part). And none of the examples at the UPU website uses this ISO-3166 supposed standard: http://www.upu.int/en/activities/addressing/postal-addressing-systems-in-member-countries.html This is an international problem of cooperation. If there is an International Standard, supported by an Organisation (yes, ISO was intentionally capitalised), it should be adhered to, unless there is compelling evidence to the contrary (of outstanding benefit). I think, in this case, it is merely a topic of custom and practice I think, and if any practice is to be adopted for an application with international usage, an internationally accepted standard should be adhered to, if at least to support and strengthen the collaborative effort, which I believe FOSS and Gnu is all about. If bbdb is going to use any country abbreviations, they should be according to ISO is my opinion. However, as far as I am aware, postcodes do not appear in ISO and should be locally (user) specified. -- Johnny -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
Re: making address formatting more flexible
Hi there! On Thu, 03 Feb 2011 05:31:50 +0100, Roland Winkler wrote: On Wed Feb 2 2011 Johnny wrote: This is a good idea; the current BBDB handling seems very US-centered. For one, I think Postal code should replace the American term Zip code as default naming, as this seems to be the generic term. This becomes yet more complicated. I vaguely remember that some other english-speaking countries use yet different names instead of zip code and postal code, but I forgot where it was and what their alternative terminology was... Well, I would say that by default we should use the same term used by the UPU, which is Postcode [1], albeit quite surprisingly the main article on Wikipedia is referred as Postal Code: http://www.upu.int/en/resources/postcodes/about-postcodes.html http://en.wikipedia.org/wiki/Postcode FWIW, here a small survey on some websites: easyJet.com Postcode/Zip Amazon.com ZIP eBay.it CAP (Italian for 'Postal Code') PayPal.com Postal Code (localized, CH-...) FSF.org ZIP/Postal Code FSFE.org Post Code If I remember correctly, Europe introduced zip codes like CH-8052, NL-2300RA, and SE-132 54 I guess this stems from ISO-3166? It does seem appealing to use this standard, but it could take some effort to implement; e.g. would a lookup table be necessary? I am impressed what is covered by some ISO-xyz! Yet I guess what matters in the end is what people actually like to use in real life... I do not think there is even a *used* standard within a single country, at least here in Switzerland I saw different layouts sometime according to where the sender lives (French/German/Italian part). And none of the examples at the UPU website uses this ISO-3166 supposed standard: http://www.upu.int/en/activities/addressing/postal-addressing-systems-in-member-countries.html I am not yet sure what is the best way how to combine a look-up table based on country names with a zip-based scheme. Wikipedia lists a few formattings of postal codes; however this is not defined in ISO-3166. Maybe there's some other source for this though... Well, I want to ask: Is the scheme I proposed general enough to make most people happy? Or is it necessary to have something yet more complicated (and possibly less user-friendly? I wouldn't like that either...) Your proposed scheme is enough customizable, so the situation will be improved anyway WRT the actual US/EU dichotomy ;-) Thx, bye, Gismo / Luca pgpVDR9Eeuzrg.pgp Description: PGP signature -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb___ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
making address formatting more flexible
I am thinking about ways to make the formatting of snail mail addresses more flexible. In my BBDB I have addresses from a few countries in the world, and each goes with slightly different formatting styles, in particular for city, zip code and state. Yet currently BBDB has only two hard-coded functions bbdb-format-address-default and bbdb-format-address-continental. I am thinking about replacing this scheme by a generic function bbdb-format-address that uses some kind of format strings for addresses from different countries. One could have the format specifiers %s streets (used repeatedly for each street part) %c city %z zip code %S state %C country A problem is that not every element is always present in an address. So if there is no country, we want to omit the delimiting newline, too. This would require some kind of generalized format specification. So I thought one could have a delimiter such as `@' in the format string. If the element referred to by a format specifier was missing, everything between two `@' was skipped (e.g., @\n%C@ would omit the newline, too, if there was no country). But we do not need @ at the very beginning / very end of a format string. So we could have for example the following format strings %s\n@%c@, %S@ %z@\n%C USA %s\n@%s @%c@ (%S)@\n%Cmost European countries %s\n@%c@ %S@ %z@\n%C Australia %s\n@%c@ %z@ (%S)@\n%CIndia ... ... (I guess that state names are used neither in Europe nor in India, but if you insist you can get them...) Also, I want to make the scheme for selecting the above address formatting schemes more flexible. Old BBDB used the format of zip code, where the approach was rather euro-centric. I guess this works fine for some people. But for a more international database, it's more reliable to use the country -- if (and only if) an address includes the country field. If I remember correctly, Europe introduced zip codes like CH-8052, NL-2300RA, and SE-132 54 so that one need not spell out country names anymore. I do not know whether people ever followed this rule. Yet it seems that this was the idea underlying Babb-continental-zip-regexp. -- I am not yet sure what is the best way how to combine a look-up table based on country names with a zip-based scheme. Comments and suggestions welcome! Roland -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
Re: making address formatting more flexible
On 2011-02-02 23:15 +0800, Roland Winkler wrote: Yet currently BBDB has only two hard-coded functions bbdb-format-address-default and bbdb-format-address-continental. I am thinking about replacing this scheme by a generic function bbdb-format-address that uses some kind of format strings for addresses from different countries. One could have the format specifiers %s streets (used repeatedly for each street part) %c city %z zip code %S state %C country This is still awkward for Chinese addresses. In bbdb2 it was so awkward to put address in the address field that I have to put them in the notes field. This is because we tend to use one line for the address and it is specified from country/state to street/room number, for example, 香港九龍 觀塘興業街14號永興大廈6樓C1C室. Leo -- Oracle is the new evil -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
Re: making address formatting more flexible
Roland Winkler wink...@gnu.org writes: I am thinking about ways to make the formatting of snail mail addresses more flexible. This is a good idea; the current BBDB handling seems very US-centered. For one, I think Postal code should replace the American term Zip code as default naming, as this seems to be the generic term. I am thinking about replacing this scheme by a generic function bbdb-format-address that uses some kind of format strings for addresses from different countries. ... If I remember correctly, Europe introduced zip codes like CH-8052, NL-2300RA, and SE-132 54 I guess this stems from ISO-3166? It does seem appealing to use this standard, but it could take some effort to implement; e.g. would a lookup table be necessary? I am not yet sure what is the best way how to combine a look-up table based on country names with a zip-based scheme. Wikipedia lists a few formattings of postal codes; however this is not defined in ISO-3166. Maybe there's some other source for this though... -- Johnny -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
Re: making address formatting more flexible
On 2011-02-03 00:41 +0800, Roland Winkler wrote: This is still awkward for Chinese addresses. In bbdb2 it was so awkward to put address in the address field that I have to put them in the notes field. This is because we tend to use one line for the address and it is specified from country/state to street/room number, for example, 14 6 C1C . I am not sure I understand correctly what you are missing here. It appears to me that the room number could become a second street part. (The street part of a BBDB address is really just a list of strings.) Also, newlines would become part of the format specification. So if the format specification for chinese addresses contained no newlines, everything would go on one line. So for the street part you might want to use a plain %s which would be used repeatedly for all street parts. Thanks, that sounds good enough. Leo -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
Re: making address formatting more flexible
On Thu Feb 3 2011 Leo wrote: It appears to me that the room number could become a second street part. (The street part of a BBDB address is really just a list of strings.) Also, newlines would become part of the format specification. So if the format specification for chinese addresses contained no newlines, everything would go on one line. So for the street part you might want to use a plain %s which would be used repeatedly for all street parts. Thanks, that sounds good enough. OK! Roland -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
Re: making address formatting more flexible
On Wed Feb 2 2011 Johnny wrote: This is a good idea; the current BBDB handling seems very US-centered. For one, I think Postal code should replace the American term Zip code as default naming, as this seems to be the generic term. This becomes yet more complicated. I vaguely remember that some other english-speaking countries use yet different names instead of zip code and postal code, but I forgot where it was and what their alternative terminology was... If I remember correctly, Europe introduced zip codes like CH-8052, NL-2300RA, and SE-132 54 I guess this stems from ISO-3166? It does seem appealing to use this standard, but it could take some effort to implement; e.g. would a lookup table be necessary? I am impressed what is covered by some ISO-xyz! Yet I guess what matters in the end is what people actually like to use in real life... I am not yet sure what is the best way how to combine a look-up table based on country names with a zip-based scheme. Wikipedia lists a few formattings of postal codes; however this is not defined in ISO-3166. Maybe there's some other source for this though... Well, I want to ask: Is the scheme I proposed general enough to make most people happy? Or is it necessary to have something yet more complicated (and possibly less user-friendly? I wouldn't like that either...) Roland -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
