Snippet List
A script that gathers statistics of translated, untranslated and fuzzy literals of translations (be it Django itself or a project using Django).
For that it re-scans the tree and generates a up-to-date POT in a temporary location, so the statistics of translation "coverage" are calculated relative to the current status of the tree. It doesn't touch the tree it is analyzing at all.
It should be run from the directory containing the `locale/` directory of your project or from the `django/` directory of a Django copy.
It is based on the `makemessages` Django management command (or rather its previous standalone `make-messages.py` script incarnation) and uses the same command line switches:
* `-d <domain>` -- `<domain>` is `django` or `djangojs`. Optional, defaults to `django`.
* `-l <language>` OR
* `-a` -- process all languages
- internationalization
- i18n
- l10n
- translations
- status
- statistics
- localization
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 ...
)
- middleware
- i18n
- l10n
- locale
- babel
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 :) )
- middleware
- i18n
- l10n
- locale
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/).
- i18n
- l10n
- translations
- multilingual
4 snippets posted so far.