Re: [Django] #19672: Negated Q objects over nullable joins result in invalid SQL

[Django]

#19672: Negated Q objects over nullable joins result in invalid SQL
-+-
 Reporter:  ikelly   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  Q ForeignKey |  checkin
  nullable   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

 * stage:  Unreviewed => Ready for checkin


Comment:

 The patch looks good to me.

 What versions to patch? I think 1.4 is out of reach, this isn't a crashing
 or data loss bug.

 1.5 is technically also in "crash, data-loss, security, regression" fixes
 only as it is in RC, but as we are going to do RC2 and the patch is as
 safe as they get, IMO master + stable/1.5.x seems like the correct way.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19672: Negated Q objects over nullable joins result in invalid SQL

[Django]

#19672: Negated Q objects over nullable joins result in invalid SQL
-+-
 Reporter:  ikelly   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  Q ForeignKey |  Unreviewed
  nullable   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by ikelly):

 * needs_docs:   => 0
 * has_patch:  0 => 1
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 The bug seems to happen because a local variable gets clobbered in the
 Query.add_filter method.  I've uploaded a patch and tests to fix this.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19672: Negated Q objects over nullable joins result in invalid SQL

[Django]

#19672: Negated Q objects over nullable joins result in invalid SQL
--+
 Reporter:  ikelly|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal|   Keywords:  Q ForeignKey
 Triage Stage:  Unreviewed|  nullable
Easy pickings:  0 |  Has patch:  0
  |  UI/UX:  0
--+
 Using the following set of models:

 {{{
 from django.db import models

 class A(models.Model):
 value = models.IntegerField(null=True)

 class B(models.Model):
 a = models.ForeignKey(A)

 class C(models.Model):
 b = models.ForeignKey(B, null=True)
 }}}

 The query {{{C.objects.filter(~Q(b__a__value=42))}}} fails with the
 following error:

 {{{DatabaseError: no such column: testapp_b.value}}}

 The SQL generated is:

 {{{
 SELECT "testapp_c"."id", "testapp_c"."b_id" FROM "testapp_c" LEFT OUTER
 JOIN "t
 estapp_b" ON ("testapp_c"."b_id" = "testapp_b"."id") LEFT OUTER JOIN
 "testapp_a"
  ON ("testapp_b"."a_id" = "testapp_a"."id") WHERE NOT
 (("testapp_a"."value" = 42
   AND NOT ("testapp_b"."id" IS NULL) AND "testapp_b"."value" IS NOT NULL))
 }}}

 The problem is caused by the last WHERE condition, which is incorrectly
 filtering on the "value" column in the testapp_b table (where it does not
 exist) instead of in the testapp_a table.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18150: Uploading a file ending with a backslash fails

[Django]

#18150: Uploading a file ending with a backslash fails
-+-
 Reporter:  Peter Kuma   |Owner:
 Type:  Bug  |  supersteve9219
Component:  File |   Status:  assigned
  uploads/storage|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by supersteve9219):

 * has_patch:  0 => 1


Comment:

 I added a patch.

 Given IE_sanitize is only used with files uploaded from Internet Explorer
 7 and earlier which represents less than 3% of the total browser share, I
 don't think it is no longer necessary to use this method. Especially given
 that using IE_sanitize causes issues with all unix users.

 Using IE_sanitize only on files starting with something like {{{X:\}}}
 does not fix the issue since {{{:}}} is still a valid unix filename char.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19385: Add support for multiple-column join

[Django]

#19385: Add support for multiple-column join
-+-
 Reporter:  cseibert |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  join |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by jeremyt):

 Pull Request updated concerning comments.

 To the point of the contrib portion, I would like to put this
 functionality in related.py. I have extra commits that moves this to a
 ForeignObject field. ForeignObject is basically the join_field of a
 JoinInfo tuple as ForeignKey is today. It is represented as a virtual
 field so if preferred, we can integrate konk's change. ForeignKey will
 inherit ForeignObject and add properties to make the field non-virtual to
 retain it being used as a column.

 If we want to got this route (my vote goes here), I'm ready to pull the
 trigger so let me know.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 5ab24e: [1.5.x] Added more shortcuts to i18n docs in index...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 5ab24e205af03835fe2e5b856ec253e7405e6769
  
https://github.com/django/django/commit/5ab24e205af03835fe2e5b856ec253e7405e6769
  Author: Ramiro Morales 
  Date:   2013-01-25 (Fri, 25 Jan 2013)

  Changed paths:
M docs/index.txt

  Log Message:
  ---
  [1.5.x] Added more shortcuts to i18n docs in index page.

5b99d5a from master



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19671: Model field option "validators" not working with ManyToManyField

[Django]

