Opened 11 years ago
Last modified 11 years ago
#22633 assigned New feature
LANGUAGE_CODE should be automatically set based on system locale
Reported by: | Håkan W | Owned by: | Håkan W |
---|---|---|---|
Component: | Internationalization | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Pull Requests: | |||
Description ¶
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.
According to the ticket's flags, the next step(s) to move this issue forward are:
- To improve the patch as described in the pull request review comments or on this ticket, then uncheck "Patch needs improvement".
If creating a new pull request, include a link to the pull request in the ticket comment when making that update. The usual format is:
[https://github.com/django/django/pull/#### PR]
.
Change History (8)
comment:1 by , 11 years ago
Type: | Uncategorized → New feature |
---|
comment:2 by , 11 years ago
Triage Stage: | Unreviewed → Accepted |
---|---|
Version: | 1.6 → master |
comment:3 by , 11 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:4 by , 11 years ago
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.
comment:5 by , 11 years ago
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 :)
comment:6 by , 11 years ago
I'm working on this here: https://github.com/hakanw/django/commits/default_settings_locale
No tests so far, just testing the approach.
comment:8 by , 11 years ago
Patch needs improvement: | set |
---|
Could you make a proper pull request against django/django master on GitHub? That makes review a lot easier :)
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.