#15168: feature request - New setting
------------------------------------------------+---------------------------
Reporter: zay2 | Owner: nobody
Status: closed | Milestone: 1.3
Component: Internationalization | Version: SVN
Resolution: wontfix | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 |
------------------------------------------------+---------------------------
Comment (by zay2):
Look- I need the middleware. The middleware works just fine. Its just this
one specific piece of code in django.utils.translation.trans_real
get_language_from_request that does not provide the desired results. Like
i explained in Original Post, language discovery, based on accept headers
shows pages in undesired language on first visit.
For that reason forementioned method looks like that in my django install,
right now:
{{{
def get_language_from_request(request):
"""
Analyzes the request to find what language the user wants the system
to
show. Only languages listed in settings.LANGUAGES are taken into
account.
If the user requests a sublanguage where we have a main language, we
send
out the main language.
"""
global _accepted
from django.conf import settings
globalpath =
os.path.join(os.path.dirname(sys.modules[settings.__module__].__file__),
'locale')
supported = dict(settings.LANGUAGES)
if hasattr(request, 'session'):
lang_code = request.session.get('django_language', None)
if lang_code in supported and lang_code is not None and
check_for_language(lang_code):
return lang_code
lang_code = request.COOKIES.get(settings.LANGUAGE_COOKIE_NAME)
if lang_code and lang_code not in supported:
lang_code = lang_code.split('-')[0] # e.g. if fr-ca is not
supported fallback to fr
if lang_code and lang_code in supported and
check_for_language(lang_code):
return lang_code
'''
accept = request.META.get('HTTP_ACCEPT_LANGUAGE', '')
for accept_lang, unused in parse_accept_lang_header(accept):
if accept_lang == '*':
break
# We have a very restricted form for our language files (no
encoding
# specifier, since they all must be UTF-8 and only one possible
# language each time. So we avoid the overhead of gettext.find()
and
# work out the MO file manually.
# 'normalized' is the root name of the locale in POSIX format
(which is
# the format used for the directories holding the MO files).
normalized = locale.locale_alias.get(to_locale(accept_lang, True))
if not normalized:
continue
# Remove the default encoding from locale_alias.
normalized = normalized.split('.')[0]
if normalized in _accepted:
# We've seen this locale before and have an MO file for it, so
no
# need to check again.
return _accepted[normalized]
for lang, dirname in ((accept_lang, normalized),
(accept_lang.split('-')[0], normalized.split('_')[0])):
if lang.lower() not in supported:
continue
langfile = os.path.join(globalpath, dirname, 'LC_MESSAGES',
'django.mo')
if os.path.exists(langfile):
_accepted[normalized] = lang
return lang
'''
return settings.LANGUAGE_CODE
}}}
I would need to comment that part of code out from each new django version
without that setting. With setting check, if i want to use that accept
headers based lang discovery, commenting out would be unnecessary.
Did that make it clearer? Why would i want or need to write whole new
languagemiddleware if all i need is one method out of the way?
Thanks,
Alan.
--
Ticket URL: <http://code.djangoproject.com/ticket/15168#comment:2>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