#19671: Model field option "validators" not working with ManyToManyField
---+
 Reporter:  fabio@…|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.4
 Severity:  Normal |   Keywords:  validators ManyToManyField
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 {{{
 # models.py

 def validate_depends_on(value):
 # just raise an error, whatever the value
 raise ValidationError('Error')

 class Package(models.Model):
 # ...
 depends_on = models.ManyToManyField(
 'self',
 symmetrical=False,
 related_name='required_by',
 blank=True,
 null=True,
 validators=[validate_depends_on]
 )
 }}}

 My custom validator is not called when saving a model instance through the
 admin. The same validator perfectly works with other fields. Also,
 removing blank and null options didn't help.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15586: Fields with missing columns populated when querying on PostgreSQL

[Django]

#15586: Fields with missing columns populated when querying on PostgreSQL
---+
 Reporter:  sebzur |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.2
 Severity:  Normal |   Resolution:  wontfix
 Keywords:  postgresql | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by timo):

 * status:  reopened => closed
 * resolution:   => wontfix


Comment:

 Since this doesn't happen on PostgreSQL 9.2 and seems like it has a very
 low probability of happening, I don't think it's worth documenting at this
 point. If someone really wants to see this added and can provide a patch,
 I'll be happy to review and commit it.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19670: CachedFilesMixin Doesn't Limit Substitutions to Extension Matches

[Django]

