FWIW: we are successfully using Ned's fix on top of 1.2.5 today. -peter
--
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
On 6/3/2011 12:26 PM, Jannis Leidel wrote:
On 03.06.2011, at 04:15, Ned Batchelder wrote:
On 5/29/2011 5:40 AM, Jannis Leidel wrote:
On 15.04.2011, at 15:25, Ned Batchelder wrote:
Hi Ned,
As you say, Jannis has suggested that a Babel-based solution isn't that much
work. But that work hasn
On 03.06.2011, at 04:15, Ned Batchelder wrote:
> On 5/29/2011 5:40 AM, Jannis Leidel wrote:
>> On 15.04.2011, at 15:25, Ned Batchelder wrote:
>>
>> Hi Ned,
>>
>>> As you say, Jannis has suggested that a Babel-based solution isn't that
>>> much work. But that work hasn't been done yet. I don'
On 5/29/2011 5:40 AM, Jannis Leidel wrote:
On 15.04.2011, at 15:25, Ned Batchelder wrote:
Hi Ned,
As you say, Jannis has suggested that a Babel-based solution isn't that much
work. But that work hasn't been done yet. I don't know how much work it is.
It's going to be a larger change to th
On 15.04.2011, at 15:25, Ned Batchelder wrote:
Hi Ned,
> As you say, Jannis has suggested that a Babel-based solution isn't that much
> work. But that work hasn't been done yet. I don't know how much work it is.
> It's going to be a larger change to the code base than my patch is, at least
On Thursday, April 14, 2011 12:30:56 PM UTC-4, Jannis Leidel wrote:
>
> On 14.04.2011, at 17:27, Jacob Kaplan-Moss wrote:
>
> > I think I agree with Ned here: I can't see the downside to fixing it
> > on the release branch. "It violates our policy" doesn't count IMO:
> > it's *our* policy, and we g
Hi Lukasz,
It does not yet generate .po files. While I haven't yet had any plans
for doing this, it's not really complex at all to make this possible
through the preprocessor.
What is currently does, is parsing and processing templates and
external css/js files. It does a lot of optimizations in
On 19 April 2011 15:35, Jonathan Slenders wrote:
>
> Basically, when this works, the i18n catalog for javascript is no
> longer required, even for external files.
> https://github.com/citylive/django-template-preprocessor
>
Could you elaborate on that ? How does your application help me handle
cl
A related question.
How should we thread escape characters when the msgid is generated?
Is the escaping backslash assumed to be part of the translation?
And is this behaviour consistent between Babel and the current parser?
gettext("xy\"zzy 3");
In my opinion, we should completely unescape t
On 4/15/2011 12:40 PM, Russell Keith-Magee wrote:
On Fri, Apr 15, 2011 at 9:25 PM, Ned Batchelder wrote:
On 4/14/2011 11:40 PM, Russell Keith-Magee wrote:
Keep in mind that the proposal is not to include Babel, but to depend on it
as a prerequisite, which means we are stuck in the same situa
On Fri, Apr 15, 2011 at 9:25 PM, Ned Batchelder wrote:
> On 4/14/2011 11:40 PM, Russell Keith-Magee wrote:
>>
>> No offense intended to Ned, but I simply don't see sufficient evidence
>> to be confident that this is the case. 216 lines of tests doesn't
>> strike me as anything close to a broad eno
On 4/14/2011 11:40 PM, Russell Keith-Magee wrote:
On Fri, Apr 15, 2011 at 12:30 AM, Jannis Leidel wrote:
On 14.04.2011, at 17:27, Jacob Kaplan-Moss wrote:
I think I agree with Ned here: I can't see the downside to fixing it
on the release branch. "It violates our policy" doesn't count IMO:
it
On Fri, Apr 15, 2011 at 12:30 AM, Jannis Leidel wrote:
> On 14.04.2011, at 17:27, Jacob Kaplan-Moss wrote:
>
>> I think I agree with Ned here: I can't see the downside to fixing it
>> on the release branch. "It violates our policy" doesn't count IMO:
>> it's *our* policy, and we get to break it if
Ok, I created a ticket to track the Babel integration:
http://code.djangoproject.com/ticket/15832
On 14 April 2011 21:47, Jannis Leidel wrote:
>
> I'm not convinced it's much more work, since we really only need to
> replace the string extraction code in makemessages and the
> compilation code in
On 14.04.2011, at 20:09, Łukasz Rekucki wrote:
> On 14 April 2011 18:30, Jannis Leidel wrote:
>> On 14.04.2011, at 17:27, Jacob Kaplan-Moss wrote:
>>
>>> I think I agree with Ned here: I can't see the downside to fixing it
>>> on the release branch. "It violates our policy" doesn't count IMO:
>>
On 14 April 2011 18:30, Jannis Leidel wrote:
> On 14.04.2011, at 17:27, Jacob Kaplan-Moss wrote:
>
>> I think I agree with Ned here: I can't see the downside to fixing it
>> on the release branch. "It violates our policy" doesn't count IMO:
>> it's *our* policy, and we get to break it if there's a
On 14.04.2011, at 17:27, Jacob Kaplan-Moss wrote:
> I think I agree with Ned here: I can't see the downside to fixing it
> on the release branch. "It violates our policy" doesn't count IMO:
> it's *our* policy, and we get to break it if there's a good reason.
> Making translation in JavaScript wor
Hey all --
I think I agree with Ned here: I can't see the downside to fixing it
on the release branch. "It violates our policy" doesn't count IMO:
it's *our* policy, and we get to break it if there's a good reason.
Making translation in JavaScript work is a good reason as I see it.
Jannis: can yo
On 4/14/2011 10:30 AM, Jannis Leidel wrote:
On 14.04.2011, at 15:54, Ned Batchelder wrote:
On 4/14/2011 9:26 AM, Jannis Leidel wrote:
On 14.04.2011, at 14:41, Ned Batchelder wrote:
Does anyone else have any opinions on a direction forward to fix this problem?
At the very least I'd like to
On 14.04.2011, at 15:54, Ned Batchelder wrote:
> On 4/14/2011 9:26 AM, Jannis Leidel wrote:
>> On 14.04.2011, at 14:41, Ned Batchelder wrote:
>>
>>> Does anyone else have any opinions on a direction forward to fix this
>>> problem? At the very least I'd like to make a doc patch for 1.3.1 that
On 4/14/2011 9:26 AM, Jannis Leidel wrote:
On 14.04.2011, at 14:41, Ned Batchelder wrote:
Does anyone else have any opinions on a direction forward to fix this problem?
At the very least I'd like to make a doc patch for 1.3.1 that explains the
fragility.
Yeah, a doc patch sounds like a go
On 14.04.2011, at 14:41, Ned Batchelder wrote:
> Does anyone else have any opinions on a direction forward to fix this
> problem? At the very least I'd like to make a doc patch for 1.3.1 that
> explains the fragility.
Yeah, a doc patch sounds like a good plan.
Jannis
--
You received this me
On 14.04.2011, at 15:01, Łukasz Rekucki wrote:
> On 14 April 2011 14:41, Ned Batchelder wrote:
>> Does anyone else have any opinions on a direction forward to fix this
>> problem? At the very least I'd like to make a doc patch for 1.3.1 that
>> explains the fragility.
>
> I'm +1 on fixing it no
+1 from the Tabblo group remnants.
On Thu, Apr 14, 2011 at 8:41 AM, Ned Batchelder wrote:
> Does anyone else have any opinions on a direction forward to fix this
> problem? At the very least I'd like to make a doc patch for 1.3.1 that
> explains the fragility.
>
>
--
You received this message
On 14 April 2011 14:41, Ned Batchelder wrote:
> Does anyone else have any opinions on a direction forward to fix this
> problem? At the very least I'd like to make a doc patch for 1.3.1 that
> explains the fragility.
I'm +1 on fixing it now, rather then later. The regex approach was a
bad idea i
Does anyone else have any opinions on a direction forward to fix this
problem? At the very least I'd like to make a doc patch for 1.3.1 that
explains the fragility.
--Ned.
On 4/9/2011 1:02 PM, Ned Batchelder wrote:
On 4/9/2011 11:57 AM, Jannis Leidel wrote:
On 09.04.2011, at 17:32, Ned Batc
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/
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
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 doe
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
t
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 JavaScr
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 t
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 Bab
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
37 matches
Mail list logo
