This snippet display a human readable date diff. You give it the your date in parameter and the diff with datetime.datetime.now() is returned. The diff must be positive to be more accurate (future dates are not supported) Usage: {{ status.created_at|date_diff }} Will give something like: less than 1 minute ago 13 minutes ago 1 hour ago etc. Based on [Fuzzy Date Diff Template Filter](http://www.djangosnippets.org/snippets/1347/)
This is an example middleware that is highly inspired by how Symfony handles [i18n in URLs](http://www.symfony-project.com/book/trunk/13-I18n-and-L10n#Changing the Culture for a User). You basically set a (?P<dj_culture>[\w-]+) pattern in your URL and this middleware will determine the language to use for the i18n toolkit for Django. It also removes the dj_culture parameter after dealing with it, so that you don't have to change all the views you want this middleware to work with.
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/).
This Snippet allows for your project's apps names to be displayed as you want in the Admin, including translations. The lists of apps and languages are created from your settings.py file. **How to use** 1st part: - Create a application called 'apps_verbose' in you project with the models.py and admin.py showed here - Create a folder inside it with named 'templatetags' with the verbose_tags.py file inside it. - Add this app to installed apps in your settings.py - If you change this app name, dont forget to correct the imports. 2nd part: - Create a folder named 'admin' in your templates folder and copy the following files form your /django/contrib/admin/templates/admin/ folder. - /app_index.html - /base.html - /change_form.html - /change_list.html - /delete_confirmation.html - /delete_selected_confirmation.html - /index.html - /object_history.html - Make the necessary changes in each file, like shown here. 3rd part: - Create translations in the Admin and enjoy.
you have a multilingual site and need to change languages in admin. Previously this was easy in the site itself and more difficult in admin. Now it is dead easy. Set up your languages in settings.py. Make a directory called 'admin' in your templates directory, copy ~/django/contrib/admin/templates/base.html to that directory. Add the following code (below breadcrumbs is a good place) this will give you a switcher for all installed languages. You would need to refresh the browser on changing the language.
Looks up for a template based on the template-name plus the current users language code. Loads the template and renders it with the current context. Example:: {% langinclude "foo/some_include.html" %} Based on the users LANGUAGE_CODE, assumed we have 'de', it tries to render the template 'foo/some_include.html.de'. If that doesn't exists, it renders the template 'foo/some_include.html'. This is the default behavior of the include-Tag. Basically this is a shortcut for the following code, just with a fallback for the default template:: {% ifequal LANGUAGE_CODE "de" %} {% include "foo/some_include.html.de" %} {% else %} {% include "foo/some_include.html" %} {% endifequal %} --- Ein deutscher [Weblogeintrag mit Beschreibung](http://www.mahner.org/weblog/sprachabhangige-template-imports/)
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.
Usage: {% load helper_tags %} {% get_available_languages as languages %} {% for lang_code, lang_name in languages %} <link rel="alternate" hreflang="{{ lang_code }}" href="{% change_lang lang_code %}"> {% endfor %}
This is a Model base class used to support internationalization (i18n) for your models. This code extends the Django's Model class so you can use all available options from Model safely. Basicly, it uses introspection to create a sub-model to your model to hold translation. **Features:** 1. Simplicity of use. You simply extend your model with this class and add all the fields that needs to be translated are placed under the `locale` sub-class; 2. The code uses the `django.utils.translation.get_language()` to select the current language; 3. You can use `python ./manage.py syncdb` command safely; 4. Force the user to enter a translation for each language even if the fields can be blank. This makes sure that all objects are returned safely. **Ordering by locale fields:** To sort on translated fields, use the form of "model_i18n__transfieldname" (see code for example). **Limitation:** Do not use localized fields in __unicode__, the admin will throw an exception when you'll add a new item and do "save and continue". Just drop a comment if you need more information. (last update: 06/15/2010)
If you try to load a template named filename.LANG.html it will try to load filename.de.html first, then filename.html afterwards (assuming that German is the currently selected language). Usage: Put in a file named langtemplateloader.py under your project, and replace django's default filesystem loader with this in the TEMPLATE_LOADERS section of settings.py: TEMPLATE_LOADERS = ( 'myproject.langtemplateloader.load_template_source', # 'django.template.loaders.filesystem.load_template_source', 'django.template.loaders.app_directories.load_template_source', 'django.template.loaders.eggs.load_template_source', )
Together with my mentor, Dusty Phillips, I have developed a simple class that dynamically adds two fields to its subclasses. This is useful in cases when a single piece of content is divided into translatable and non-translatable fields, connected by a 1-to-many relationship. ## Update 2009/03/30 Since its inception, this snippet has grown into a significantly more powerful solution for translatable content (I use it myself with great joy :). The project is now hosted on github: [project page](http://github.com/foxbunny/django-i18n-model/tree/master) ## Update 2008/07/09 It is now possible to define `i18n_common_model` attribute in `class Meta` section. Here's an example: class Meta: i18n_common_model = "MyCommonModel" As you can see, it has to be a string, not the real class, and it is case-sensitive. ## Example class Article(models.Model): author = models.CharField(max_length = 40) class Admin: pass class ArticleI18N(I18NModel): title = models.CharField(max_length = 120) body = models.TextField() class Admin: pass # optionally, you can specify the base class # if it doesn't follow the naming convention: # # class Meta: # i18m_common_model = "Article" When the ArticleI18N class is created, it automatically gains two new fields. `lang` field is a CharField with choices limited to either `settings.LANGUAGES` or `django.conf.global_settings.LANGUAGES`. The other field is `i18n_common` field which is a ForeignKey to Article model. ## The conventions * call the translation model `SomeBaseModelI18N`, and the non-translation model SomeBaseModel (i.e., the translation model is called basename+"I18N") * the first convention can be overriden by specifying the base model name using the `i18n_common_model` attribute in `Meta` section of the `I18N` model * I18N model is a subclass of `I18NModel` class ## Original blog post [http://blog.papa-studio.com/2008/07/04/metaclasses-and-translations/](http://blog.papa-studio.com/2008/07/04/metaclasses-and-translations/)
I like the per-site caching offered by Django (it's simple) and I like the cache to be dependent on the chosen language. Unfortunately with the current `CacheMiddleware` you can either have the one or the other but not both at the same time. `VaryOnLangCacheMiddleware` is a small wrapper around `CacheMiddleware`. It looks at the `request.LANGUAGE_CODE` (set by `LocaleMiddleware`) and appends it to your `CACHE_MIDDLEWARE_KEY_PREFIX`. So "mysiteprefix" becomes "mysiteprefix_en" or "mysiteprefix_de-AT" depending on the user's chosen language. Site-wide, so no messing with per-view decorators and stuff. To use this, make sure `VaryOnLangCacheMiddleware` comes below `LocaleMiddleware` in your settings.py. If you haven't set your `CACHE_MIDDLEWARE_KEY_PREFIX`, it's works, too. **Update:** Replaced `super()` calls with `CacheMiddleware.xxx(self, ...)`.
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 snippet holds your Django project from automatically changing language of the page to the best fitting one by discovering the client browser language. I personally needed to show the page to the user for the first time in the default language (English), although there were some translations. User can still change the language (via session cookies). Insert this middleware BEFORE the Django's `django.middleware.locale.LocaleMiddleware` in settings.
This snippet is inspired by [dnordberg](http://djangosnippets.org/snippets/1048/) 's translation script which used google's translation script. But after google translation is no more free. I put together it to use microsoft translator's python wrapper by [openlab](https://github.com/openlabs/Microsoft-Translator-Python-API) usage ----- 1. get a bing appID from [here](https://ssl.bing.com/webmaster/developers/appids.aspx) and replace it on the top of script 2. sudo apt-get install translate-toolkit 3. sudo pip install microsofttranslator 4. sudo autotranslate.py [pofile] [sourcelangcode] [targetlangcode] Enjoy!!! **Prabhat Kumar Gupta** Python/Django Dev [http://www.prabhatgupta.com](http://www.prabhatgupta.com)