[Django] #22633: LANGUAGE_CODE should be automatically set based on system locale
Django
--------------------------------------+--------------------
Reporter: hakanw | Owner: nobody
Type: Uncategorized | Status: new
Component: Internationalization | Version: 1.6
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+--------------------
Many other frameworks (like Wordpress) make a good job of using the user's
language when you set them up. In many countries, for example some
european countries where people are generally not english speaking, this
is a really important first impression.
I propose that the settings.py should set LANGUAGE_CODE to the user's
locale, if:
1) We find a locale on the system
2) The locale is matched by the list of locales supported by django
If not, we can fall back to the normal en-us.
In addition (but this is more like a bonus thing), since USE_TZ is always
set to True by default, I think it would be cool to set the TIME_ZONE
variable to the user's time zone, but this might be better spun off as
another ticket.
--
Ticket URL: <https://code.djangoproject.com/ticket/22633>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: hakanw | Owner: nobody
Type: New feature | Status: new
Component: | Version: 1.6
Internationalization | Resolution:
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by hakanw):
* needs_better_patch: => 0
* type: Uncategorized => New feature
* needs_tests: => 0
* needs_docs: => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/22633#comment:1>
Django
Reporter: hakanw | Owner: nobody
Type: New feature | Status: new
Component: Internationalization | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by russellm):
* version: 1.6 => master
* stage: Unreviewed => Accepted
Comment:
Sounds like a good idea to me - having correct localization would be a
good OOTB behaviour for non-US users.
From an implementation perspective - the end user should get a settings.py
file with the "right" locale, not a settings.py file with logic that calls
out to the environment. We also need to make sure it works on non *nix
platforms (esp window), and falls back appropriately to en-us when no data
is available.
Agreed that the timezone thing should be a separate ticket; similar rules
would apply for that implementation.
--
Ticket URL: <https://code.djangoproject.com/ticket/22633#comment:2>
Django
Reporter: hakanw | Owner: hakanw
Type: New feature | Status: assigned
Component: Internationalization | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by hakanw):
* owner: nobody => hakanw
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/22633#comment:3>
Django
Reporter: hakanw | Owner: hakanw
Type: New feature | Status: assigned
Component: Internationalization | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by claudep):
As for me, the `LANGUAGE_CODE` of a Django project and the developer's
system locale are rather different things. I'm not opposed to this idea,
but in general, I think the `LANGUAGE_CODE` is part of the settings you
have to review each time a new project is created. I don't care that much
about the default.
--
Ticket URL: <https://code.djangoproject.com/ticket/22633#comment:4>
Django
Reporter: hakanw | Owner: hakanw
Type: New feature | Status: assigned
Component: Internationalization | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by hakanw):
For me, and I know others have the similar problem, the first thing I
always have to do is set this to my language. I think it would rock if
django had sensible defaults when it's easy :)
--
Ticket URL: <https://code.djangoproject.com/ticket/22633#comment:5>
Django
Reporter: hakanw | Owner: hakanw
Type: New feature | Status: assigned
Component: Internationalization | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by hakanw):
I'm working on this here:
https://github.com/hakanw/django/commits/default_settings_locale
No tests so far, just testing the approach.
--
Ticket URL: <https://code.djangoproject.com/ticket/22633#comment:6>
Django
Reporter: hakanw | Owner: hakanw
Type: New feature | Status: assigned
Component: Internationalization | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by hakanw):
* has_patch: 0 => 1
Comment:
Now there's code + tests that pass above.
--
Ticket URL: <https://code.djangoproject.com/ticket/22633#comment:7>
Django
Reporter: hakanw | Owner: hakanw
Type: New feature | Status: assigned
Component: Internationalization | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by erikr):
* needs_better_patch: 0 => 1
Comment:
Could you make a proper pull request against django/django master on
GitHub? That makes review a lot easier :)
--
Ticket URL: <https://code.djangoproject.com/ticket/22633#comment:8>