The “local flavor” app

django-localflavor is a collection of assorted pieces of code that are useful for particular countries or cultures. These are called the “local flavor” add-ons and live in the localflavor package.

Inside that package, country- or culture-specific code is organized into subpackages, named using ISO 3166 country codes.

Most of the localflavor add-ons are localized form components deriving from the forms framework – for example, a USStateField that knows how to validate U.S. state abbreviations, and a FISocialSecurityNumber that knows how to validate Finnish social security numbers.

To use one of these localized components, just import the relevant subpackage. For example, here’s how you can create a form with a field representing a Greek postal code:

from django import forms
from import GRPostalCodeField

class MyForm(forms.Form):
    my_greek_postal_code = GRPostalCodeField()

The localflavor package also includes a generic subpackage, containing useful code that is not specific to one particular country or culture. This package defines date, datetime and split datetime input fields based on those from the forms, but with non-US default formats. Here’s an example of how to use them:

from django import forms
from localflavor import generic

class MyForm(forms.Form):
    my_date_field = generic.forms.DateField()

The localflavor generic package also has IBAN and BIC model and form fields. Here’s an example of how to use the IBAN and BIC form fields:

from django import forms
from localflavor.generic.forms import BICFormField, IBANFormField

class MyForm(forms.Form):
    iban = IBANFormField()
    bic = BICFormField()


To install django-localflavor use your favorite packaging tool, e.g.pip:

pip install django-localflavor

Or download the source distribution from PyPI at, decompress the file and run python install in the unpacked directory.

Then add 'localflavor' to your INSTALLED_APPS setting:

    # ...


Adding 'localflavor' to your INSTALLED_APPS setting is required for migrations and translations to work. Using django-localflavor without adding it to your INSTALLED_APPS setting is not recommended.


Local flavor has its own catalog of translations, in the directory localflavor/locale, and it’s not loaded automatically like Django’s general catalog in django/conf/locale. If you want local flavor’s texts to be translated, like form fields error messages, you must include localflavor in the INSTALLED_APPS setting, so the internationalization system can find the catalog, as explained in How Django discovers translations.

Adding flavors

We’d love to add more of these, so please create an issue or pull request with any code you’d like to contribute. See any of the existing flavors for examples.

See the contributing documentation for how to run the tests while working on a local flavor.

If you consider adding a new localflavor for country here are some examples that you might consider implementing:

  • form fields and form widgets
    • ID verification
    • tax or social security number validator
    • car registration
    • postal code validation
    • country area selects, e.g. cities, counties, states, provinces
  • model fields, e.g. for storing any of the above form fields’ values
  • local translations of English area names. Join your language team at Transifex:


django-localflavor does not accept contributions of country specific phone number fields. The django-phonenumber-field package has excellent support for validating phone numbers in many countries and we recommend this package.


django-localflavor releases follow semver with the major version number matching the major version number of Django (from Django 2.0 and above). A compatible version of django-localflavor will be released within one month of each Django release. django-localflavor may have additional releases if there are enough changes in between Django versions to justify a new version of django-localflavor. This means that the minor version number for django-localflavor may not match the minor version of Django itself. See the documentation about Django’s release process for more information.

Deprecation Policy

When non-internal parts of the project are deprecated a DeprecationWarning or a PendingDeprecationWarning will be thrown upon use until the next major version is released. The warning will explain how to safely update your code, and which version the functionality will be removed in. Deprecated code will be removed in releases with a new major version number (e.g. x.0 releases).

Backwards compatibility

We will always attempt to make localflavor reflect the officially gazetted policies of the appropriate local government authority. For example, if a government body makes a change to add, alter, or remove a province (or state, or county), that change will be reflected in localflavor in the next release.

When a backwards-incompatible change is made (for example, the removal or renaming of a province) the localflavor in question will raise a warning when that localflavor is imported. This provides a run-time indication that something may require attention.

However, once you have addressed the backwards compatibility (for example, auditing your code to see if any data migration is required), the warning serves no purpose. The warning can then be suppressed. For example, to suppress the warnings raised by the Indonesian localflavor you would use the following code:

import warnings
from import forms as id_forms