On Tue, Aug 25, 2009 at 11:08 AM, ch...@moffitts.net<chris.moff...@gmail.com> wrote: > > > > On Aug 22, 8:12 am, Russell Keith-Magee <freakboy3...@gmail.com> > wrote: >> On Sat, Aug 22, 2009 at 7:49 PM, Tim >> >> Chase<django.us...@tim.thechases.com> wrote: >> >> > James Bennett wrote: >> >> The current proposal is for a "USPostalCodeField" which >> >> corresponds to the US Postal Service's list of postal codes: >> >> >>http://www.usps.com/ncsc/lookups/abbr_state.txt >> >> >> [snip] Based on the various arguments up to this point, it >> >> seems like no single field is going to make everybody happy, >> >> Agreed that this particular argument is a recurring theme that we >> should address. >> >> > Internally, I've solved a similar "can't make everybody happy" >> > problem with a class factory function that takes the desired set >> > of defined data, depending on the project: >> >> Given that the number of options is constrained, a fully-fledged >> factory strikes me as overkill. Why not just booleans on the field >> itself? >> >> USStateField(lower_48=True, dc=True, non_contiguous=True, >> protectorates=False, military_drops=True) >> >> No need to deprecate anything - we can continue to ship USStateField >> as is, just with some extra options that have default boolean values >> set to reflect the currently enabled choices. >> >> Given that US postal codes seems like a particularly common request, >> there isn't much harm in including a a USPostalCodeField as a shortcut >> - it's just a subclass with all the options set True. >> > > I'll toss out one idea. In Satchmo, we have an l10n application to > support this data. We use a fixture to load the following data: > - ISO2, ISO3 and ISO numeric > - Official Name, Continent and Aministrative Area (state, territory, > etc) > - List of all Admin Areas (aka states in US) with full name and > abbreviation > > for most of the countries of the world. > > The nice thing about this approach is that if someone wants to add an > administrative area of some sort, it can be done and if they want to > deactivate one, it's simple. I realize this may be a bit out of the > scope for this particular issue but it feels like it would be a more > robust solution and would scale nicely to other countries. This would > also be a really cool feature to have in Django as a whole. Once the > models are in place, data maintenance is pretty simple. Integrating > into the USStateField of other country fields wouldn't be too > difficult. > > Anyway, let me know your thoughts. The Satchmo l10n code is BSD > licensed and I'd be willing to help if there's sufficient interest.
Hi Chris, While I can appreciate the intent of your suggestion, we've said in the past that we don't want Django to become a repository for i18n and l10n data. I don't see any particularly strong reason to change this policy. There are several reasons for this decision. Firstly, it's a lot of data to carry around, and not every project will need this data. It's also a huge maintenance burden for us - and for the translators that need to inspect and potentially translate every region name etc. Secondly, this is one of those areas where the community can play an important role. I'd much rather see a vibrant community of i18n/l10n data tools than try to generate the One True Font of Regions, and ship it with Django. Django should stick to what it is good at. Let the community decide where the best source of i18n data is to be found. So - Django tries to ship with a basic set of l10n data and tools that is useful to many. It's not perfect, but it's suitable for most simple cases. We'll try to accommodate simple configuration requests (such as giving some flexibility for US states), but there comes a point where we'll say no. There's a line between 'batteries included' and 'includes every battery you will ever need for every Tibetan kitchen appliance you will ever buy' :-) So - if you're sufficiently enthused by the l10n problem, I heartily encourage you to split the l10n code and data out of Satchmo into a separate project. If anyone else in the community is interested in this problem, I encourage you to take Chris up on his invitation to use his BSD licensed code and data. There is plenty that could be done in the l10n space for Django, and I'm eager to see what the community can do. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
