On 04.04.2011, at 23:15, Ned Batchelder wrote:
> Last week I re-encountered the problems with using makemessages on Javascript
> files, and lost a couple of half-days to trying to figure out why some of my
> translatable messages weren't being found and deposited into my .po files.
> After ful
On 4/4/2011 5:45 PM, Łukasz Rekucki wrote:
On 4 April 2011 23:15, Ned Batchelder wrote:
I have a few questions you can help me with:
1. Is this the best path forward? Ideally xgettext would support Javascript
directly. There's code out there to add Javascript to xgettext, but I don't
know wha
On 4 April 2011 23:15, Ned Batchelder wrote:
>
> I have a few questions you can help me with:
>
> 1. Is this the best path forward? Ideally xgettext would support Javascript
> directly. There's code out there to add Javascript to xgettext, but I don't
> know what shape that code is in, or if it's
Last week I re-encountered the problems with using makemessages on
Javascript files, and lost a couple of half-days to trying to figure out
why some of my translatable messages weren't being found and deposited
into my .po files. After fully understanding the extent of Django's
current hack, I
On Sun, Apr 03, 2011 at 03:08:51PM -0400, Alex Gaynor wrote:
> Like Carl I haven't had time to properly read this, but one important thing
> (IMO) to think about is not just having composite field support, but support
> for "virtual" fields in general, that is fields that don't map to a database
>
Hi Mikołaj,
On 4 April 2011 19:46, trybik wrote:
> Omg, I've just reviewed this bug, it's still there but this message is
> completely confusing. A little correction:
It's best to report bugs on the tracker. Otherwise, they'll die in
infinite depths of everyone's mailboxes.
>
> On 25 Lut, 14:14
Omg, I've just reviewed this bug, it's still there but this message is
completely confusing. A little correction:
On 25 Lut, 14:14, trybik wrote:
> Hi,
>
> when generating sql forWhereNoderepresented as (AND:
> (EverythingNode)),
> inhttp://code.djangoproject.com/browser/django/trunk/django/db/m
2011/4/4 Daniel Greenfeld :
> Anyway, as the current lead on Django Uni-Form I think its great that Gregor
> is picking up the torch for refactoring form rendering in Django 1.40. He's
> obviously done his homework and put a lot of thought into this critical part
> of Django.
> I'm not a core devel
> Hi,
> How uwsgi is more secure than FastCGI ?
I think he is referring to the various included jailing systems (chroot,
linux namespaces, posix capabilities...) because if we are talking about
protocols there are no really differences between uwsgi and FastCGI, both
are unsecure by-design :)
Hi,
How uwsgi is more secure than FastCGI ?
I believe that running manage.py for production deployments is "not
way to go", as it has been noted by django devs previously.
What purpose would runuwsgi command serve ?
On Sat, Apr 2, 2011 at 2:23 PM, James Pic wrote:
> Hello everybody,
>
> Do
On Apr 2, 1:23 pm, James Pic wrote:
> I think it should because it's easier, safer, faster and more secure
> than flup or mod_wsgi. Also, it made my sysadmin life really easy and
> that's something cool to share with the community.
+1 on more docs, since uwsgi is quite useable by now. But pleas
On Sun, Apr 03, 2011 at 02:52:01PM -0400, Carl Meyer wrote:
> I haven't had time yet to sit down and look at your implementation
> questions for a CompositeField (how it works with lookups and Qs, etc),
> but I do think that one design goal for a CompositeField implementation
> is that we should be
Il giorno 02/apr/2011, alle ore 16.44, Łukasz Rekucki ha scritto:
> On 2 April 2011 13:23, James Pic wrote:
>> Hello everybody,
>>
>> Do you think uWSGI deserves a place in the official django documentation ?
>>
>> I think it should because it's easier, safer, faster and more secure
>> than fl
13 matches
Mail list logo
