On Fri, Jul 9, 2010 at 00:00, Russell Keith-Magee
<russ...@keith-magee.com> wrote:
> On Thu, Jul 8, 2010 at 3:55 PM, Lachlan Musicman <data...@gmail.com> wrote:
>> Hola,
>>
>> I'm new to this dev thing, but I've done some work on ticket #5373
>
> Thanks for pitching in! Hopefully I'll be able to give you enough
> feedback to progress this issue without scaring you off :-)

That would be great, cheers

> I agree that the first patch (.2.patch) isn't the right approach --
> isinstance checks are generally an indication that you're doing
> something wrong (or at least that you could be doing it better).

Yeah, I knew that, just didn't have the eloquence

> However, I'm also concerned about unexpected consequences for the
> second patch. The obvious use case that you're breaking is if your
> ForeignKey manually defines a verbose_name.

I'm not quite sure I understand. Does that mean we can have
conflicting verbose_names? My mental unrolling of your advice brings
me to:

eg 1:
class Book(models.Model):
    name = models.CharField(max_length=50)

    class Meta:
        verbose_name = _(u'Novel')
        verbose_name_plural = _(u'Novels')

class Author(models.Model):
    name = models.CharField(max_length=50)
    books = models.ManyToManyField(Book, verbose_name=_(u'Paperback'))

In this (ugly, but possible?) case, we have conflicting verbose names.
Which should take precedence? Your note would indicate that Paperback
should?


> So - the next step is to make the tests more robust; you'll either
> prove that this isn't a problem, or you'll find the edge case that
> needs to be fixed.

It's definitely a problem - I've started this because it's one I experience :)

> would be at a lower level -- in this case, testing that foreign key
> fields return an appropriate verbose_name, and/or that ModelForms pick
> up a translated verbose name.

Got it - am working on it now.

cheers
L.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Reply via email to