Luke Plant wrote:
This is important:
http://www.w3.org/2001/tag/doc/whenToUseGet-20030709.html#i18n
There is a note in that text saying that when encoding is unknown
browsers may use the encoding that was used for outputting the form.
Which they really do.
But as I understod Hugo's note
On Wed, 11 Jan 2006 00:12:02 +0300 Maniac wrote:
> It mentions that HTTPResponse should do unicode -> DEFAULT_ENCODING.
> I think that HTTPRequest should do backward translation. Or am I
> missing something why it shouldn't?
This is important:
http://www.w3.org/2001/tag/doc/whenToUseGet-2003070
On 1/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> 1132 and 1164 both provides solutions for the CurrentUser issue), but
> as
> of now, these solutions have been (in my own opinion rightly) deemed
> too
> hackish to get committed. This thread is aimed at finding a clean
> implementation
Hi folks,
Yes, I'm bringing this issue again, please don't throw things at me !
Basically, I would want to open a discussion on these subjects so as to
define a clean solution to this problem, if at least possible.
I think I'm gonna give some use cases that should, in my very humble
opinion, be
# http://www.openidenable.com
This should be:
http://www.openidenabled.com
--
Jonathan Daugherty
http://www.parsed.org
>It mentions that HTTPResponse should do unicode -> DEFAULT_ENCODING. I
>think that HTTPRequest should do backward translation. Or am I missing
>something why it shouldn't?
Absolutely correct. That's why I asked others to join in, because I am
bound to have forgotten some parts ;-)
I added that
Amit Upadhyay wrote:
> This makes clear on what to do incase there are different subdomains, we
> can just add other subdomains specific setting files blog_settings.py
> and so on, which point to different ROOT_URLCONF and so on [we can
> overwrite other things too if required].
Look at http://c
hugo wrote:
http://code.djangoproject.com/wiki/UnicodeInDjango
It mentions that HTTPResponse should do unicode -> DEFAULT_ENCODING. I
think that HTTPRequest should do backward translation. Or am I missing
something why it shouldn't?
>I think that Django should support(use only) python unicode strings.
Since the work needed would be a bit involved (not the actual work, I
think, but finding and fixing all relevant places), I set up a wiki
page to collect places and procedures regarding unicodefication.
I think that Django sho
On 1/10/06, Antonio Cavedoni <[EMAIL PROTECTED]> wrote:
>
> Maybe we could start a "unicode" branch right after "magic-removal"
> is merged back into the trunk?
+1 to that; I'd rather not see magic-removal last forever as a
"catch-all", diverging further and further from trunk. :-)
On 10 Jan 2006, at 21:24, hugo wrote:
The patch to #914 is just sitting there because there is no comment
from the core devs on it - but I think we should do either the
unicodefication or the patch from #914, with my preference being the
unicodefication.
I’m +1 on the full unicodefication and
>unicodefication or the patch from #914, with my preference being the
924, that is ...
bye, Georg
>You mean total unicodization? As far as I understand it's not
>incompatibilities that hold this change but complexity. The problem is
>not localized to just templates filters it would be the change across
>entire code.
Yep, it would be just a pain to do - loads of places need changing, all
str()
Ivan Fedorov wrote:
I think now is good time to do this work. We already have many backward
incompatibitilies in magic-removal branch. So I'm think that we can add
one more.
You mean total unicodization? As far as I understand it's not
incompatibilities that hold this change but complexity.
Fair enough. Somebody had to resist being a +1 sheep :-)
Maniac пишет:
>
> Ivan Fedorov wrote:
>
>> I think that Django should support(use only) python unicode strings.
>>
>> For example, at this time django can't capitalize russian strings, when
>> site charset is utf-8...
>>
>>
> There is a patch fixing this bug in
> http://code.djangoproject.com/
Ivan Fedorov wrote:
I think that Django should support(use only) python unicode strings.
For example, at this time django can't capitalize russian strings, when
site charset is utf-8...
There is a patch fixing this bug in
http://code.djangoproject.com/ticket/924 waiting for... something? :
I think that Django should support(use only) python unicode strings.
For example, at this time django can't capitalize russian strings, when
site charset is utf-8...
On 12/8/05, Pedro Furtado <[EMAIL PROTECTED]> wrote:
> > And I think that the DATABASE_ENGINE setting should be set to empty
> > string "" in settings.py by default, so it can detect if it hasn't
> > been properly set up.
>
> +1 here. I presume it will fix this minor bug and this way won't
> privi
19 matches
Mail list logo
