Thanks Lachlan.
The middleware was the bit I was missing. The only mention of it on
the Django website appears to be on the Middleware page. Perhaps it
should go on the localisation pages?
The middleware allows the pages to be localised to the browser's
locale, although there are still a number of strange behaviours
There seem to be two main places where date formats originate. They
are set in settings.py and in the locale's formats.py
(django.conf.locale.<locale_code>.formats).
formats.py sets (amongst others) DATE_FORMAT and SHORT_DATE_FORMAT for
the locale in question (along with a load of other datetime formats).
setings.py sets L10N, and also DATE_FORMAT and SHORT_DATE_FORMAT.
If L10N is True, the SHORT_DATE_FORMAT in settings.py is not used in
rendering, with the localised version from the appropriate formats.py
being used instead.
However, Django uses two versions of DATE_FORMAT. The settings.py one
defaults to to the US format of 'N j, Y', but can be changed. The
formats.py one contains the appropriate setting for your locale (but
see en_GB below!).
So, what does all this mean for rendering? I think that the following
happens (assuming that d is a date):
{{d|date:"SHORT_DATE_FORMAT"}}
produces a localised short date: 'd/m/Y' here in the UK
{{d}}
produces a localised long date: 'j \de F \de Y' in Portugal
{{d|date}}
produces a date based on the settings.DATE_FORMAT ( 'N j, Y'
unless changed), but incredibly the month name is translated to the
browser locale. This often produces date that no one would ever use
like: Março 10, 2010 (the default setting with a Portuguese browser).
I seem to remember seeing in some documentation somewhere (that I now
can't find) that it was intended that the date filter without
arguments would produce a consistent, machine readable date format.
While it may be useful to have a locale independent date format, this,
to me, has a number of problems:
1. re-using the variable name DATE_FORMAT is bound to cause confusion
2. using a common human format for locale independent machine readable
dates is likely to cause confusion.
3. translating the result renders the whole process pointless.
Meanwhile, the documentation says:
http://docs.djangoproject.com/en/dev/ref/settings/#date-format
Note that if USE_L10N is set to True, then the locale-dictated
format has higher precedence and will be applied instead.
http://docs.djangoproject.com/en/dev/ref/templates/builtins/#date
When used without a format string...the formatting string defined
in the DATE_FORMAT setting will be used, without applying any
localization.
Neither of these statements correctly describe the actual behaviour I
have observed.
To add to my confusion, django.conf.locale.en_GB.formats contains
DATE_FORMAT='N j, Y', whereas I think it should be something like 'j F
Y', 'j N Y' or 'jS F Y'. The Unicode Common Locale Data Repository
seems to agree with me, plumping for 'd MMMM y' or 'd MMM
y' (obviously these are in a different format).
Have I got this right?
Where do I/we go from here?
Is there a better forum for this?
Can I help improve things by writing bug reports? enhancements
requests? patches? documentation? or taking part in discussions?
Cheers,
Dave
On Jan 17, 4:39 am, Lachlan Musicman <data...@gmail.com> wrote:
> On Sun, Jan 16, 2011 at 04:23, David Walker <d...@walker.cx> wrote:
> > Despite reading round and round in circles in the documentation, I am
> > completely baffled aboutlocalisationand how it works. I am not
> > trying to do any translation yet, but want to code money and date
> > formats right so that I don't have to rewrite things later.
>
> > It isn't even clear to me which locale things are being localised to.
> > I had presumed that everything would be localised to the browser's
> > locale, using the language setting, however it seems to be localised
> > to the LANGUAGE_CODE setting from settings.py. Am I doing something
> > wrong?
>
> I have successfully seen changing the language setting in the/a
> browser work (in Japanese) when it comes tolocalisationof a django
> based site, with LANGUAGE_CODE set to "en".
>
> You may need to send more information, for eg:
>
> which version of django on what platform (these are less important,
> but you never know)
>
> Do you have USE_L10N = True in settings.py?
>
> Do you have 'django.middleware.locale.LocaleMiddleware', in
> MIDDLEWARE_CLASSES?
>
> cheers
> L.
>
>
>
> > Any help would be gratefully received.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django users" group.
> > To post to this group, send email to django-users@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-users+unsubscr...@googlegroups.com.
> > For more options, visit this group
> > athttp://groups.google.com/group/django-users?hl=en.
>
> --
> "... imagine a puddle waking up one morning and thinking, 'This is an
> interesting world I find myself in - an interesting hole I find myself
> in - fits me rather neatly, doesn't it? In fact it fits me
> staggeringly well, must have been made to have me in it!' This is such
> a powerful idea that as the sun rises in the sky and the air heats up
> and as, gradually, the puddle gets smaller and smaller, it's still
> frantically hanging on to the notion that everything's going to be
> alright, because this world was meant to have him in it, was built to
> have him in it; so the moment he disappears catches him rather by
> surprise."
> Douglas Adams
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
