Originally posted on [skam.webfactional.com](http://skam.webfactional.com/blog/2007/07/16/babel-integration-django/)
This is a very simple middleware that uses babel (http://babel.edgewall.org) for accessing locale data in request objects through request.LOCALE attribute.
It also provides a function to get locale data outside views.
settings.py:
MIDDLEWARE_CLASSES = (
... cut ...
'django.middleware.locale.LocaleMiddleware',
'middleware.locale.BabelMiddleware',
... cut ...
)
This is something we're using over at Curse to keep things clean and simple for our users.
* We needed a url for any language code (which the domain provides) vs a cookie
* We needed a to only store 2 letter codes in the db for each language (thus the key doesn't always match the code)
This consists of two major modifications:
* LANGUAGES in settings.py is a completely different format and would need changed based on your setup
* the locale middleware has a couple absolute instances of where to point a user by default.
A little tiny middleware that, when used in multilingual sites, will make Django I18N ignore any `Accept-Language` headers in the request, thus ensuring that every first-time visitor (with no explicit language preference set via session or cookie) will see the site in the language specified by `settings.LANGUAGE_CODE`.
(Please note that I think that overriding user preferences is generally a bad practice, but I had my reasons to use it :) )
Changes **all slugify calls** to support translat automatically, behind the scenes. Using this one doesn't have to change any models or code to make it work everywhere.
Create new project, I call it myself *autoslugifytranslat*, and add the following to project's `__init__.py` file. It will automatically add translat slugify support for all default slugify calls.
This script is depending on the fact that slugify function in Django is always in *django.template.defaultfilters.slugify*.
**Note:** The snippet is supposed to have "ä","Ä" and "ö","Ö" in the `char_translat` list, but djangosnippets does not let me put ä's and ö's to the code part!
A way to implement models with translatable content.
The translatable field of the default language has no extension, like "title" and the translations have extensions postfixes "_<two-letter language code>", like "title_la" or "title_mn". Method get_title() in this case returns the translation of the currently chosen language or the title of the default language, if the translation is not set.
The class XFieldList overrides the default list class and is used for modifying ordering and list_display settings according the chosen language. For example, when the German language is chosen, the list of translatable content objects will be ordered by German titles (not English).
*At the time when the list of field names is assigned to ordering or list_display (at the import of the model), the currently chosen language is still not known. But the language is known when ordering and list_display lists are used in contributed administration or elsewhere.*
The XFieldList returns the modified values of the passed-in list, when its methods/properties are triggered. XFieldList transforms field names ending "_" (except the ones beginning with "__", like "__str__") to appropriate translations according the currently chosen language. For example ['title_', 'content_', 'is_published'] will be changed to ['title', 'content', 'is_published'] for the English language and to ['title_lt', 'content_lt', 'is_published'] for the Lithuanian language.
*The best practice is to put XFieldList into a separate file and import it from different apps whenever needed.*
It's worth mentioning that one implementing this should also know about [Django internationalization](http://www.djangoproject.com/documentation/i18n/).