hugo wrote:
Looks like a typo: DEFAULT_ENCODING there is actually DEFAULT_CHARSET?
Yep. Fixed it. But you could have fixed that yourself, it's a wiki ;-)
Will do next time. I didn't have much experience with public wikis and
thought I need some special authorisation to correct someth
>Looks like a typo: DEFAULT_ENCODING there is actually DEFAULT_CHARSET?
Yep. Fixed it. But you could have fixed that yourself, it's a wiki ;-)
bye, Georg
hugo wrote:
I think that Django should support(use only) python unicode strings.
http://code.djangoproject.com/wiki/UnicodeInDjango
Looks like a typo: DEFAULT_ENCODING there is actually DEFAULT_CHARSET?
On 12 Jan 2006, at 14:44, Simon Willison wrote:
http://www.flickr.com/services/api/misc.encoding.html
ROTFL!
Could you make that text a bit bigger? I’m not sure which encoding is
expected by the Flickr API :-p
--
Antonio
Antonio Cavedoni пишет:
>> 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 a
On 10 Jan 2006, at 20:35, Antonio Cavedoni wrote:
Maybe we could start a “unicode” branch right after “magic-removal”
is merged back into the trunk?
+1, sounds smart.
I've been bitten by unicode problems a bunch of times while using
Django and I'm not even trying to build an internationa
>i understand the general unicode-related problems with python, i just
>wanted to understand what's django specific.
Since Django is written in Python, those _are_ django specific. For
example several of the template filters make use of uppercase/lowercase
conversions (only interesting if you can
hugo wrote:
i understand that django's architecture should use unicode because it's
the better way, but from the "outside"... what functionality is not
working fine with non-english characters?
currently you are up to your own to turn the
unicode strings returned from those into utf-8 bytest
>i understand that django's architecture should use unicode because it's
>the better way, but from the "outside"... what functionality is not
>working fine with non-english characters?
There are loads of things that don't work - actually anything that has
a notion of a character but get's fed wit
hugo wrote:
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
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
>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
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.
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...
23 matches
Mail list logo