#19670: CachedFilesMixin Doesn't Limit Substitutions to Extension Matches
-+
 Reporter:  matthewwithanm   |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  contrib.staticfiles  |Version:  1.4
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 The format of the `patterns` attribute seems to imply that substitutions
 will only be performed in files with the corresponding extension. However,
 if a file matches *any* of the filename patterns, then *all* of the listed
 substitutions will be performed. For example:


 {{{
 patterns = (
 ("*.css", (
 r"""(url\(['"]{0,1}\s*(.*?)["']{0,1}\))""",
 r"""(@import\s*["']\s*(.*?)["'])""",
 )),
 ("*.js", (
 r"whatever",
 ),
 )
 }}}

 Not only will `url_converter()` be called for any occurrences of the word
 "whatever" in JavaScript files, but also for any occurrences of
 `url('something')` and `@import('something')` (in JavaScript files).

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 58062a: Used property decorators in django/forms.py

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 58062a6302a2bf1013d100deb053ccae2298bb84
  
https://github.com/django/django/commit/58062a6302a2bf1013d100deb053ccae2298bb84
  Author: Claude Paroz 
  Date:   2013-01-25 (Fri, 25 Jan 2013)

  Changed paths:
M django/forms/forms.py

  Log Message:
  ---
  Used property decorators in django/forms.py



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 1686e0: Fixed #18460 -- Fixed change detection of ReadOnly...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 1686e0d184aaf704e5131a8651a070c4a0e58b03
  
https://github.com/django/django/commit/1686e0d184aaf704e5131a8651a070c4a0e58b03
  Author: Claude Paroz 
  Date:   2013-01-25 (Fri, 25 Jan 2013)

  Changed paths:
M django/contrib/auth/forms.py
M django/contrib/auth/tests/forms.py

  Log Message:
  ---
  Fixed #18460 -- Fixed change detection of ReadOnlyPasswordHashField

Thanks jose.sanchez et ezeep.com for the report and Vladimir Ulupov
for the initial patch.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18460: In admin, the history for model User shows always a change in password, although it is not changed

[Django]

#18460: In admin, the history for model User shows always a change in password,
although it is not changed
-+
 Reporter:  jose.sanchez@…   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.4
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  admin, password  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Claude Paroz ):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"1686e0d184aaf704e5131a8651a070c4a0e58b03"]:
 {{{
 #!CommitTicketReference repository=""
 revision="1686e0d184aaf704e5131a8651a070c4a0e58b03"
 Fixed #18460 -- Fixed change detection of ReadOnlyPasswordHashField

 Thanks jose.sanchez et ezeep.com for the report and Vladimir Ulupov
 for the initial patch.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16807: Document/Introduce the process and usage of class based views outside of generic view context

[Django]

#16807: Document/Introduce the process and usage of class based views outside of
generic view context
---+
 Reporter:  ptone  |Owner:  ptone
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by timo):

 Hi Preston, nice work so far. I'd like to try to get this committed. I've
 done some work with your existing patch.

 
https://github.com/timgraham/django/commit/5aa27d5c78024e9c5fdadd883bbac63bf29a9aec

 It looks like you had some more ideas as there were some notes at the
 bottom of the existing commits. Would you like to describe a little more
 what you had in mind?

 
https://github.com/ptone/django/commit/ce46758c02eafd90c92dc07862c5fad9dde40a03#L0R180

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16955: Querying on the reverse of a FK with the wrong class silently returns bad data

[Django]

#16955: Querying on the reverse of a FK with the wrong class silently returns 
bad
data
-+-
 Reporter:  jdunck   |Owner:  dgouldin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 This will be horrible to fix. At least the following work currently, also
 with multistep chains:
 {{{
 parent__in=list_of_childs
 child__in=list_of_parents

 class A:
 pass

 class B:
 a = models.OneToOneField(A, primary_key=True)

 a__in=list_of_B
 b__in=list_of_A
 }}}

 This means that we must check issubclass in two directions + primary key
 chain from value to the related model, and from related model to value.

 The sanest fixes would be to precalculate a set of allowed models in
 Model._meta. The calculation of the set of allowed models will still be
 ugly, but at least checking would be somewhat fast... Patches welcome.

 Another way is to disallow the OneToOneField related lookups. The
 issubclass checks are easy to do.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] ebb504: Moved has_changed logic from widget to form field

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: ebb504db692cac496f4f45762d1d14644c9fa6fa
  
https://github.com/django/django/commit/ebb504db692cac496f4f45762d1d14644c9fa6fa
  Author: Claude Paroz 
  Date:   2013-01-25 (Fri, 25 Jan 2013)

  Changed paths:
M django/contrib/admin/widgets.py
M django/contrib/gis/admin/widgets.py
M django/contrib/gis/forms/fields.py
M django/contrib/gis/tests/geoadmin/tests.py
M django/forms/extras/widgets.py
M django/forms/fields.py
M django/forms/forms.py
M django/forms/models.py
M django/forms/widgets.py
M docs/releases/1.6.txt
M tests/regressiontests/admin_widgets/tests.py
M tests/regressiontests/forms/tests/extra.py
M tests/regressiontests/forms/tests/fields.py
M tests/regressiontests/forms/tests/widgets.py

  Log Message:
  ---
  Moved has_changed logic from widget to form field

Refs #16612. Thanks Aymeric Augustin for the suggestion.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16612: Localized form fields cause Form.has_changed() to always return True.

[Django]

#16612: Localized form fields cause Form.has_changed() to always return True.
---+
 Reporter:  rviotti@…  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Claude Paroz ):

 In [changeset:"ebb504db692cac496f4f45762d1d14644c9fa6fa"]:
 {{{
 #!CommitTicketReference repository=""
 revision="ebb504db692cac496f4f45762d1d14644c9fa6fa"
 Moved has_changed logic from widget to form field

 Refs #16612. Thanks Aymeric Augustin for the suggestion.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19667: blocktrans plural to fail on untranslated languages

[Django]

#19667: blocktrans plural to fail on untranslated languages
--+
 Reporter:  rgaudin@… |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:  i18n locale   | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by anonymous):

 OK, I tested with 1.4.3 and it's the same.

 LANGUAGE_CODE = 'ar'
 LANGUAGES = [('ar', u'Arabic'), ('az', u'Azerbaijani'), ('bg',
 u'Bulgarian'), ('bn', u'Bengali'), ('bs', u'Bosnian'), ('ca', u'Catalan'),
 ('cs', u'Czech'), ('cy', u'Welsh'), ('da', u'Danish'), ('de', u'German'),
 ('el', u'Greek'), ('en', u'English'), ('en-gb', u'British English'),
 ('eo', u'Esperanto'), ('es', u'Spanish'), ('es-ar', u'Argentinian
 Spanish'), ('es-mx', u'Mexican Spanish'), ('es-ni', u'Nicaraguan
 Spanish'), ('et', u'Estonian'), ('eu', u'Basque'), ('fa', u'Persian'),
 ('fi', u'Finnish'), ('fr', u'French'), ('fy-nl', u'Frisian'), ('ga',
 u'Irish'), ('gl', u'Galician'), ('he', u'Hebrew'), ('hi', u'Hindi'),
 ('hr', u'Croatian'), ('hu', u'Hungarian'), ('id', u'Indonesian'), ('is',
 u'Icelandic'), ('it', u'Italian'), ('ja', u'Japanese'), ('ka',
 u'Georgian'), ('kk', u'Kazakh'), ('km', u'Khmer'), ('kn', u'Kannada'),
 ('ko', u'Korean'), ('lt', u'Lithuanian'), ('lv', u'Latvian'), ('mk',
 u'Macedonian'), ('ml', u'Malayalam'), ('mn', u'Mongolian'), ('nb',
 u'Norwegian Bokmal'), ('ne', u'Nepali'), ('nl', u'Dutch'), ('nn',
 u'Norwegian Nynorsk'), ('pa', u'Punjabi'), ('pl', u'Polish'), ('pt',
 u'Portuguese'), ('pt-br', u'Brazilian Portuguese'), ('ro', u'Romanian'),
 ('ru', u'Russian'), ('sk', u'Slovak'), ('sl', u'Slovenian'), ('sq',
 u'Albanian'), ('sr', u'Serbian'), ('sr-latn', u'Serbian Latin'), ('sv',
 u'Swedish'), ('sw', u'Swahili'), ('ta', u'Tamil'), ('te', u'Telugu'),
 ('th', u'Thai'), ('tr', u'Turkish'), ('tt', u'Tatar'), ('uk',
 u'Ukrainian'), ('ur', u'Urdu'), ('vi', u'Vietnamese'), ('zh-cn',
 u'Simplified Chinese'), ('zh-tw', u'Traditional Chinese')]

 LANGUAGES here displayed in English for readiness, it's actually in
 Arabic.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16955: Querying on the reverse of a FK with the wrong class silently returns bad data

[Django]

#16955: Querying on the reverse of a FK with the wrong class silently returns 
bad
data
-+-
 Reporter:  jdunck   |Owner:  dgouldin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by claudep):

 #19669 was a duplicate.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19669: Django doesn't check type on foreign key query

[Django]

#19669: Django doesn't check type on foreign key query
-+-
 Reporter:  ram@…|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * status:  new => closed
 * resolution:   => duplicate


Comment:

 Duplicate of #16955

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19669: Django doesn't check type on foreign key query

[Django]

#19669: Django doesn't check type on foreign key query
-+-
 Reporter:  ram@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 There's already a ticket for this, but I can't find it.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19669: Django doesn't check type on foreign key query

[Django]

#19669: Django doesn't check type on foreign key query
--+
 Reporter:  ram@… |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I can only test on 1.4.x and not 1.5.x, so if someone can test on 1.5.x
 that would help. (If the bug was already found and fixed in 1.5.x I'll be
 happy!)

 If you're making a lookup that includes a foreign-key field, and you pass
 in an object of a different type, Django doesn't complain but just uses
 the ID of the object you put in even if it's of a different type.

 Example:

 Chair.objects.filter(user=site)

 If you pass in a `Site` object instead of a `User` object, Django will not
 raise an exception, but will look for a `Chair` whose `User` has an ID
 equal to that of `site`, which is probably never what the user wants and
 caused a hard-to-find bug for me in my application.

 I suggest simply raising an exception in this case.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18481: IOErrors from FILES are not wrapped with UnreadablePostError

[Django]

#18481: IOErrors from FILES are not wrapped with UnreadablePostError
---+
 Reporter:  KyleMac|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  HTTP handling  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by edevil):

 I added a new patch that re-raises the exception in the standard format
 seen on the rest of the codebase.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] ce27fb: Revert "Patch by Claude for #16084."

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: ce27fb198dcce5dad47de83fc81119d3bb6567ce
  
