Let's not dabble in the international politics, but support practical choices. There is an official table provided by U.S.P.S. listing states, possessions, and military "states" recognized as valid abbreviations: http://www.usps.com/ncsc/lookups/abbr_state.txt
If somebody doesn't like it --- write a letter to the Postmaster General, or the Secretary of State to straighten out our international agreements. So I am for #4. Yes, sometimes businesses ship only to a subset of that list, e.g., conterminous United States (GIS geeks know what I am talking about). And sometimes they require to state a place of residence, which can be only real states and DC. And in some cases businesses operate only in handful of states. So what? We cannot provide a custom-tailored table for everyone --- use filtering if you are in this situation, or clone and modify the table suitable to your personal needs. Eugene Lazutkin Dojo Toolkit, Committer SitePen, Developer James Bennett wrote: > Over the past few months we've had a few back-and-forth tugs in the > ticket tracker, and a couple of commits, related to the choice list > for ``django.contrib.localflavor.us.forms.USStateField.`` > > Relevant background: > > * First, ticket #8425 asked for several choices to be removed, on > grounds that they are now sovereign nations and not US territories > or protectorates (resolution: the choices were removed): > http://code.djangoproject.com/ticket/8425 > > * Then, ticket #9022 asked for US armed forces postal codes to be > supported (resolution: wontfix): > http://code.djangoproject.com/ticket/9022 > > So it seems there's some tension as to what, exactly, "USStateField" > should do, and it seems there are a few options we could go with here: > > 1. Support only the fifty entities which are states of the US, and > nothing else. This would make it a true "US state field", but would > be unacceptable since this would exclude the District of Columbia > (which is, famously, not a state) and so make quite a lot of people > very unhappy. > > 2. Support the fifty states and the District of Columbia, and nothing > else. This would technically add something that's not really a "US > state", but I think most people would forgive us for it, and this > is a bit more acceptable since it covers all common US > destinations, for things like order forms which need addresses > filled in. > > 3. Support all 50 US states, the District of Columbia, US overseas > territories/protectorates/dependencies, and US armed forces postal > codes. This would move further from just being "US state" field, > but would cover a much wider range of "US" addresses. > > 4. Support the full list of locations/codes supported by the US postal > service[1]. This includes several places which are sovereign > nations, but which have specialized treaties or other agreements > with the US (often the result of former trust territory status) and > so are supported by the US postal service as "US" addresses. > > Personally I lean toward option 4. For a ``localflavor`` module, I > think we really ought to rely on appropriate local authority whenever > available, and in this case the US postal service is the appropriate > authority for what constitutes a "US" address. > > One alternative, of course, would be to provide a number of separate > fields -- one for "US states + DC", one for "US territories and > protectorates", one for "US armed forces postal codes", etc. -- but > given that the utility of a ``localflavor`` field like this mostly > comes from having a *single* field that can cover addresses for a > given locale, I'd be rather averse to it. > > Also, from a backwards-compatibility perspective, the ``USStateField`` > in current trunk is a functionality regression for anyone relying on > the ``USStateField`` from Django 1.0.x, and that's also something I'd > prefer to avoid. > > Does anyone have strong feelings on this one way or another? With 1.1 > looming I'd like to get this resolved and have a consensus view we can > point folks to if there are further concerns about it. > > > [1] http://www.usps.com/ncsc/lookups/abbreviations.html#states > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
