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:2669 unmerged

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 Håkan W, 11 years ago

Type: UncategorizedNew feature

comment:2 by Russell Keith-Magee, 11 years ago

Triage Stage: UnreviewedAccepted
Version: 1.6master

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.

comment:3 by Håkan W, 11 years ago

Owner: changed from nobody to Håkan W
Status: newassigned

comment:4 by Claude Paroz, 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 Håkan W, 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 Håkan W, 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:7 by Håkan W, 11 years ago

Has patch: set

Now there's code + tests that pass above.

comment:8 by Sasha Romijn, 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 :)

Note: See TracTickets for help on using tickets.
Back to Top