https://github.com/django/django/commit/ce27fb198dcce5dad47de83fc81119d3bb6567ce
  Author: Ramiro Morales 
  Date:   2013-01-25 (Fri, 25 Jan 2013)

  Changed paths:
M django/core/management/commands/makemessages.py
M docs/man/django-admin.1
M docs/ref/django-admin.txt
M docs/topics/i18n/translation.txt
M tests/regressiontests/i18n/commands/extraction.py
R tests/regressiontests/i18n/commands/project_dir/__init__.py
R tests/regressiontests/i18n/commands/project_dir/app_no_locale/models.py
R tests/regressiontests/i18n/commands/project_dir/app_with_locale/models.py
M tests/regressiontests/i18n/tests.py

  Log Message:
  ---
  Revert "Patch by Claude for #16084."

This reverts commit 2babab0bb351ff7a13fd23795f5e926a9bf95d22.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 2babab: Patch by Claude for #16084.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 2babab0bb351ff7a13fd23795f5e926a9bf95d22
  
https://github.com/django/django/commit/2babab0bb351ff7a13fd23795f5e926a9bf95d22
  Author: Ramiro Morales 
  Date:   2013-01-25 (Fri, 25 Jan 2013)

  Changed paths:
M django/core/management/commands/makemessages.py
M docs/man/django-admin.1
M docs/ref/django-admin.txt
M docs/topics/i18n/translation.txt
M tests/regressiontests/i18n/commands/extraction.py
A tests/regressiontests/i18n/commands/project_dir/__init__.py
A tests/regressiontests/i18n/commands/project_dir/app_no_locale/models.py
A tests/regressiontests/i18n/commands/project_dir/app_with_locale/models.py
M tests/regressiontests/i18n/tests.py

  Log Message:
  ---
  Patch by Claude for #16084.


  Commit: 5b99d5a330fc412ce56b9e5f9cf0b971654da90c
  
