Re: Locale from URL Middleware
2006/5/19, jon1012 <[EMAIL PROTECTED]>: I've done an helper function that strips the selected language from thecurrent url and return it... Usefull to make a language change button..All you have to do is to make a link to the url with '/fr' for example in front of the value given by the function:Thanks for your function, that's not exactly what I need but it's really interesting.
Re: Locale from URL Middleware
I've done an helper function that strips the selected language from the
current url and return it... Usefull to make a language change button..
All you have to do is to make a link to the url with '/fr' for example
in front of the value given by the function:
from django.conf import settings
def get_absolute_path_without_lang(request):
for lang in settings.LANGUAGES:
if '/' + str(lang[0]) + '/' in request.path:
return request.path.replace('/' + str(lang[0]) + '/',
'/')
return request.path
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---
Re: Locale from URL Middleware
2006/4/5, Rudolph <[EMAIL PROTECTED]>: I would like to add another good reason: Another nice effect languagecodes in the URL is that search engine crawlers can easily get all yourcontent.My customers often want something like this: www.example.com -> site in the main language of your visitorswww.example.nl -> site in Dutchwww.example.com/nl-nl/ -> site in Dutch etc.I would highly appreciate such middleware.RudolphHi! I'm really interested in this option (domain-name extension -> appropriate language), is it possible to have more details in implementation? I'm a beginner in django so maybe I haven't look at the right place, feel free to answer with a simple link.Cheers,David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Locale from URL Middleware
A downside in this is increased complexity when generating links between pages. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Locale from URL Middleware
Optional middleware seems okay, or perhaps we can just set up a wiki-page on the Django site about this so everybody can implement this their own way. Rudolph --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Locale from URL Middleware
On 4/5/06, Simon Willison <[EMAIL PROTECTED]> wrote: > > On 5 Apr 2006, at 12:26, limodou wrote: > > > Why you need do this? Because django can auto judge the language from > > your browser request http head, or context settings, or settings. If > > you like , you can provide a language selection in web page, and > > that's enough. The url doesnot need to be special processed I think. > > I for one much prefer the language to be specified in the URL rather > than being derived from the browser settings. I would prefer this > behaviour to be supported (at least as an option) in Django core. I > know that language detection based on browser HTTP headers is a > feature of the HTTP specification, but personally I believe that it's > a mistake in the spec. Here's my reasoning: > > 1. Serving up content from the same URL in a different language > depending on browser settings is an idea that is based on the ideal > situation where each translation is a perfect representation of the > content's underlying meaning. This is clearly not a realistic > proposition. Some languages have phrases that do not perfectly > translate to other languages, and translations may not be perfect in > any case due to human error. The French version of a page is > fundamentally different from the English version, and I believe that > the URL should reflect that. > > 2. Passing URLs around. If I copy and paste the URL of a page and > send it to a friend / post it to my weblog, my expectation is that > they will see exactly what I see. Likewise, if I quote something and > cite the original URL, my expectation is that I'm pointing back to > the source of that quote. Changing the content based on the language > header breaks that expectation. Again, I know it's part of the HTTP > spec - but it's so rarely implemented that very few users expect it > to happen. > > 3. Related to the above: What if I spot a typo in a page and want to > report it to the site owner? Sending them the URL is no longer enough > - I have to tell them my browser's language setting as well. > > Given the above, I much prefer the approach taken by most sites that > feature content in multiple languages where the language code is > included somewhere in the URL. > > That's not to say that the user's browser language setting should be > ignored - you can use it to inform them that the page is available in > their preferred language (maybe with a nice big note at the top of > the page, written in their native language of course). > > Tim Berners-Lee and the W3C may disagree with me on this one, but I'm > convinced that using URLs to distinguish between languages is smarter > than relying on browser settings alone. > > Cheers, > > Simon > The reasons are good enough. And I think these things are more concerned with application. Maybe someone doesn't need it I think, or current status in django is enough. If you want to implement it, I can give my opinion.Firstly it should be optional. Secondly, I also think maybe we need to resolve the apps prefix first. Because how to design the url. Just set the locale string after domain? http://domain.com/en http://domain.com/zh_CN Or permit user set it every where he want? http://domain/page/en http://domain/page/zh_CN -- I like python! My Blog: http://www.donews.net/limodou My Django Site: http://www.djangocn.org NewEdit Maillist: http://groups.google.com/group/NewEdit --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Locale from URL Middleware
Glad I am not alone :) There is a little irritation in using the middleware posted above because I obviously have to account for the language in all lines in my urls.py (r'(\w\w/)?... and so on). I would prefer for this to have the same result as using an "include" statement, ie the prefix would be cut off. Going to look into that tomorrow, if anyone knows where to look, a finger in the right direction would be well appreciated. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Locale from URL Middleware
I would like to add another good reason: Another nice effect language codes in the URL is that search engine crawlers can easily get all your content. My customers often want something like this: www.example.com -> site in the main language of your visitors www.example.nl -> site in Dutch www.example.com/nl-nl/ -> site in Dutch etc. I would highly appreciate such middleware. Rudolph --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Locale from URL Middleware
I very much agree with Simon and Jan. A middleware like this would be nice to have in django.contrib. One useful enhancement would be the ability to specify in where in the URL the language can be specified. On one of my sites the syntax of the URL is always /userid/locale/page... so it would be safest to have the middleware only accept locale codes from the second part of the URL. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Locale from URL Middleware
Op wo, 05-04-2006 te 16:34 +0100, schreef Simon Willison: > I for one much prefer the language to be specified in the URL Or sometimes using a cookie... > rather > than being derived from the browser settings. I would prefer this > behaviour to be supported (at least as an option) in Django core. I > know that language detection based on browser HTTP headers is a > feature of the HTTP specification, but personally I believe that it's > a mistake in the spec. Here's my reasoning: [snip 3 good reasons] One more reason is when you are using someone else's computer and you don't prefer the same language as the owner. (That owner might also be a "cybercafé" or such.) -- Jan Claeys --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Locale from URL Middleware
On 5 Apr 2006, at 12:26, limodou wrote: > Why you need do this? Because django can auto judge the language from > your browser request http head, or context settings, or settings. If > you like , you can provide a language selection in web page, and > that's enough. The url doesnot need to be special processed I think. I for one much prefer the language to be specified in the URL rather than being derived from the browser settings. I would prefer this behaviour to be supported (at least as an option) in Django core. I know that language detection based on browser HTTP headers is a feature of the HTTP specification, but personally I believe that it's a mistake in the spec. Here's my reasoning: 1. Serving up content from the same URL in a different language depending on browser settings is an idea that is based on the ideal situation where each translation is a perfect representation of the content's underlying meaning. This is clearly not a realistic proposition. Some languages have phrases that do not perfectly translate to other languages, and translations may not be perfect in any case due to human error. The French version of a page is fundamentally different from the English version, and I believe that the URL should reflect that. 2. Passing URLs around. If I copy and paste the URL of a page and send it to a friend / post it to my weblog, my expectation is that they will see exactly what I see. Likewise, if I quote something and cite the original URL, my expectation is that I'm pointing back to the source of that quote. Changing the content based on the language header breaks that expectation. Again, I know it's part of the HTTP spec - but it's so rarely implemented that very few users expect it to happen. 3. Related to the above: What if I spot a typo in a page and want to report it to the site owner? Sending them the URL is no longer enough - I have to tell them my browser's language setting as well. Given the above, I much prefer the approach taken by most sites that feature content in multiple languages where the language code is included somewhere in the URL. That's not to say that the user's browser language setting should be ignored - you can use it to inform them that the page is available in their preferred language (maybe with a nice big note at the top of the page, written in their native language of course). Tim Berners-Lee and the W3C may disagree with me on this one, but I'm convinced that using URLs to distinguish between languages is smarter than relying on browser settings alone. Cheers, Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Locale from URL Middleware
I understand how django does it. Unfortunately I am forced to maintain a web structure that requires this functionality so that's why I wrote it. But I actually prefer this over the ambiguity in the browser settings which most people do not set anyway and the extra step required to select the right language if someone sends you a url that ends up in the wrong language. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Locale from URL Middleware
On 4/5/06, atlithorn <[EMAIL PROTECTED]> wrote: > > Just in case anyone is interested... I wrote my own middleware class to > support selecting languages from the URL itself. eg: > > www.example.com - default english > www.example.com/de - same page with german trans > > It was a simple copy-paste of the LocaleMiddleWare from the distro: > Why you need do this? Because django can auto judge the language from your browser request http head, or context settings, or settings. If you like , you can provide a language selection in web page, and that's enough. The url doesnot need to be special processed I think. -- I like python! My Blog: http://www.donews.net/limodou My Django Site: http://www.djangocn.org NewEdit Maillist: http://groups.google.com/group/NewEdit --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
