>I also think that utf-8 should be the standard file
>encoding for every language translation file.
Don't worry. Just stick to what you are comfortable with, gettext will
take care of it. No need to change anything.
bye, Georg
Hi,
I already started the french translation and I used the given file sample
(iso-8859 encoding). I also think that utf-8 should be the standard file
encoding for every language translation file.
What do you think about it Georg ??
Le Samedi 5 Novembre 2005 00:14, Steven Armstrong a écrit :
>For example the german translations are encoded as iso-8859-1.
>I'm not sure, but guess that this may cause some headaches when serving
>content as utf-8. Or does the gettext library handle this some way?
gettext indeed handles that transparently. So there is no need to use
only one encoding for
On 11/04/05 06:13, Jacob Kaplan-Moss wrote:
Howdy --
I've merged the i18n branch into the trunk; major thanks are due to
hugo! I'm running it live on all the LJW sites and it works fine,
but there could be some lurking issues, so caveat programmer. Adrian
will have a blog post on the ma
On 11/4/05, Brant Harris <[EMAIL PROTECTED]> wrote:
> Half way through ticket #603
> (http://code.djangoproject.com/ticket/603/) Robert brings up a topic
> of much interest to me, which is the templates and their compilation.
>
> The templates currently go through a seemingly needless two-step
> p
Arrgh, I think I had a caching problem. I take it back. Everything
seems to work fine now.
Sorry,
Morten
Hi,
Updating my django source seems to have broken the django admin app. I
get this error: http://django.pastebin.com/417624, saying "i18n is not
a valid tag library.
Any clues as to how to get things working again?
Thanks,
Morten
Half way through ticket #603
(http://code.djangoproject.com/ticket/603/) Robert brings up a topic
of much interest to me, which is the templates and their compilation.
The templates currently go through a seemingly needless two-step
process: compilation and rendering. It seems like the point wou
> This should definitely be clarified in the documentation. Actually I
> think it might even make sense to have an additional setting where you
> give an explicit order of middleware to use in the response phase -
> that way you could even have different order in request and response
> phase. Wou
>I realised that in google's interface, this post is buried several
>pages down, so I'm reposting it as a new thread.
I already answered in that other thread (just before you posted this
;-) ) and opened ticket #730 with the idea of explicit response
middleware ordering.
bye, Georg
>Am I missing something? This makes quite a big difference, since you
>could end up serving private data to the wrong person if you get it
>wrong.
No, I think you got it right. The reverse order of middleware in the
response phase does make sense, but it is a bit counter-intuitive at
some times
I was taking about case #2.
Cheers
Ian.
On 11/4/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Ian,
>
> > by doing this you would disable/stop post's coming from via
> > javascript/ajax method.
> > it wouldn't be able to access the tokens required, or at the very
> > least it would require
Ian,
> by doing this you would disable/stop post's coming from via
> javascript/ajax method.
> it wouldn't be able to access the tokens required, or at the very
> least it would require a form tag to be someone on the HTML page which
> is generating the post (which might not be the case)
I'm not
13 matches
Mail list logo