https://github.com/django/django/commit/5b99d5a330fc412ce56b9e5f9cf0b971654da90c
  Author: Ramiro Morales 
  Date:   2013-01-25 (Fri, 25 Jan 2013)

  Changed paths:
M docs/index.txt

  Log Message:
  ---
  Added more shortcuts to i18n docs in index page.


Compare: https://github.com/django/django/compare/b9c8bbf3726a...5b99d5a330fc

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #10070: Named parameters not working on raw sql queries with sqlite

[Django]

#10070: Named parameters not working on raw sql queries with sqlite
-+-
 Reporter:  msurdi   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.0
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by anonymous):

 I think at very least this should be mentioned explicitly in the docs.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19667: blocktrans plural to fail on untranslated languages

[Django]

#19667: blocktrans plural to fail on untranslated languages
--+
 Reporter:  rgaudin@… |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:  i18n locale   | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by ramiro):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * component:  Translations => Internationalization
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 Are you actually using Django 1.3? Can you test with a newer versions like
 1.4 and 1.5c1?

 Also, what are the values of the LANGUAGES and LANGUAGE_CODE settings?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19668: Form enhancement: `Form.set_data` to set data and files (was: Form enhancement: `Form.set_data` to set data an files)

[Django]

#19668: Form enhancement: `Form.set_data` to set data and files
-+--
 Reporter:  bruth|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19668: Form enhancement: `Form.set_data` to set data an files

[Django]

#19668: Form enhancement: `Form.set_data` to set data an files
-+--
 Reporter:  bruth|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by bruth):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Pull request here: https://github.com/django/django/pull/674

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19668: Form enhancement: `Form.set_data` to set data an files

[Django]

#19668: Form enhancement: `Form.set_data` to set data an files
-+
 Reporter:  bruth|  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  Forms|Version:  master
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  1
Easy pickings:  0|  UI/UX:  0
-+
 This simply moves the logic for setting `is_bound`, `data` and `files`
 into a method which enables setting the data after form initialization.
 This is a backwards compatible. This makes it easier to not have to
 initialize a form twice in view. It changes from this idiom:

 {{{#!python
 def view(request):
 if request.method == 'POST':
 form = Form(request.POST, request.FILES)
 ...
 else:
 form = Form()
 ...
 }}}

 to simply this:

 {{{#!python
 def view(request):
 form = Form()
 if request.method == 'POST':
 form.set_data(request.POST, request.FILES)
 ...
 }}}

 This reduces clutter and redundancy when there are a lot of form arguments
 passed.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19414: Add a "register" class decorator for admin.

[Django]

#19414: Add a "register" class decorator for admin.
---+
 Reporter:  stavros|Owner:  BHold
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by stavros):

 Why not just reuse admin.site.register? It looks like you reimplemented
 the method?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17037: Add management command to print active project settings

[Django]

#17037: Add management command to print active project settings
-+-
 Reporter:  msabramo |Owner:  aaugustin
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  1.3
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  printsettings|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * status:  new => assigned
 * owner:  msabramo => aaugustin


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #1193: Write {% load i18n %} only once

[Django]

#1193: Write {% load i18n %} only once
-+--
 Reporter:  inerte@… |Owner:  adrian
 Type:  enhancement  |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  minor|   Resolution:  invalid
 Keywords:  i18n, trans  | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by anonymous):

 * ui_ux:   => 0
 * easy:   => 0


Comment:

 I don't understand, so how would I add {% load i18n %} to the default
 taglibs?

 What is the feature of the template system called?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18986: Improve error message for broken CSS in CachedStaticFilesStorage

[Django]

#18986: Improve error message for broken CSS in CachedStaticFilesStorage
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  1.4
Component:  contrib.staticfiles  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by aaugustin):

 Pull request by zyegfryed: https://github.com/django/django/pull/673

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18114: makemessages does not care about context in trans templatetag

[Django]

#18114: makemessages does not care about context in trans templatetag
-+-
 Reporter:  tomaz.stucin@…   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  1.4
  commands)  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:
 Keywords:  trans context|  Unreviewed
  pgettext makemessages i18n |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by ramiro):

 * status:  new => closed
 * resolution:   => duplicate


Comment:

 Duplicate of #18881. Install the latest 1.4.x bug-fix release (currently
 1.4.3) to get the fix.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19587: makemessages to update PO file only if translation's changed

[Django]

#19587: makemessages to update PO file only if translation's changed
--+
 Reporter:  Natim87   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Internationalization  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by ramiro):

 * component:  Translations => Internationalization


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19667: blocktrans plural to fail on untranslated languages

[Django]

