Re: uWSGI documentation
On Sat, Apr 9, 2011 at 2:15 PM, Graham Dumpleton wrote: > To be blunt, you are actually asking a lot for them to host detailed > documentation on uWSGI integration on the Django site for every possible way > it can be setup. I haven't even managed to get much more than minimal setup > instructions for mod_wsgi into the official Django documentation. > I believe you will find that they don't really believe it is for them to be > providing extensive documentation on particular hosting mechanisms, or at > least they don't have the time. Personally I do find that stance a bit odd > as they should be striving to at least ensure that it is as painless as > possible for users to get it going on at least the mainstream hosting > methods to combat the accusations that it is too hard. As such, the minimal > documentation they provide at the moment is quite often not enough. I'm a little confused by this sentiment. Why is it Django's role to provide full documentation for mod_wsgi (or any other deployment interface, for that matter)? If people are complaining that mod_wsgi is too hard to use, why is that a failure of *Django's* documentation? Django isn't the sole arbiter of all documentation. We are in a position to document Django. We are in a position to point out the unique requirements that Django may have (for example, what needs to be in the system path and environment). We can -- and do -- link to the official documentation for mod_wsgi. At some point, the issue with deploying Django under X has less to do with Django, and more to do with the eccentricities of X. That's the point at which, IMHO, it ceases to be Django's responsibility to provide documentation. I don't think it's Django's place to document mod_wsgi any more than it's Django's place to document MySQL or SQLite. We provide the detail to explain the Django-specific friction points that exist, but beyond that, it's up to those external (to Django) libraries to provide adequate documentation for their own configurations. > To me this should extend to ensuring that interfaces in the framework make > it easy and predictable. It is a said state of affairs though that pretty > well all the Python web frameworks give minimal time to ensuring that the > experience of a user as far as hosting it is as simple as possible and why > every framework is so different and don't use some sort of common defining > mechanism for an entry point. Again, I'm confused here -- to my reading, this "common defining mechanism" is what WSGI is supposed to be. You won't get any argument out of me that Django has some quirks that makes deployment harder than it should be -- for example, the path munging problems that you've blogged about in the past. You won't get any argument out of me that these issues should be addressed. The reason we spend "minimal time" addressing these problems is that in the grand scheme of things, deployment pain is quite far down the list of problems that we have. Yes, Django has deployment quirks. Yes, this makes it harder for absolute beginners to get started. However, once you understand those quirks (as any non-beginning Django user must do), deployment simply isn't that big a problem. I completely agree that deploying Django could be *better*, but like it or not, the status quo *works*, and the 'itch' that would cause someone to address this issue is a relatively minor annoyance. On the other hand, issues like logging, handling of static files, controlling cascading behavior during deletion, i18n and l10n are problems that are real, current, and affect *every* Django user, be they novice or master. The incentive to work on these issues (and I've just picked the ones we addressed in 1.3) is much higher. If someone wants to take a swing at addressing these Django-specific deployment issues, I fully support that. However, that doesn't just mean pointing out the problems that exist -- we already know they exist. It means providing a concrete patch that fixes those problems, or at least can be used as a starting point for further discussion. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: uWSGI documentation
> To be blunt, you are actually asking a lot for them to host detailed > documentation on uWSGI integration on the Django site for every possible > way > it can be setup. I haven't even managed to get much more than minimal > setup > instructions for mod_wsgi into the official Django documentation. > > I have asked anything, other users spawned this thread, and as the main uWSGI author i am doing suggestions/corrections. -- Roberto De Ioris http://unbit.it -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: uWSGI documentation
On Saturday, April 9, 2011 5:35:14 PM UTC+10, Russell Keith-Magee wrote: > > On Sat, Apr 9, 2011 at 2:15 PM, Graham Dumpleton > wrote: > > To be blunt, you are actually asking a lot for them to host detailed > > documentation on uWSGI integration on the Django site for every possible > way > > it can be setup. I haven't even managed to get much more than minimal > setup > > instructions for mod_wsgi into the official Django documentation. > > I believe you will find that they don't really believe it is for them to > be > > providing extensive documentation on particular hosting mechanisms, or at > > least they don't have the time. Personally I do find that stance a bit > odd > > as they should be striving to at least ensure that it is as painless as > > possible for users to get it going on at least the mainstream hosting > > methods to combat the accusations that it is too hard. As such, the > minimal > > documentation they provide at the moment is quite often not enough. > > I'm a little confused by this sentiment. Why is it Django's role to > provide full documentation for mod_wsgi (or any other deployment > interface, for that matter)? > I am not saying it is and why I was stating that for uWSGI at most what they should be hoping for is to get the most minimal documentation included. I believe that they might have been going over the top in the expectations of what could be included when I started seeing some of the stuff posted especially since they were things that weren't even unique to using Django with uWSGI. > If people are complaining that mod_wsgi > is too hard to use, why is that a failure of *Django's* documentation? > I didn't specifically say that mod_wsgi in particular is too hard, it was a general statement about use of Django with any hosting mechanism. Django prides itself on having really excellent documentation but experience has shown that in the area of hosting, what documentation you provide keeps falling a bit short because of the constant questions about the issues. You even mention some of the pain points below around sys.path. Another is static media host, the differences between media and static area etc. There is also the SCRIPT_NAME issue with LOGIN_URL and LOGOUT_URL These are peculiarities to Django. If I were to remove tomorrow the Django specific integration notes from the mod_wsgi site and you didn't yourselves document these Django specific issues, then what are your users going to do. I though would be able to quite rightly say, 'well how to use mod_wsgi is documented over there, if you can't work out how to make a specific framework work because the framework doesn't explain then it isn't my problem'. In fact I have actually taken this specific stance with most of the other Python web frameworks and removed the documentation from the mod_wsgi site about them. This was in part done because some changed how to work with the frameworks between versions and it was too much to keep track of it and they couldn't be bothered to highlight the differences. It has also been because they had certain things that had to be done in certain ways with anything but their own included server and they weren't documenting it. Given that they didn't seem interested in devoting much time to the area of hosting and regarded documenting how to do it properly as not their problem, even for those things which were specific to their framework I just gave up and left it up to them. Faced with that they have started to improve the documentation but across the board the problem is still one of frameworks providing a simple example but not really going in depth into why things are done certain ways so that when things go wrong for a user that they have some clue as to why. As such, you never get rid of the questions from people about why things don't work when their setup isn't exactly as per the prototypical setup. Even though I don't use Django myself I have always paid a great deal of attention to what problems people were having and would answer questions on the Django forums, StackOverflow and mod_wsgi list even though a lot of the time they related to the Django specific issues and nothing to do with mod_wsgi itself. I would update my own Django integration documentation at least to address these issues. When I have tried to highlight problems that the Django documentation didn't perhaps explain well enough, such as sys.path and need for parent and site directories, the response has been one of 'I don't see a problem' from the list. Still though people get confused by the documentation. So, may not be confusing to an experienced user, but the newbies don't understand and that seems to be missed. So, that is my gripe, that the documentation in place isn't a bit more friendly to newbies who don't have the experience of those people who think there is no problem with the documentation. And yes I have raised these issues on the list a nu
Re: Fixing makemessages for Javascript
I've created two patches implementing this strategy, and attached them
to ticket http://code.djangoproject.com/ticket/7704.
--Ned.
On 4/4/2011 5:15 PM, 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 fully understanding the extent of
Django's current hack, I decided to take a stab at providing a better
solution.
Background: today, Javascript source files are parsed for messages by
running a "pythonize" regex over them, and giving the resulting text
to xgettext, claiming it is Perl. The pythonize regex simply changes
any //-style comment on its own line into a #-style comment. This
strange accommodation leaves a great deal of valid Javascript syntax
in place to confuse the Perl parser in xgettext. As a result,
seemingly innocuous Javascript will result in lost messages:
gettext("xyzzy 1");
var x = y;
gettext("xyzzy 2");
var x = z;
gettext("xyzzy 3");
In this sample, messages 1 and 3 are found, and message 2 is not,
because y;ABC;abc; is valid Perl for a transliteration operator.
Digging into this, every time I thought I finally understood the full
complexity of the brokenness, another case would pop up that didn't
make sense. The full horror of Perl syntax
(http://perldoc.perl.org/perlop.html#Quote-and-Quote-like-Operators ,
for example) means that it is very difficult to treat non-Perl code as
Perl and expect everything to be OK. This is polyglot programming at
its worst.
This needs to be fixed. To that end, I've written a Javascript lexer
(https://bitbucket.org/ned/jslex) with the goal of using it to
pre-process Javascript into a form more suitable for xgettext. My
understanding of why we claim Javascript is Perl is that Perl has
regex literals like Javascript does, and so xgettext stands the best
chance of parsing Javascript as Perl. Clearly that's not working
well. My solution would instead remove the regex literals from the
Javascript, and then have xgettext treat it as C.
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
reasonable to expect Django installations to use bleeding-edge
xgettext. Is there some better solution that someone is pursuing?
2. Is there some other badness that will bite us if we tell xgettext
that the modified Javascript is C? With a full Javascript lexer, I
feel pretty confident that we could solve issues if they do come up,
but I'd like to know now what they are.
3. I know that lexing Javascript is tricky. I need help finding
diabolical test cases for my lexer (https://bitbucket.org/ned/jslex).
Anyone care to come up with some Javascript source that it can't
properly find the regex literals in?
BTW: This would close tickets #7704, #14045, #15331, and #15495.
--Ned.
--
You received this message because you are subscribed to the Google
Groups "Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Error message not clear
Hi, Maybe it's a stupid issue but I think the error message is not clear or I am missing something about the dummy db.backend. Why if you set an error database backend the error message is the next one? Try using django.db.backends.XXX, where XXX is one of: 'dummy', 'mysql', 'oracle', 'postgresql', 'postgresql_psycopg2', 'sqlite3' If a user sets the dummy one it will get stucked with messages like this (and will ask help on the django-users list :P): Error: Django doesn't know which syntax to use for your SQL statements, because you haven't specified the ENGINE setting for the database. Edit your settings file and change DATBASES['default']['ENGINE'] to something like 'django.db.backends.postgresql' or 'django.db.backends.mysql'. Shouldn't the first error just tell you: Try using django.db.backends.XXX, where XXX is one of: 'mysql', 'oracle', 'postgresql', 'postgresql_psycopg2', 'sqlite3' (not dummy) Just because users (new ones) can expect that the dummy backend is a correct one. And as I've been looking onto the code it's just used when no backend is setted. Just to don't give people an incorrect message. Thanks, -- Raúl Cumplido -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Fixing makemessages for Javascript
On 09.04.2011, at 16:14, Ned Batchelder wrote:
> I've created two patches implementing this strategy, and attached them to
> ticket http://code.djangoproject.com/ticket/7704.
Thanks Ned, but I'm a bit confused, I thought we agreed that Babel should be
the way to go, since adding an own JavaScript lexer into Django would further
move us away from our goal to get rid of the dependency on xgettext.
Jannis
> On 4/4/2011 5:15 PM, 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 fully understanding the extent of Django's current hack, I
>> decided to take a stab at providing a better solution.
>>
>> Background: today, Javascript source files are parsed for messages by
>> running a "pythonize" regex over them, and giving the resulting text to
>> xgettext, claiming it is Perl. The pythonize regex simply changes any
>> //-style comment on its own line into a #-style comment. This strange
>> accommodation leaves a great deal of valid Javascript syntax in place to
>> confuse the Perl parser in xgettext. As a result, seemingly innocuous
>> Javascript will result in lost messages:
>> gettext("xyzzy 1");
>> var x = y;
>> gettext("xyzzy 2");
>> var x = z;
>> gettext("xyzzy 3");
>> In this sample, messages 1 and 3 are found, and message 2 is not, because
>> y;ABC;abc; is valid Perl for a transliteration operator. Digging into this,
>> every time I thought I finally understood the full complexity of the
>> brokenness, another case would pop up that didn't make sense. The full
>> horror of Perl syntax
>> (http://perldoc.perl.org/perlop.html#Quote-and-Quote-like-Operators , for
>> example) means that it is very difficult to treat non-Perl code as Perl and
>> expect everything to be OK. This is polyglot programming at its worst.
>>
>> This needs to be fixed. To that end, I've written a Javascript lexer
>> (https://bitbucket.org/ned/jslex) with the goal of using it to pre-process
>> Javascript into a form more suitable for xgettext. My understanding of why
>> we claim Javascript is Perl is that Perl has regex literals like Javascript
>> does, and so xgettext stands the best chance of parsing Javascript as Perl.
>> Clearly that's not working well. My solution would instead remove the regex
>> literals from the Javascript, and then have xgettext treat it as C.
>>
>> 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 reasonable to expect Django
>> installations to use bleeding-edge xgettext. Is there some better solution
>> that someone is pursuing?
>>
>> 2. Is there some other badness that will bite us if we tell xgettext that
>> the modified Javascript is C? With a full Javascript lexer, I feel pretty
>> confident that we could solve issues if they do come up, but I'd like to
>> know now what they are.
>>
>> 3. I know that lexing Javascript is tricky. I need help finding diabolical
>> test cases for my lexer (https://bitbucket.org/ned/jslex). Anyone care to
>> come up with some Javascript source that it can't properly find the regex
>> literals in?
>>
>> BTW: This would close tickets #7704, #14045, #15331, and #15495.
>>
>> --Ned.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-developers@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Fixing makemessages for Javascript
On 4/9/2011 10:43 AM, Jannis Leidel wrote: On 09.04.2011, at 16:14, Ned Batchelder wrote: I've created two patches implementing this strategy, and attached them to ticket http://code.djangoproject.com/ticket/7704. Thanks Ned, but I'm a bit confused, I thought we agreed that Babel should be the way to go, since adding an own JavaScript lexer into Django would further move us away from our goal to get rid of the dependency on xgettext. Jannis I understood that a few people including you expressed a preference for integrating Babel. But I don't see any motion toward doing it, and it brings its own questions, such as the relationship between Django and Babel. Forgive me if I'm wrong, but it seemed like switching from xgettext to Babel was not a simple proposition, and had its detractors. For example, could we switch to Babel for 1.3.1? I'd very much like to have this headache gone as soon as possible. The lexer I've attached to the ticket works well, at least I'd like to hear from someone who believes it doesn't. I understand the desire to move away from xgettext, but it doesn't seem to be happening. No one had claimed the three open tickets about this problem, for instance. I apologize if I'm being brash or impatient here. What's the right way forward? --Ned. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Fixing makemessages for Javascript
On 05.04.2011, at 13:39, Ned Batchelder wrote:
> Jannis and Łukasz have both suggested the same thing: use Babel instead of
> xgettext. I understand why: it's a more complete solution than what I have
> proposed, which is at heart still a way to trick xgettext into parsing source
> code it doesn't natively understand.
>
> I have no experience with Babel, so I don't know what work lies ahead to
> integrate it with Django. I have used my code in makemessages, and it works
> well.
>
> Questions now include:
>
> 1) What can we get done in 1.3.1? Is integrating Babel something that would
> have to wait for 1.4?
Both, your lexel as well as Babel adoption would have to wait for 1.4.
> 2) Who is the best expert on Babel and Django that could comment on the work
> needed?
I talked to Armin Ronacher who both knows Django and Babel reasonable well,
being one of the developers of the latter.
> 3) Are there other opinions about the two paths forward? Are there other
> options?
Not as far as I can see.
> I would like very much to get this problem solved.
>
> --Ned.
>
> On 4/4/2011 6:42 PM, Jannis Leidel wrote:
>> 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 fully understanding the extent of Django's current
>>> hack, I decided to take a stab at providing a better solution.
>>>
>>> Background: today, Javascript source files are parsed for messages by
>>> running a "pythonize" regex over them, and giving the resulting text to
>>> xgettext, claiming it is Perl. The pythonize regex simply changes any
>>> //-style comment on its own line into a #-style comment. This strange
>>> accommodation leaves a great deal of valid Javascript syntax in place to
>>> confuse the Perl parser in xgettext. As a result, seemingly innocuous
>>> Javascript will result in lost messages:
>>> gettext("xyzzy 1");
>>> var x = y;
>>> gettext("xyzzy 2");
>>> var x = z;
>>> gettext("xyzzy 3");
>>> In this sample, messages 1 and 3 are found, and message 2 is not, because
>>> y;ABC;abc; is valid Perl for a transliteration operator. Digging into
>>> this, every time I thought I finally understood the full complexity of the
>>> brokenness, another case would pop up that didn't make sense. The full
>>> horror of Perl syntax
>>> (http://perldoc.perl.org/perlop.html#Quote-and-Quote-like-Operators , for
>>> example) means that it is very difficult to treat non-Perl code as Perl and
>>> expect everything to be OK. This is polyglot programming at its worst.
>>>
>>> This needs to be fixed. To that end, I've written a Javascript lexer
>>> (https://bitbucket.org/ned/jslex) with the goal of using it to pre-process
>>> Javascript into a form more suitable for xgettext. My understanding of why
>>> we claim Javascript is Perl is that Perl has regex literals like Javascript
>>> does, and so xgettext stands the best chance of parsing Javascript as Perl.
>>> Clearly that's not working well. My solution would instead remove the
>>> regex literals from the Javascript, and then have xgettext treat it as C.
>> Thanks Ned, I meant the post about this issue here after 1.3, since we also
>> talked about this during the Pycon sprint, especially since we seem to have
>> hit a few more problems with the recent gettext 0.18.1.1 (such as a
>> seemingly stricter Perl lexer) -- which I encountered while I applied the
>> final translation updates right before 1.3 but didn't have time to
>> investigate yet. The bottom line is that I think we should rethink the way
>> we look for translateable strings instead of working around the limitations
>> of xgettext.
>>
>>> 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
>>> reasonable to expect Django installations to use bleeding-edge xgettext.
>>> Is there some better solution that someone is pursuing?
>> We can't really expect Django users to upgrade to the most recent (or even
>> an unreleased) version of gettext, We've bumped the minimum required version
>> in Django 1.2 to 0.15 once all OSes were covered with installers. Which made
>> me talk to Armin Ronacher about using Babel instead of GNU gettext, since it
>> has a JavaScript lexer and is in use in Sphinx and Trac. [1] In that sense,
>> I wholeheartedly encourage you to take a stab at it for 1.4 -- if you think
>> that's a good idea.
>>
>> Having a Python based library (assuming it works similarly) seems like a
>> better fit to Django than relying on a C program.
>>
>>> 2. Is there some other badness that will bite us if we tell xgettext that
>>> the modified Javascript is C? With a full
Re: Fixing makemessages for Javascript
On 09.04.2011, at 17:32, Ned Batchelder wrote: > On 4/9/2011 10:43 AM, Jannis Leidel wrote: >> On 09.04.2011, at 16:14, Ned Batchelder wrote: >> >>> I've created two patches implementing this strategy, and attached them to >>> ticket http://code.djangoproject.com/ticket/7704. >> Thanks Ned, but I'm a bit confused, I thought we agreed that Babel should be >> the way to go, since adding an own JavaScript lexer into Django would >> further move us away from our goal to get rid of the dependency on xgettext. >> >> Jannis > I understood that a few people including you expressed a preference for > integrating Babel. But I don't see any motion toward doing it, and it brings > its own questions, such as the relationship between Django and Babel. > Forgive me if I'm wrong, but it seemed like switching from xgettext to Babel > was not a simple proposition, and had its detractors. We've just been out with 1.3 for a few weeks, so there is no big surprise we haven't produced any substancial patches for moving away from xgettext. But that doesn't mean that I (and it seems a few others) haven't researched the bits needed to make it happen. As for the "detractors", I'm not even sure what you mean by that. > For example, could we switch to Babel for 1.3.1? I'd very much like to have > this headache gone as soon as possible. The lexer I've attached to the > ticket works well, at least I'd like to hear from someone who believes it > doesn't. No, Babel can't be adopted in the 1.3.X release branch, just like your JavaScript lexer. > I understand the desire to move away from xgettext, but it doesn't seem to be > happening. No one had claimed the three open tickets about this problem, for > instance. How can you say it's not happening? I clearly made a statement about my committement for Babel adoption in the current release cycle. Jannis -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Fixing makemessages for Javascript
On 4/9/2011 11:57 AM, Jannis Leidel wrote: On 09.04.2011, at 17:32, Ned Batchelder wrote: On 4/9/2011 10:43 AM, Jannis Leidel wrote: On 09.04.2011, at 16:14, Ned Batchelder wrote: I've created two patches implementing this strategy, and attached them to ticket http://code.djangoproject.com/ticket/7704. Thanks Ned, but I'm a bit confused, I thought we agreed that Babel should be the way to go, since adding an own JavaScript lexer into Django would further move us away from our goal to get rid of the dependency on xgettext. Jannis I understood that a few people including you expressed a preference for integrating Babel. But I don't see any motion toward doing it, and it brings its own questions, such as the relationship between Django and Babel. Forgive me if I'm wrong, but it seemed like switching from xgettext to Babel was not a simple proposition, and had its detractors. We've just been out with 1.3 for a few weeks, so there is no big surprise we haven't produced any substancial patches for moving away from xgettext. But that doesn't mean that I (and it seems a few others) haven't researched the bits needed to make it happen. As for the "detractors", I'm not even sure what you mean by that. I thought I had read some issues about integrating Babel, but I can't find them now. It must have been a figment of my lexer-fevered brain, my mistake. What are the bits needed to make it happen? For example, could we switch to Babel for 1.3.1? I'd very much like to have this headache gone as soon as possible. The lexer I've attached to the ticket works well, at least I'd like to hear from someone who believes it doesn't. No, Babel can't be adopted in the 1.3.X release branch, just like your JavaScript lexer. Even if Babel is the solution for 1.4, I don't understand why my patch can't be applied to 1.3.x? It's well tested, and clearly works better than the code in 1.3 now. It's transparent to the user, except it isn't baffling like today's code. From my point of view, makemessages simply doesn't work for Javascript files. It's a frustrating process that usually ends with twisting your Javascript sources to meet the needs of a Perl parser, but without understanding that that's what you're doing. I understand the desire to move away from xgettext, but it doesn't seem to be happening. No one had claimed the three open tickets about this problem, for instance. How can you say it's not happening? I clearly made a statement about my committement for Babel adoption in the current release cycle. I was basing that on the fact that the tickets weren't claimed. Again, I don't mean to antagonize anyone, I just want this to be fixed. --Ned. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
