Localisation
David Walker
completely baffled about localisation and 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?
Any help would be gratefully received.
Lachlan Musicman
I have successfully seen changing the language setting in the/a
browser work (in Japanese) when it comes to localisation of 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...@googlegroups.com.
> To unsubscribe from this group, send email to django-users...@googlegroups.com.
> For more options, visit this group at http://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
David Walker
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:
> > Despite reading round and round in circles in the documentation, I am
> > 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
>
> 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...@googlegroups.com.
> > To unsubscribe from this group, send email to django-users...@googlegroups.com.
Lachlan Musicman
I am not sur e- you seem to have done the work and I trust you did it
correctly :)
> Where do I/we go from here?
I guess we need to bring it up with the developers - ie, should this
be listed as a bug, and if so is it a documentation bug/clarification
that's needed, or does something need to happen at a deeper level.
Plus, there seem to be a multitude of issues (precedence of SHORT_DATE
settings, en_GB short date format...) - which also complicates things.
> Is there a better forum for this?
Yes, I would say that the dev list is the place to go -
django-d...@googlegroups.com I might send through a link to this
discussion to that list now
> Can I help improve things by writing bug reports? enhancements
> requests? patches? documentation? or taking part in discussions?
Yes. How to do it is the hard part. I would frame it as a question,
with clearly demarked issues.
re precedence: expected behavior vs explained behaviour vs witnessed
behaviour (remember to include OS, python version, django version,
documentation version)
re en_GB problems, raise it separately/secondarily and with links that
support your argument.
cheers
L.
--
"There are all kinds of pedants around with more time to read and
imitate Lynne Truss and John Humphrys than to write poems,
love-letters, novels and stories it seems. They whip out their
Sharpies and take away and add apostrophes from public signs, shake
their heads at prepositions which end sentences and mutter at split
infinitives and misspellings, but do they bubble and froth and slobber
and cream with joy at language? Do they ever let the tripping of the
tips of their tongues against the tops of their teeth transport them
to giddy euphoric bliss? Do they ever yoke impossible words together
for the sound-sex of it? Do they use language to seduce, charm,
excite, please, affirm and tickle those they talk to? Do they? I doubt
it. They’re too farting busy sneering at a greengrocer’s less than
perfect use of the apostrophe. Well sod them to Hades. They think
they’re guardians of language. They’re no more guardians of language
than the Kennel Club is the guardian of dogkind."
Stephen Fry
Ramiro Morales
> 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?
There is a "How Django discovers language preference" section in the
translation deplomyment document
http://docs.djangoproject.com/en/1.2/topics/i18n/deployment/
that describes the workflow followed to discover per user preferences.
That document is linked from the main internationalization page with
the following paragraph:
"For system administrators/final users setting up internationalized apps
or developers integrating third party apps: Deployment of translations."
If you think there is a better place for this part of the docs
please feel free to suggest it. I'm interested in cases as yours (you started
this thread with "despite reading round and round in circles in the
documentation, I am completely baffled about localisation and how it
works") so we can improve the organization of the i18n docs.
> The middleware allows the pages to be localised to the browser's
> locale, although there are still a number of strange behaviours
>
> [...]
>
> 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?
>
Sorry for the late reply, I've had this message in draft for almost a week.
I will try to answer to the rest of your concerns after I digest and research
them in the following days.
Thanks for taking the time to describe and yes please if you can
open tickets for the issues you identified. although some of them might
have been already reported, you can search them in our Trac installation
filtering by Component = Internationalization.
Regards,
--
Ramiro Morales