#19667: blocktrans plural to fail on untranslated languages
--+-
 Reporter:  rgaudin@… |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Translations  |Version:  1.3
 Severity:  Normal|   Keywords:  i18n locale
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+-
 Reproduce:
 * Pick a language with a different plural system then English. The
 language must exists in Django core. Arabic for example.
 * Set your browser to it.
 * Add a plural blocktrans {% blocktrans count nb_users=5 %}{{ nb_users }}
 user{% plural %}{{ nb_users }} users{% endblocktrans %}
 * Don't add translation for it.
 * Browse it.

 It will fail with TemplateSyntaxError: Caught TypeError while rendering:
 not all arguments converted during string formatting

 I believe what happens is:
 * Django finds a translation in django core and consider the language
 supported.
 * Django sets its internal plural mechanism to Arabic.
 * Django can't find a matching plural translation in the nonexistent
 Arabic translation NOR in the default English as the plural system is
 different.

 If this assumption is true, the problem might be in gettext itself.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18114: makemessages does not care about context in trans templatetag

[Django]

#18114: makemessages does not care about context in trans templatetag
-+-
 Reporter:  tomaz.stucin@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.4
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  trans context|  Unreviewed
  pgettext makemessages i18n |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Description changed by ramiro:

Old description:

> We are working with translations and we have done the following
> * we have 2 templates: template1.html and template2.html
> * in template1 we have the following:
> {{{
> {% trans 'contact' as trans_contact %}
> }}}
> * in template2 we have the following:
> {{{
> {% trans 'contact' context 'suggestive' as trans_contact %}
> }}}
> * when we makemessages -a we get the following in the django.po file:
> {{{
> #: web/templates/web/template1.html:35
> #: web/templates/web/template2.html:21
> msgid "contact"
> msgstr ""
> }}}
> - what we expect instead (in django.po) is actually:
> {{{
> #: web/templates/web/template1.html:35
> msgid "contact"
> msgstr ""
> #: web/templates/web/template2.html:21
> msgctxt "suggesttive"
> msgid "contact"
> msgstr ""
> }}}
>
> So it seems that the "django-admin.py makemessages -a" does not take into
> account context in the trans templatetag (but it does process both trans
> tag as can be seen in the comment)
>
> If we write (anywhere in the code) the following:
> {{{
> from django.utils.translation import pgettext
> test = pgettext('suggesttive', 'contact')
> }}}
>
> then the django.po content is as expected and if we translate the strings
> (in django.po) and then render the template, the context is taken into
> account and the translation on the webpage (produced from the template)
> is as it should be, so the trans templatetag works as expected, just the
> makemessages does not.
>

> If this is a "feature" I apologize in advance.

New description:

 We are working with translations and we have done the following
 * we have 2 templates: template1.html and template2.html
 * in template1 we have the following:
 {{{
 {% trans 'contact' as trans_contact %}
 }}}
 * in template2 we have the following:
 {{{
 {% trans 'contact' context 'suggesttive' as trans_contact %}
 }}}
 * when we makemessages -a we get the following in the django.po file:
 {{{
 #: web/templates/web/template1.html:35
 #: web/templates/web/template2.html:21
 msgid "contact"
 msgstr ""
 }}}
 - what we expect instead (in django.po) is actually:
 {{{
 #: web/templates/web/template1.html:35
 msgid "contact"
 msgstr ""
 #: web/templates/web/template2.html:21
 msgctxt "suggesttive"
 msgid "contact"
 msgstr ""
 }}}

 So it seems that the "django-admin.py makemessages -a" does not take into
 account context in the trans templatetag (but it does process both trans
 tag as can be seen in the comment)

 If we write (anywhere in the code) the following:
 {{{
 from django.utils.translation import pgettext
 test = pgettext('suggesttive', 'contact')
 }}}

 then the django.po content is as expected and if we translate the strings
 (in django.po) and then render the template, the context is taken into
 account and the translation on the webpage (produced from the template) is
 as it should be, so the trans templatetag works as expected, just the
 makemessages does not.


 If this is a "feature" I apologize in advance.

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19665: 'Command' object has no attribute 'stderr'

[Django]

