I'd like to move all Django localflavor code into a separate package,
distributed separately from Django the framework.
1. We shouldn't be in the business of updating Romanian phone number
rules (e.g., https://github.com/django/django/pull/275
). That doesn't
belong in a Web framework.
2. The localflavor code makes Django more bloated than it should be,
in terms of number of files (a concern with stuff like App Engine) and
download size (not a huge concern, but still worth improving).
On Feb. 14, 2007, I created django.contrib.localflavor because I felt
guilty we had USA-specific form fields.
Nearly immediately, people saw this and started contributing form
fields and validation logic for their own countries / governments. It
was kind of amazing to watch all of the patches come in, and you could
feel the national pride from contributors all over the world.
In retrospect, setting this expectation and allowing all of this code
into Django proper was a bad idea. We should have created an
infrastructure for a *separate* package (or packages) of
country-specific stuff, not shipping it with Django proper.
I think it makes most sense for there to be country-specific packages,
such as django-forms-us or django-forms-es, that are distributed
independently. These would be very easy to install (via pip), and
people outside of the Django core team could maintain them and take
full responsibility for them.
Considering backwards-compatibility, we could jumpstart these
country-specific packages by (1) creating them in the first place and
(2) replacing the django.contrib.localflavor code with code that
imports from the correct third-party library (e.g., djangoforms_us),
as a shim. For Django 1.5, we'd tell people to install the appropriate
django-forms-* packages for their sites, and their code referencing
django.contrib.localflavor would still work (with a
How does this sound? I'm happy to start doing the work myself on Sept.