This is a simple TextInput widget that uses my [Currency object](http://www.djangosnippets.org/snippets/1525/).
I placed my Currency object in the Django utils directory because I integrated a set of currency objects into the Admin app ( [here](http://www.djangosnippets.org/snippets/1529/) ) and it was just easier to have everything within Django.
The rest of the series: [Currency Object](http://www.djangosnippets.org/snippets/1525/), [Currency Form Field](http://www.djangosnippets.org/snippets/1527/), [Currency DB Field](http://www.djangosnippets.org/snippets/1528/), [Admin Integration](http://www.djangosnippets.org/snippets/1529/)
This object stitches together the [Babel](http://babel.edgewall.org/) number formating and the Decimal object, with a little of my own hand rolled validation for parsing.
Note the comment at the end of the code. It contains two lines to add to your settings.py.
CURRENCY_LANGUAGE_CODE = 'pt_BR'
CURRENCY_CODE = '' # If one exists like 'USD', 'EUR'
UPDATE 06-03-2009: Now with rounding
UPDATE 07-14-2009: Now with - More graceful handling of missing settings variables - Support for negatives (small oversight) - More flexible format strings - Thorough doctest tests
UPDATE 07-30-2009: Added the parse_string argument to the `__new__()` method. This fixes a bug when importing data using `manage.py loaddata`. I have not yet updated the tests to reflect the change.
The rest of the series: [Currency Widget](http://www.djangosnippets.org/snippets/1526/), [Currency Form Field](http://www.djangosnippets.org/snippets/1527/), [Currency DB Field](http://www.djangosnippets.org/snippets/1528/), [Admin Integration](http://www.djangosnippets.org/snippets/1529/)
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',
)
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/)
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/)
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
Another one like [980](http://www.djangosnippets.org/snippets/980/), but using re's instead.
I haven't benchmarked these, but my guess is that [981](http://www.djangosnippets.org/snippets/981/) is faster for strings of pure digits and this is faster for larger chunks of text that happen to contain digits. If you're generating the numbers yourself, I'd just use 981 on a number right when you generate it.
This is based on [980](http://www.djangosnippets.org/snippets/980/), removing the unnecessary use of StringIO. Hopefully the translation can be educational.
Arabic and Farsi languages use their own digits. This template filter translates any digits in the supplied unicode string into the correct ones for the language. The previous version used StringIO to parse the string one character at a time. It now uses regular expressions.
I just saw that kcarnold created two snippets that also removed the need for StringIO: [981](http://www.djangosnippets.org/snippets/981/) and [982](http://www.djangosnippets.org/snippets/982/). That last snippet is almost the same as this one.
- Choices are saved as the key integers.
- Admin will show the correct translation in forms.
- You can reuse the make_choices function for other choices fields.
- Bad side: bin/make_messages.py won't get the choices values automatically, you have to add them in the .po's by hand.
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, ...)`.
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.
Deprecated. I don't use this any more.
Hi,
I want decimal input which uses a comma as decimal seperator. It was quite complicated,
but it works.
It can be used as an example how to create an own subclass of an existing db.Field class and how to pass the dbfield to the widget, and use it in its render() method.
I think my snippet is too complicated, but couldn't find a better solution. If you do, please tell me.