#19665: 'Command' object has no attribute 'stderr'
-+-
 Reporter:  stefankoegl  |Owner:  claudep
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz ):

 In [changeset:"2d8b0315f46d24c6567a05422bd609f3a689bda8"]:
 {{{
 #!CommitTicketReference repository=""
 revision="2d8b0315f46d24c6567a05422bd609f3a689bda8"
 [1.5.x] Fixed #19665 -- Ensured proper stderr output for
 Command.run_from_argv

 Thanks Stefan Koegl for the report and Simon Charette for the review.
 Backport of b9c8bbf37 from master.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 2d8b03: [1.5.x] Fixed #19665 -- Ensured proper stderr outp...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 2d8b0315f46d24c6567a05422bd609f3a689bda8
  
https://github.com/django/django/commit/2d8b0315f46d24c6567a05422bd609f3a689bda8
  Author: Claude Paroz 
  Date:   2013-01-25 (Fri, 25 Jan 2013)

  Changed paths:
M django/core/management/base.py
M tests/regressiontests/admin_scripts/tests.py

  Log Message:
  ---
  [1.5.x] Fixed #19665 -- Ensured proper stderr output for Command.run_from_argv

Thanks Stefan Koegl for the report and Simon Charette for the review.
Backport of b9c8bbf37 from master.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19665: 'Command' object has no attribute 'stderr'

[Django]

#19665: 'Command' object has no attribute 'stderr'
-+-
 Reporter:  stefankoegl  |Owner:  claudep
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"b9c8bbf3726a1956be1db70ffd3bef04a2e5311a"]:
 {{{
 #!CommitTicketReference repository=""
 revision="b9c8bbf3726a1956be1db70ffd3bef04a2e5311a"
 Fixed #19665 -- Ensured proper stderr output for Command.run_from_argv

 Thanks Stefan Koegl for the report and Simon Charette for the review.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] b9c8bb: Fixed #19665 -- Ensured proper stderr output for C...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: b9c8bbf3726a1956be1db70ffd3bef04a2e5311a
  
https://github.com/django/django/commit/b9c8bbf3726a1956be1db70ffd3bef04a2e5311a
  Author: Claude Paroz 
  Date:   2013-01-25 (Fri, 25 Jan 2013)

  Changed paths:
M django/core/management/base.py
M tests/regressiontests/admin_scripts/tests.py

  Log Message:
  ---
  Fixed #19665 -- Ensured proper stderr output for Command.run_from_argv

Thanks Stefan Koegl for the report and Simon Charette for the review.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19665: 'Command' object has no attribute 'stderr'

[Django]

#19665: 'Command' object has no attribute 'stderr'
-+-
 Reporter:  stefankoegl  |Owner:  claudep
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * version:  1.5-alpha-1 => master
 * stage:  Accepted => Ready for checkin


Comment:

 Patch looks good and `admin_scripts` tests pass on Python 2.7.3 and 3.2.3
 (SQlite) while failing without the fix.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17664: Smart `if` tag silencing exceptions plus `QuerySet` caching equals buggy behaviour.

[Django]

#17664: Smart `if` tag silencing exceptions plus `QuerySet` caching equals buggy
behaviour.
-+-
 Reporter:  mrmachine|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  smart if tag | Triage Stage:  Accepted
  queryset exception silenced|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by pjdelport):

 This should probably be split into two different tickets, yes.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17664: Smart `if` tag silencing exceptions plus `QuerySet` caching equals buggy behaviour.

[Django]

#17664: Smart `if` tag silencing exceptions plus `QuerySet` caching equals buggy
behaviour.
-+-
 Reporter:  mrmachine|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  smart if tag | Triage Stage:  Accepted
  queryset exception silenced|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by pjdelport):

 I ran into this template system problem, independent of querysets, with a
 filter that triggered an {{{AssertionError}}}.

 The following example raises the error:

 {{{
 {% if var|some_filter %}yes{% else %}no{% endif %}
 }}}

 while the following examples both swallow the error, and (surprisingly!)
 evaluate to "no":

 {{{
 {% if not var|somefilter %}yes{% else %}no{% endif %}
 {% if True or var|somefilter %}yes{% else %}no{% endif %}
 }}}

 krzysiumed's analysis of the template evaluation behavior is spot-on.

 I believe the current behavior is broken, regardless of the question of
 whether templates should raise exceptions or not: if an exception-raising
 filter like `var|somefilter` is supposed to evaluate to the empty string,
 then one would in turn expect expressions like `not var|somefilter` and
 `True or var|somefilter` to interpret the empty string and evaluate to
 true (or whatever is appropriate), instead of effectively ignoring the
 intermediate expressions and always evaluating to false, as above.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19665: 'Command' object has no attribute 'stderr'

[Django]

#19665: 'Command' object has no attribute 'stderr'
-+-
 Reporter:  stefankoegl  |Owner:  claudep
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:
  commands)  |  1.5-alpha-1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * has_patch:  0 => 1


Comment:

 Patch attached in case someone wants to quickly review it.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19666: choice_text in the detail template

[Django]

#19666: choice_text in the detail template
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.4
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by aaugustin):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => invalid
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 You're mixing versions 1.4 and 1.5/dev of the docs — you started the
 tutorial with one version and continued with the other.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19577: admin doc may encourage bad practices

[Django]

