Re: i18n/setlang no longer support GET
Hello, I wrote an my blog about the solution I have chosen perform what is describes. To put it in a nutshell I am using a middleware to direct the user to the language requested in the URL. I am not sure this follow any "Best Practice": http://yml-blog.blogspot.com/2007/12/django-internationalisation.html May be this could help you. --yml On 20 déc, 00:32, "James Bennett" <[EMAIL PROTECTED]> wrote: > On Dec 19, 2007 12:59 PM, Poromenos <[EMAIL PROTECTED]> wrote: > > > My application's UI depends on the set_language view being a link, and > > I don't think it should be up to the framework to force this on the > > developer. It would be better if the view supported both ways and the > > developer could choose whether they wanted functionality or spec > > compliance. This isn't a simple change, and it shouldn't be decided > > just like that... > > So write your own view which uses GET. Django encourages best > practices, and that includes following the recommendations of the HTTP > specification. You are free to throw down and trample the spec as much > as you like in your own code, but don't expect Django to help you with > it. > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: i18n/setlang no longer support GET
On Dec 19, 2007 12:59 PM, Poromenos <[EMAIL PROTECTED]> wrote: > My application's UI depends on the set_language view being a link, and > I don't think it should be up to the framework to force this on the > developer. It would be better if the view supported both ways and the > developer could choose whether they wanted functionality or spec > compliance. This isn't a simple change, and it shouldn't be decided > just like that... So write your own view which uses GET. Django encourages best practices, and that includes following the recommendations of the HTTP specification. You are free to throw down and trample the spec as much as you like in your own code, but don't expect Django to help you with it. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: i18n/setlang no longer support GET
2007/12/19, Poromenos <[EMAIL PROTECTED]>: > > I mistakenly replied to James instead of everyone, so I will rewrite > my reply. > > My application's UI depends on the set_language view being a link, and > I don't think it should be up to the framework to force this on the > developer. It would be better if the view supported both ways and the > developer could choose whether they wanted functionality or spec > compliance. This isn't a simple change, and it shouldn't be decided > just like that... Same as I. It's easy to solve, but it's quite annoying the first time. -- Antoni Aloy López Binissalem - Mallorca http://www.trespams.com Soci de Bulma - http://www.bulma.cat --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: i18n/setlang no longer support GET
I mistakenly replied to James instead of everyone, so I will rewrite
my reply.
My application's UI depends on the set_language view being a link, and
I don't think it should be up to the framework to force this on the
developer. It would be better if the view supported both ways and the
developer could choose whether they wanted functionality or spec
compliance. This isn't a simple change, and it shouldn't be decided
just like that...
On Oct 27, 1:32 am, Marc Garcia <[EMAIL PROTECTED]> wrote:
> That's not a big problem, you can just do something like that:
>
> #language {
> background-color: transparent;
> border-style: none;
> cursor: pointer;
>
> }
>
>
>
>
>
>
>
>
> That have too few lines than a link, but follows standards, is
> probably clearer, ans looks exactly the same way.
>
> See you!
> Marc Garcia
> http://vaig.be/category/it/applications/django/
>
> On Sep 26, 7:39 pm, "Antoni Aloy" <[EMAIL PROTECTED]> wrote:
>
>
>
> > 2007/9/21, James Bennett <[EMAIL PROTECTED]>:
>
> > > The HTTP specification says that GET requests should not take any
> > > action other than retrieving a resource; in other words, a GET request
> > > which modifies state on the server or has other side effects should
> > > not be allowed.
>
> > That's true, but this makes i18n/setlangunworth for usual
> > applications, so I would prefer to have the option to be a bad boy and
> > use the GET request.
> > --
> > Antoni Aloy López
> > Binissalem - Mallorcahttp://www.trespams.com
> > Soci de Bulma -http://www.bulma.cat
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: i18n/setlang no longer support GET
That's not a big problem, you can just do something like that:
#language {
background-color: transparent;
border-style: none;
cursor: pointer;
}
That have too few lines than a link, but follows standards, is
probably clearer, ans looks exactly the same way.
See you!
Marc Garcia
http://vaig.be/category/it/applications/django/
On Sep 26, 7:39 pm, "Antoni Aloy" <[EMAIL PROTECTED]> wrote:
> 2007/9/21, James Bennett <[EMAIL PROTECTED]>:
>
> > The HTTP specification says that GET requests should not take any
> > action other than retrieving a resource; in other words, a GET request
> > which modifies state on the server or has other side effects should
> > not be allowed.
>
> That's true, but this makes i18n/setlangunworth for usual
> applications, so I would prefer to have the option to be a bad boy and
> use the GET request.
> --
> Antoni Aloy López
> Binissalem - Mallorcahttp://www.trespams.com
> Soci de Bulma -http://www.bulma.cat
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: i18n/setlang no longer support GET
2007/9/21, James Bennett <[EMAIL PROTECTED]>: > The HTTP specification says that GET requests should not take any > action other than retrieving a resource; in other words, a GET request > which modifies state on the server or has other side effects should > not be allowed. That's true, but this makes i18n/setlang unworth for usual applications, so I would prefer to have the option to be a bad boy and use the GET request. -- Antoni Aloy López Binissalem - Mallorca http://www.trespams.com Soci de Bulma - http://www.bulma.cat --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: i18n/setlang no longer support GET
On 9/20/07, Arnold Chen <[EMAIL PROTECTED]> wrote: > I don't know why the developers change like that, and if there any one > can, please tell me the consequences of using GET (by modifying the > set_language function by myself) The HTTP specification says that GET requests should not take any action other than retrieving a resource; in other words, a GET request which modifies state on the server or has other side effects should not be allowed. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: i18n/setlang no longer support GET
I had more or less the same situation to solve and I think http://www.djangosnippets.org/snippets/371/ should come quite close :-) 2007/9/21, erik <[EMAIL PROTECTED]>: > > > Me, too, I stumbled over this change lately. > > My understanding of the HTTP spec is that there shouldn't be > different content for a given URL without having to use a POST > request. The solution for our problem (having links to switch > languages) might be to use unique URLs for each translation, like > > /en/startpage/ > /zh-cn/startpage/ > > I didn't think about the required i18n-logic to have this automated, > so in the meantime I just use the old set_language funtionality in a > custom function. > > best > -- erik > > > > --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: i18n/setlang no longer support GET
Me, too, I stumbled over this change lately. My understanding of the HTTP spec is that there shouldn't be different content for a given URL without having to use a POST request. The solution for our problem (having links to switch languages) might be to use unique URLs for each translation, like /en/startpage/ /zh-cn/startpage/ I didn't think about the required i18n-logic to have this automated, so in the meantime I just use the old set_language funtionality in a custom function. best -- erik --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
