Re: Fixing makemessages for Javascript

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

Re: Fixing makemessages for Javascript

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

Re: Fixing makemessages for Javascript

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

Fixing makemessages for Javascript

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,

Re: [GSoC] Composite fields

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 >

Re: Bug when generating sql for single (AND: (EverythingNode))

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

Re: Bug when generating sql for single (AND: (EverythingNode))

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)), >

Re: [GSoC] Revised form rendering

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. >

Re: uWSGI documentation

> 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 :)

Re: uWSGI documentation

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: >

Re: uWSGI documentation

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

Re: [GSoC] Composite fields

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

Re: uWSGI documentation

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