On 11/7/06, Christopher Lenz <[EMAIL PROTECTED]> wrote:
> Please check whether you have a ticket_notify_email.cs template in
> your environment directory. If you do, delete it.
>
> (And as I mentioned before, it'd be a very good idea to also delete
> the other templates from that directory and mov
I have created a patch for this pesky bug.
http://code.djangoproject.com/ticket/2315
It's pretty much a one-liner fix, so could a committer please review
and submit?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Hi,
there's a ticket (#3005) that fixes bad documentation about writing
forms. It's been closed as wontfix because newforms are coming (and then
re-opened by the reporter).
Following the tradition to discuss tickets on the devel-list, I'd like
to ask you to reconsider this policy. The old forms
On 11/9/06 9:19 AM, Thomas Steinacher wrote:
> I'm posting it here because Akismet is blocking my ticket. Can't you
> use captchas instead of a stupid spam detector?
I you put in a name and password on the settings page (the link's in the
footer), Trac should let you in.
I'm sorry that you got
Hello,
I'm posting it here because Akismet is blocking my ticket. Can't you
use captchas instead of a stupid spam detector?
Session.objects.get_object() should be Session.objects.get()
On
http://www.djangoproject.com/documentation/sessions/#using-sessions-out-of-views
it says:
{{{
>>> from dj
* David Blewett wrote, On 09.11.2006 14:14:
> What about using generic relations for this? You could have something
> like this:
> class I18NText(models.Model):
> language = models.ForeignKey(Language)
> field = models.CharField(maxlength=25)
> translated_text = models.TextField()
>
I have a question about the database api behavior with the folowing
model
Poll --<< Choice
Poll --<< Vote
Poll
question = models.CharField(maxlength=200)
pub_date = models.DateTimeField()
Choice
poll = models.ForeignKey(Poll)
choice = models.CharField(maxlength=200)
votes = models.IntegerF
Call any Phone anywhere Free!
http://surl.in/HLGB7238206SVRAKSX
--~--~-~--~~~---~--~~
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
On Nov 9, 3:21 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> +1. Keeping all translations in one table instead of creating separate
> tables for each user table is what I was going to propose but you beat
> me :-)
This has one potential benefit - ease global search implementation.
--
serg.
-
David Blewett wrote:
>>> Actually this could be integrated into the core.
>>> When you create a model, you could add translatable=True to fields
>>> that have to be in the language-specific table.
>>> When you make selections, you would need to set the language name in
>>> the following or a simil
On Nov 9, 8:14 am, "David Blewett" <[EMAIL PROTECTED]> wrote:
> What about using generic relations for this? You could have something
> like this:
>
> class I18NText(models.Model):
> language = models.ForeignKey(Language)
> field = models.CharField(maxlength=25)
> translated_text = mod
> > Actually this could be integrated into the core.
> > When you create a model, you could add translatable=True to fields
> > that have to be in the language-specific table.
> > When you make selections, you would need to set the language name in
> > the following or a similar way:
> > MyModel.o
I am forwarding this from the django-users list as it will be of
interest to developers too
Begin forwarded message:
> From: "Aidas Bendoraitis" <[EMAIL PROTECTED]>
> Date: 9 November 2006 2:58:03 PM GMT+05:30
> To: django-users@googlegroups.com
> Subject: Re: how are you handling i18n and m10
13 matches
Mail list logo