#19577: admin doc may encourage bad practices
-+-
 Reporter:  foo@…|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  1.4
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"42fcfcaa529dac1fe3066797d7e4ab7aa6f6cdf3"]:
 {{{
 #!CommitTicketReference repository=""
 revision="42fcfcaa529dac1fe3066797d7e4ab7aa6f6cdf3"
 [1.5.x] Fixed #19577 - Added HTML escaping to admin examples.

 Thanks foo@ for the report and Florian Apolloner for the review.

 Backport of eafc036476 from master
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 42fcfc: [1.5.x] Fixed #19577 - Added HTML escaping to admi...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 42fcfcaa529dac1fe3066797d7e4ab7aa6f6cdf3
  
https://github.com/django/django/commit/42fcfcaa529dac1fe3066797d7e4ab7aa6f6cdf3
  Author: Tim Graham 
  Date:   2013-01-25 (Fri, 25 Jan 2013)

  Changed paths:
M django/utils/html.py
M docs/ref/contrib/admin/index.txt
M docs/ref/utils.txt

  Log Message:
  ---
  [1.5.x] Fixed #19577 - Added HTML escaping to admin examples.

Thanks foo@ for the report and Florian Apolloner for the review.

Backport of eafc036476 from master



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19577: admin doc may encourage bad practices

[Django]

#19577: admin doc may encourage bad practices
-+-
 Reporter:  foo@…|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  1.4
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by Tim Graham ):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"eafc0364764ba12babd76194d8e1f78b876471ec"]:
 {{{
 #!CommitTicketReference repository=""
 revision="eafc0364764ba12babd76194d8e1f78b876471ec"
 Fixed #19577 - Added HTML escaping to admin examples.

 Thanks foo@ for the report and Florian Apolloner for the review.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] eafc03: Fixed #19577 - Added HTML escaping to admin exampl...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: eafc0364764ba12babd76194d8e1f78b876471ec
  
https://github.com/django/django/commit/eafc0364764ba12babd76194d8e1f78b876471ec
  Author: Tim Graham 
  Date:   2013-01-25 (Fri, 25 Jan 2013)

  Changed paths:
M django/utils/html.py
M docs/ref/contrib/admin/index.txt
M docs/ref/utils.txt

  Log Message:
  ---
  Fixed #19577 - Added HTML escaping to admin examples.

Thanks foo@ for the report and Florian Apolloner for the review.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19666: choice_text in the detail template

[Django]

#19666: choice_text in the detail template
---+
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 In the doc website part 3 it says about the detail template:


 {{ poll.question }}
 
 {% for choice in poll.choice_set.all %}
 {{ choice.choice }}
 {% endfor %}
 


 But choice.choice does not exist. Should be choice.choice_text

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19577: admin doc may encourage bad practices

[Django]

#19577: admin doc may encourage bad practices
-+-
 Reporter:  foo@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by apollo13):

 * stage:  Accepted => Ready for checkin


Comment:

 Thanks, looks good now!

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19665: 'Command' object has no attribute 'stderr'

[Django]

#19665: 'Command' object has no attribute 'stderr'
-+-
 Reporter:  stefankoegl  |Owner:  claudep
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:
  commands)  |  1.5-alpha-1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 I'm still curious to know what error did your command raises so as
 `self.stderr` was not even initialized, as it is one of the first thing
 `execute` is doing. Try to replace `self.stderr` by `sys.stderr` in your
 Django code to find out.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19662: Explain correct `authenticate` usage with custom user model.

[Django]

#19662: Explain correct `authenticate` usage with custom user model.
--+--
 Reporter:  tomchristie   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.5-beta-1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by tomchristie):

 > We have to be clear not to further confuse the situation between custom
 users and custom backends ... authenticate only needs **credentials

 Could use something like: "**Note**: If you're using the default
 authentication backend `ModelBackend`, then there are two credentials
 required: `username`, and `password`.  Note that the first named argument
 will always be named `username`, even if you're using a custom user model
 with``USERNAME_FIELD`` set to some other field."

 It's a bit verbose, but better than not mentioning it.

 > Its not clear to me that the modelbackend shouldn't further introspect
 the user model to get then name of the USERNAME_FIELD and look for a
 matching kwarg

 Could be an option, but we'd also need to consider if the same ought to
 then also apply to `AuthenticationForm`.  Ie. Should the `username` field,
 instead be named `email` if using an email-based custom user model?

 I'm not sure what the best behavior is.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19665: 'Command' object has no attribute 'stderr'

[Django]

#19665: 'Command' object has no attribute 'stderr'
-+-
 Reporter:  stefankoegl  |Owner:  claudep
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:
  commands)  |  1.5-alpha-1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * status:  new => assigned
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * owner:  nobody => claudep
 * needs_docs:   => 0
 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.