path for fix hardcode 'django_language'

[ablis]

django/utils/translation/trans_real.py and django/views/i18n.py b/django/views/i18n.py have some hardcode sessiondjango_language.
It will be some problem with language in admin if change settings.LANGUAGE_COOKIE_NAME. I attached path for fix that.

[Carl Meyer]

I think you are confusing the _cookie_ name with the _session_ key name. LANGUAGE_COOKIE_NAME is correctly used when setting or getting the actual cookie. The session key name is hardcoded to django_language; but changing LANGUAGE_COOKIE_NAME will not affect that, and should not cause any problems with language in the admin.

If you are seeing a problem when changing LANGUAGE_COOKIE_NAME, please post more detailed duplication instructions.

[ablis]

I'm sorry, do you like hardcode?
request.sessiondjango_language and request.session[settings.LANGUAGE_COOKIE_NAME] is equivalent,
but, for example, if you make in your settings.LANGUAGE_COOKIE_NAME = "site_language"?
code like that:

if hasattr(request, 'session'):

lang_code = request.session.get('django_language', None)

will not work. Because it's absolutely hardcode... And your admin language will not be changed...

[Carl Meyer]

Replying to ablis:

code like that:

if hasattr(request, 'session'):

lang_code = request.session.get('django_language', None)

will not work. Because it's absolutely hardcode... And your admin language will not be changed...

Have you actually tried setting LANGUAGE_COOKIE_NAME and seen something break?

I don't think you read or understood my first response.

By default, Django uses the session to store your language preference. If contrib.sessions is not installed, it falls back to using a cookie. The two systems are entirely separate, and the cookie system is only used if you don't have sessions available.

In the case of using the session, the session key name is hard-coded to "django_language." In the case of using the cookie, the cookie name is the value of LANGUAGE_COOKIE_NAME. A cookie name is visible to the site user, so there are valid use-cases for wanting to change it. A session key name is server-side-only, so there's no need to change it.

If you think that the session key name should _also_ be configurable with a setting, that would be a separate setting, and you would need to bring that up as a feature request on the django-developers mailing list, with a use-case that justifies the need.

Having LANGUAGE_COOKIE_NAME double also as a session key name, as your patch does, makes no sense: the name of the setting clearly indicates that it is a _cookie_ name.

Please don't reopen this ticket again unless you can provide step-by-step instructions for how to reproduce an actual observable problem.

[ablis]

Oops... Sorry for waste your time. My mistake... different constants with the same name.

[ablis]

And for the end. My opinion is that add on the default settings the constant like SESSION_LANGUAGE_NAME ='django_language' will be more correct.