Re: [Django] #6507: [proposal] Create extension to Python Cookie module

[Django]

#6507: [proposal] Create extension to Python Cookie module
+---
  Reporter:  dcramer| Owner:  nobody
Status:  new| Milestone:  1.2   
 Component:  HTTP handling  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Someday/Maybe  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  1 
Needs_better_patch:  0  |  
+---
Comment (by qingfeng):

 This bug will affect mod_python and wsgi reading session, because
 "cookie.load (str)" error, all the cookie will be cleared

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #11574: Allow extra blank rows for adding new records when using list_editable in admin change list view

[Django]

#11574: Allow extra blank rows for adding new records when using list_editable 
in
admin change list view
--+-
 Reporter:  rfugger   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  SVN   
 Keywords:  list_editable extra rows add  |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Now that we can edit records in bulk in the admin using `list_editable`,
 it would be nice to be able to add new items in bulk in the same way.
 Something like a `list_editable_extra` field on `ModelAdmin` that works
 similarly to the `extra` field on `InlineModelAdmin`.

 What's seems to be needed:

  * Set the `extra` parameter to modelformset_factory in
 `ModelAdmin.get_changelist_formset` to generate the empty forms.
  * Adapt the `result_list` template tag in `admin_list.py` to show the
 extra forms.  This can be done by calling `items_for_result` with an empty
 model for each empty form.
  * Adapt paginator and actions area to account for the extra rows.  Not
 quite sure how to do 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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #11572: Very high memory usage by big sitemaps

[Django]

#11572: Very high memory usage by big sitemaps
---+
  Reporter:  riklaunim | Owner:  nobody
Status:  closed| Milestone:
 Component:  Contrib apps  |   Version:  1.0   
Resolution:  invalid   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by ubernostrum):

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

Comment:

 I'm not sure what the bug is here; querying thousands of objects in one go
 (as you're doing when you fetch the list of items) should be expected to
 increase memory use. You may want to look into alternative query methods
 which allow you to conserve memory, but in general this is going to be
 more memory-intensive as the number of objects involved grows.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #11573: Nginx's URL Changed

[Django]

#11573: Nginx's URL Changed
+---
  Reporter:  bryanveloso| Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Alex):

  * needs_better_patch:  => 0
  * needs_docs:  => 0
  * stage:  Unreviewed => Ready for checkin
  * needs_tests:  => 0
  * milestone:  1.2 =>

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #11573: Nginx's URL Changed

[Django]

#11573: Nginx's URL Changed
---+
 Reporter:  bryanveloso|   Owner:  nobody
   Status:  new|   Milestone:  1.2   
Component:  Documentation  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 [http://wiki.codemongers.com/Main] throws a 404.
 [http://wiki.nginx.org/Main] is the new home of the Nginx wiki, etc.

 Patch included.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #11566: CSRF documentation problem

[Django]

#11566: CSRF documentation problem
+---
  Reporter:  benlbroussard  | Owner:  nobody
Status:  closed | Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution:  invalid|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by lukeplant):

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

Comment:

 Cross-domain img, css etc. requests are not "XMLHttpRequest requests", and
 they are irrelevant because you cannot get the browser to set the X
 -Requested-With header for those requests.  As for XMLHttpRequest itself,
 by looking at logs etc., I've verified that I cannot produce a cross-
 domain GET request or POST request using XMLHttpRequest (with the browsers
 I've tested at least).  So this bug report appears to be invalid.  If
 there are some browsers where you can use XMLHttpRequest to do a cross-
 domain request, please re-open, indicating which browsers.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #11572: Very high memory usage by big sitemaps

[Django]

#11572: Very high memory usage by big sitemaps
--+-
 Reporter:  riklaunim |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Contrib apps  | Version:  1.0   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 I'm using Py 2.5, Django 1.X, Nginx/FastCGI hosting at megiteam.pl. The
 site has a big sitemap - 9K elements, 1,7MB sitemap.xml file. The sitemap
 is done by the book with Sitemap framework:

 {{{
 class MainMap(Sitemap):
 changefreq = "never"
 priority = 0.5

 def items(self):
 return JobOffer.objects.filter(published=True,
 inactive=False)

 def lastmod(self, obj):
 return obj.published_at
 }}}
 The problem is that looking at memstat -v after requesting sitemap.xml
 shows that memory usage boosts from 6MB just after restart to 105MB, and
 keeps at that level for every next request of the sitemap (where the file
 is 1,7MB). If I limit the query to 1000 elements I get ~22MB memory usage.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #11571: latex documentation generation error

[Django]

#11571: latex documentation generation error
---+
 Reporter:  nsmgr8 |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.1-beta-1
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 building latex documentation fails with the following error:

 Markup is unsupported in LaTeX:
 ref/contrib/admin/actions:: too many nesting section levels for LaTeX, at
 heading: Writing action functions
 make: *** [latex] Error 1

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #10608: Support RequestSite along with Sites.objects.get_current() in contrib

[Django]

#10608: Support RequestSite along with Sites.objects.get_current() in contrib
---+
  Reporter:  hvendelbo | Owner:  nobody
Status:  new   | Milestone:  1.2   
 Component:  Contrib apps  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by veena):

 The management of the "if statements" in applications will be annoying,
 don't you think?

 Shouldn't there be a Site class not inherited from django.db.models.Model
 but provide API for getting data? Then if site app is installed it can use
 database as a storage for site data. If site app is not installed, it will
 use RequestSite class. Of course, request object is need to be passed.

 It forces not to use construction like "current_site.flatpage_set.all()"
 but "Flatpage.objects.filter(sites=site)" and also "if statements" don't
 need to be used.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #11570: Request and Response objects page not using unicode responses in examples

[Django]

#11570: Request and Response objects page not using unicode responses in 
examples
---+
 Reporter:  adamnelson |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 This is almost pedantic, but the 'Request and Response Objects' page
 examples are not giving responses in unicode.  This patch changes it.  The
 only reason this matters is because I was having trouble with updating a
 copied POST dictionary and one of the avenues I went down was whether
 there was a problem mixing unicode and non-unicode keys.  This makes it
 clear that no matter what you do, all keys are made unicode by QueryDict
 (or at least, that's how it appears).

 http://docs.djangoproject.com/en/dev/ref/request-response/

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #11569: django.core.cache.backends.db has bad transaction handling

[Django]

#11569: django.core.cache.backends.db has bad transaction handling
--+-
 Reporter:  Glenn |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 (This problem is manifesting in core.cache, but the real problem is in
 db.transaction, so I've marked this as a DB problem.)

 The database backend for caching handles transactions badly.

 When inserting a cache key, it searches for an existing cache key.  If
 found, it does an UPDATE.  If not found, it does an INSERT.  The INSERT
 case can lead to a constraint violation, if another thread inserts that
 key between the SELECT and the INSERT.  The code expects this, and catches
 DatabaseError.

 This rolls back the whole transaction, including anything the caller is
 doing.  It needs a savepoint for this, so it only rolls back its own work.

 To handle this sanely, transaction support really needs to require
 savepoints, so it can expose a helper to start and commit a nested
 transaction, eg. db.transaction.run_in_transaction(func):

  - If a transaction is started already, start a savepoint; when finished,
 release the savepoint.
  - If a transaction is not started, start one (typically a no-op due to
 non-autocommit); when finished, commit.
  - On exception, rollback whichever it started.

 Savepoints are supported by all production-quality databases (including
 MySQL, Postgres and SQLite), so requiring them in the backend seems
 reasonable.  I've hit the need for nested transactions in Django so many
 times I had to write my own wrapper to implement 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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #11568: Ordering by related attributes makes distinct() break

[Django]

#11568: Ordering by related attributes makes distinct() break
--+-
 Reporter:  sfllaw|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.0   
 Keywords:  order_by distinct ForeignKey  |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 The problem is that sorting on an attribute of a related model causes
 ```distinct()``` to fail.

 This is because the ```SELECT DISTINCT``` operates on the extra column
 required for the LEFT OUTER JOIN, which makes it impossible to group the
 desired results.

 To reproduce the error, run this test case:

 '''models.py'''
 {{{
 import django

 from django.db import models


 class Article(models.Model):
 title = models.CharField(max_length=128)

 def __unicode__(self):
 return self.title

 class Comment(models.Model):
 article = models.ForeignKey(Article)
 comment = models.CharField(max_length=128)

 def __unicode__(self):
 return "%s on %s" % (self.comment, self.article.title)

 }}}

 '''tests.py'''
 {{{
 from django.test import TestCase
 from django import db
 from django.conf import settings

 from .models import Article, Comment


 class TestOrderDistinctBug(TestCase):
 def test(self):
 settings.DEBUG = True
 awesome = Article.objects.create(title="Awesome Title")
 different = Article.objects.create(title="Different Title")
 wonderfull = Article.objects.create(title="Bad Title")

 Comment.objects.create(article=awesome, comment="Agreed")
 Comment.objects.create(article=awesome, comment="Dummy")
 Comment.objects.create(article=different, comment="Yeah")
 Comment.objects.create(article=different, comment="Onoz ")
 Comment.objects.create(article=wonderfull, comment="First !")

 db.reset_queries()
 articles = Article.objects.order_by("comment__comment").distinct()

 print "articles=%s" % articles
 # articles=[, ,
 , , ]

 print "sql is : %s" % db.connection.queries[0]
 # sql is : {'time': '0.001',
 # 'sql': u'SELECT DISTINCT `order_bug_article`.`id`,
 `order_bug_article`.`title`, `order_bug_comment`.`comment`
 # FROM `order_bug_article` LEFT OUTER JOIN `order_bug_comment` ON
 (
 #`order_bug_article`.`id` = `order_bug_comment`.`article_id`
 # ) ORDER BY `order_bug_comment`.`comment` ASC LIMIT 21'}


 # count returns the right thing
 self.assertEquals(articles.count(), 3)
 # but the content of the query set is wrong
 self.assertEquals(len(articles), 3)
 }}}

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #11567: Translation update for Danish

[Django]

#11567: Translation update for Danish
--+-
 Reporter:  finngruwier   |   Owner:  nobody
   Status:  new   |   Milestone:  1.1   
Component:  Translations  | Version:  1.1-beta-1
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Please update the translation for Danish (da) according to the attached
 diff file.

 This update is for Django 1.1.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #11566: CSRF documentation problem

[Django]

#11566: CSRF documentation problem
---+
 Reporter:  benlbroussard  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 The documentation for "Cross Site Request Forgery protection" found at
 http://docs.djangoproject.com/en/dev/ref/contrib/csrf/ is both unclear and
 incorrect in the last paragraph before limitations where it states:

 "The middleware tries to be smart about requests that come in via AJAX.
 Many JavaScript toolkits send an "X-Requested-With: XMLHttpRequest" HTTP
 header; these requests are detected and automatically not handled by this
 middleware. We can do this safely because, in the context of a browser,
 the header can only be added by using XMLHttpRequest, and browsers already
 implement a same-domain policy for XMLHttpRequest. (Note that this is not
 secure if you don't trust content within the same domain or subdomains.)"

 It is true that the browsers have implemented a same-domain policy for
 XMLHttpRequest. The implicit statement is that the browser will only allow
 XMLHttpRequest requests from the same domain. This is, however, not true.
 Browsers will allow image, js file, css file, and AJAX requests from any
 domain to any domain. What it will not allow is the parsing of the AJAX
 response.

 This means that the current CsrfMiddleware does not handle AJAX requests
 securely. It should validate a token for POST AJAX requests. It should
 fail if the token is not valid or doesn't exist.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #11565: Rate Limit Error Emails

[Django]

#11565: Rate Limit Error Emails
-+--
  Reporter:  andrewmintel| Owner:  nobody
Status:  new | Milestone:
 Component:  Core framework  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by lukeplant):

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

Comment:

 Surely the answer to your question about the cache throwing errors is to
 use the cache very defensively?  Just put broad try/catch around both
 calls to the cache, and if anything fails, ignore those errors and make
 sure you send the e-mail.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #5515: CSRF has hard-encoded error page

[Django]

#5515: CSRF has hard-encoded error page
+---
  Reporter:  Piotr Lewandowski   | 
Owner: 
Status:  closed | 
Milestone: 
 Component:  Contrib apps   |   
Version:  SVN
Resolution:  duplicate  |  
Keywords: 
 Stage:  Design decision needed | 
Has_patch:  1  
Needs_docs:  0  |   
Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Comment (by lukeplant):

 Replying to [comment:13 anonymous]:
 > Does the patch in #9977 provide for a 403.html template for
 PermissionDenied errors?

 No, it doesn't.  I guess if you removed the CSRF stuff from the patch,
 this would be useful in its own right, and the bug title would probably
 want to change.  A problem I have with the patch, on top of the concerns
 Jacob raised, is the issue of i18n — if we want to solve this, we want to
 do it right.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #11542: Interactive shell is not configurable

[Django]

#11542: Interactive shell is not configurable
-+--
  Reporter:  Seamus  | Owner:  Seamus
Status:  new | Milestone:
 Component:  Core framework  |   Version:  1.0   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by Seamus):

  * owner:  nobody => Seamus
  * component:  Uncategorized => Core framework
  * stage:  Unreviewed => Design decision needed

Comment:

 BPython can now be embedded in Django just like IPython is.  When the next
 version of BPython is released I will post my django patch for bpython.

 Currently manage.py tries to import IPython, failing that it uses the
 default interpreter.  My modification would have it first try to use
 IPython, then BPython, then the default.  There would also be a --bpython
 flag for people who use both.  Using this method nobody's default behavior
 gets messed with -- only people who want to use bpython will be affected.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #11559: urlresolvers.reverse do not work with namespaced urls and captured parameters in parent urlconf

[Django]

#11559: urlresolvers.reverse do not work with namespaced urls and captured
parameters in parent urlconf
+---
  Reporter:  kmik...@gmail.com  | Owner:  nobody
Status:  new| Milestone:  1.1   
 Component:  Core framework |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by danros):

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

Comment:

 I also have exactly the same issue. Bit of a let-down as I upgraded to 1.1
 ahead of time in order to use namespaced urls exactly in this way!

 In my example I have a 'username' argument as part of the root urlconf.

 >>> reverse('userwikis:wiki-view', kwargs={'slug':'testslug'})
 '/users/(?P%3Cusername%3E%5Cw+)/wiki//testslug'

 If I include the username argument:

 >>> reverse('userwikis:wiki-view',
 kwargs={'username':'bar','slug':'testslug'})
 NoReverseMatch: Reverse for 'wiki-view' with arguments '()' and keyword
 arguments '{'username': 'bar', 'slug': 'testslug'}' not found.

 Seems like a fairly nasty bug for 1.1? Especially as url namespaces are
 one of the headline features of 1.1.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #11565: Rate Limit Error Emails

[Django]

#11565: Rate Limit Error Emails
+---
 Reporter:  andrewmintel|   Owner:  nobody
   Status:  new |   Milestone:
Component:  Core framework  | Version:  SVN   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  1   |  
+---
 We like the emails we receive when an exception occurs on the live site.
 However, if an error repeatedly occurs (e.g. the database goes down) we
 get spammed with a huge number of emails.

 I'm attaching a patch which will only send an email once every
 settings.ERROR_EMAIL_RATE_LIMIT minutes for each error. It determines
 whether it has sent an email about a particular error by taking an MD5 of
 the traceback and storing it in whatever cache is configured. If the same
 MD5 already exists in the cache, then it doesn't send an email.

 The big problem with this approach is what if your cache starts to produce
 errors? Certainly memcached is designed so that if the server goes away
 all keys appear not to be set, rather than an error. I'm not sure about
 how the database cache backend would work in this situation.

 Any suggestions on how to improve the patch are appreciated. If it's ok
 then I'll produce a patch for the documentation too.

 Cheers,
 Andrew

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #11564: [feature request] admin inlines enhancements

[Django]

#11564: [feature request] admin inlines enhancements
---+
 Reporter:  renton1982 |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Contrib apps   | Version:  SVN   
 Keywords:  inlines admin related objects  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 some important features in django-admin are missing on inlines:

 1) setting to allow/disallow deleting related objects

 2) inline object editing is not stored in object history

 3) deleting a inline object does delete all related objects to the inline-
 object with no warning <-- very bad and dangerous

 4) inlines can not be places between the fields without re-hacking the
 whole template

 5) inlines can not be collapsed like the fieldsets

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #11563: Models are not registered at the moment when AdminSite.get_urls() runs, only at mod_wsgi environment

[Django]

#11563: Models are not registered at the moment when AdminSite.get_urls() runs,
only at mod_wsgi environment
---+
  Reporter:  daybreaker| Owner:  nobody 
Status:  closed| Milestone:  1.1
 Component:  Contrib apps  |   Version:  SVN
Resolution:  invalid   |  Keywords:  admin urls wsgi
 Stage:  Unreviewed| Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by anonymous):

 Thanks, but I've already questioned on the IRC and nobody responded, and
 stackoverflow also didn't help me. :)

 However, I have still another question (well, should it go to
 "user"-things?) -- autodiscover() is the only way that is recommended as
 the official option? And is this a strange behaviour or not?

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #11563: Models are not registered at the moment when AdminSite.get_urls() runs, only at mod_wsgi environment

[Django]

#11563: Models are not registered at the moment when AdminSite.get_urls() runs,
only at mod_wsgi environment
---+
  Reporter:  daybreaker| Owner:  nobody 
Status:  closed| Milestone:  1.1
 Component:  Contrib apps  |   Version:  SVN
Resolution:  invalid   |  Keywords:  admin urls wsgi
 Stage:  Unreviewed| Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by Alex):

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

Comment:

 Your problem is that you should be registering with the admin in your
 admin.py file and then using admin.autodiscover() at the top of your
 urls.py.  In the future please ask user questions on either the django-
 users mailing list or the #django IRC channel on freenode.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #11563: Models are not registered at the moment when AdminSite.get_urls() runs, only at mod_wsgi environment

[Django]

#11563: Models are not registered at the moment when AdminSite.get_urls() runs,
only at mod_wsgi environment
---+
  Reporter:  daybreaker| Owner:  nobody 
Status:  new   | Milestone:  1.1
 Component:  Contrib apps  |   Version:  SVN
Resolution:|  Keywords:  admin urls wsgi
 Stage:  Unreviewed| Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by daybreaker):

 I think urls.py is also important:

 {{{
 from django.conf.urls.defaults import *
 from django.contrib import admin

 urlpatterns = patterns('',
 # my custom urls...

 # Uncomment the next line to enable the admin:
 (ur'^admin/', include(admin.site.urls)),
 )
 }}}

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #11563: Models are not registered at the moment when AdminSite.get_urls() runs, only at mod_wsgi environment

[Django]

#11563: Models are not registered at the moment when AdminSite.get_urls() runs,
only at mod_wsgi environment
---+
  Reporter:  daybreaker| Owner:  nobody 
Status:  new   | Milestone:  1.1
 Component:  Contrib apps  |   Version:  SVN
Resolution:|  Keywords:  admin urls wsgi
 Stage:  Unreviewed| Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by daybreaker):

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

Comment:

 For more information, I add some bits of my codes:

 {{{
 # in admin.py
 from django.contrib import admin
 from myproject.myapp.models import MyModel # imported for custom admin-
 actions

 class MyModelAdmin(admin.ModelAdmin):
 ...


 # in models.py
 from django.contrib import admin

 class MyModel(models.Model):
 ...

 from myproject.myapp.admin import *
 admin.site.register(MyModel, MyModelAdmin)
 }}}

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #11563: Models are not registered at the moment when AdminSite.get_urls() runs, only at mod_wsgi environment

[Django]

#11563: Models are not registered at the moment when AdminSite.get_urls() runs,
only at mod_wsgi environment
-+--
 Reporter:  daybreaker   |   Owner:  nobody
   Status:  new  |   Milestone:  1.1   
Component:  Contrib apps | Version:  SVN   
 Keywords:  admin urls wsgi  |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 I'm using Django 1.1rc1 on Python 2.5.2 + mod_wsgi 1.3.1 + Apache 2.2.8 on
 a Ubuntu machine. I have never installed python-django package on this
 machine--this is a clean custom install.

 Everything works fine when I run my project via the test server.

 But after attaching it to Apache/mod_wsgi, all `/admin/appname/modelname/`
 urls stopped to work. I've inspected
 
[http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/sites.py#L191
 the source code of Django], and used
 [http://docs.python.org/library/logging.html logging module] around the
 AdminSite class, and finally found that this problem only occurs when I
 use mod_wsgi.

 All model class registration should be done BEFORE get_urls() method runs,
 and this is correct with the internal test server, but not with mod_wsgi.

 I don't have any idea why this happens, but if this is a bug of Django, it
 seems very critical. (I hope not...)

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r11343 - in django/trunk: django/core/management/commands django/db/backends tests/regressiontests/fixtures_regress

[noreply]

Author: russellm
Date: 2009-07-27 09:32:30 -0500 (Mon, 27 Jul 2009)
New Revision: 11343

Modified:
   django/trunk/django/core/management/commands/dumpdata.py
   django/trunk/django/db/backends/creation.py
   django/trunk/tests/regressiontests/fixtures_regress/models.py
Log:
Fixed #11428 -- Ensured that SQL generating commands and dumpdata don't include 
proxy models in their output. Thanks to Anssi Kaariainen for the report.

Modified: django/trunk/django/core/management/commands/dumpdata.py
===
--- django/trunk/django/core/management/commands/dumpdata.py2009-07-27 
09:12:14 UTC (rev 11342)
+++ django/trunk/django/core/management/commands/dumpdata.py2009-07-27 
14:32:30 UTC (rev 11343)
@@ -73,7 +73,8 @@
 model_list = get_models(app)
 
 for model in model_list:
-objects.extend(model._default_manager.all())
+if not model._meta.proxy:
+objects.extend(model._default_manager.all())
 
 try:
 return serializers.serialize(format, objects, indent=indent)

Modified: django/trunk/django/db/backends/creation.py
===
--- django/trunk/django/db/backends/creation.py 2009-07-27 09:12:14 UTC (rev 
11342)
+++ django/trunk/django/db/backends/creation.py 2009-07-27 14:32:30 UTC (rev 
11343)
@@ -40,7 +40,7 @@
 from django.db import models
 
 opts = model._meta
-if not opts.managed:
+if not opts.managed or opts.proxy:
 return [], {}
 final_output = []
 table_output = []
@@ -121,7 +121,7 @@
 "Returns any ALTER TABLE statements to add constraints after the fact."
 from django.db.backends.util import truncate_name
 
-if not model._meta.managed:
+if not model._meta.managed or model._meta.proxy:
 return []
 qn = self.connection.ops.quote_name
 final_output = []
@@ -236,7 +236,7 @@
 
 def sql_indexes_for_model(self, model, style):
 "Returns the CREATE INDEX SQL statements for a single model"
-if not model._meta.managed:
+if not model._meta.managed or model._meta.proxy:
 return []
 output = []
 for f in model._meta.local_fields:
@@ -268,7 +268,7 @@
 
 def sql_destroy_model(self, model, references_to_delete, style):
 "Return the DROP TABLE and restraint dropping statements for a single 
model"
-if not model._meta.managed:
+if not model._meta.managed or model._meta.proxy:
 return []
 # Drop the table now
 qn = self.connection.ops.quote_name
@@ -286,7 +286,7 @@
 def sql_remove_table_constraints(self, model, references_to_delete, style):
 from django.db.backends.util import truncate_name
 
-if not model._meta.managed:
+if not model._meta.managed or model._meta.proxy:
 return []
 output = []
 qn = self.connection.ops.quote_name

Modified: django/trunk/tests/regressiontests/fixtures_regress/models.py
===
--- django/trunk/tests/regressiontests/fixtures_regress/models.py   
2009-07-27 09:12:14 UTC (rev 11342)
+++ django/trunk/tests/regressiontests/fixtures_regress/models.py   
2009-07-27 14:32:30 UTC (rev 11343)
@@ -54,7 +54,7 @@
 class Child(Parent):
 data = models.CharField(max_length=10)
 
-# Models to regresison check #7572
+# Models to regression test #7572
 class Channel(models.Model):
 name = models.CharField(max_length=255)
 
@@ -65,6 +65,14 @@
 class Meta:
 ordering = ('id',)
 
+# Models to regression test #11428
+class Widget(models.Model):
+name = models.CharField(max_length=255)
+
+class WidgetProxy(Widget):
+class Meta:
+proxy = True
+
 __test__ = {'API_TESTS':"""
 >>> from django.core import management
 
@@ -170,4 +178,18 @@
 >>> management.call_command('dumpdata', 'fixtures_regress.animal', 
 >>> format='json')
 [{"pk": 1, "model": "fixtures_regress.animal", "fields": {"count": 3, 
"weight": 1.2, "name": "Lion", "latin_name": "Panthera leo"}}, {"pk": 2, 
"model": "fixtures_regress.animal", "fields": {"count": 2, "weight": 2.29..., 
"name": "Platypus", "latin_name": "Ornithorhynchus anatinus"}}, {"pk": 10, 
"model": "fixtures_regress.animal", "fields": {"count": 42, "weight": 1.2, 
"name": "Emu", "latin_name": "Dromaius novaehollandiae"}}]
 
+###
+# Regression for #11428 - Proxy models aren't included
+# when you run dumpdata over an entire app
+
+# Flush out the database first
+>>> management.call_command('reset', 'fixtures_regress', interactive=False, 
verbosity=0)
+
+# Create an instance of the concrete class
+>>> Widget(name='grommet').save()
+
+# Dump data for the entire app. The proxy class shouldn't be included
+>>> management.call_command('dumpdata', 'fixtu

Re: [Django] #11562: Error in regular exression for EmailField validation

[Django]

#11562: Error in regular exression for EmailField validation
-+--
  Reporter:  HuCy| Owner:  nobody
Status:  closed  | Milestone:
 Component:  Forms   |   Version:  SVN   
Resolution:  invalid |  Keywords:  emailfield
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by kmtracey):

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

Comment:

 r10573 fixed the regex to disallow hyphens except in the interior of a
 label, and that changeset includes tests that verify that email addresses
 with domain names beginning with a hyphen do  not validate.  If there is
 really still a problem, please reopen with more specifics on exactly what
 invalid email address, for example, you still observe passing validation
 with current code in SVN.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #11562: Error in regular exression for EmailField validation

[Django]

#11562: Error in regular exression for EmailField validation
+---
 Reporter:  HuCy|   Owner:  nobody
   Status:  new |   Milestone:
Component:  Forms   | Version:  SVN   
 Keywords:  emailfield  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 As RFC 1035 states:

 The labels must follow the rules for ARPANET host names.  They must
 start with a letter, end with a letter or digit, and have as interior
 characters only letters, digits, and hyphen.  There are also some
 restrictions on the length.  Labels must be 63 characters or less.

 Though the regular expression allows domainnames to begin with a hyphen.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #5390: Add signals to ManyRelatedManager

[Django]

#5390: Add signals to ManyRelatedManager
--+-
  Reporter:  Ludovico Magnocavallo   | Owner:  
rvdrijst   
Status:  assigned | Milestone:  
   
 Component:  Database layer (models, ORM) |   Version:  SVN 
   
Resolution:   |  Keywords:  
manytomanyfield feature signals
 Stage:  Design decision needed   | Has_patch:  1   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  0|  
--+-
Changes (by msurdi):

 * cc: matiassu...@gmail.com (added)

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #11163: admin ForeignKeyRawIdWidget contains incorrect link when used in change list view

[Django]

#11163: admin ForeignKeyRawIdWidget contains incorrect link when used in change
list view
---+
  Reporter:  margierogin...@yahoo.com  | Owner:  nobody   
Status:  reopened  | Milestone:   
 Component:  django.contrib.admin  |   Version:  SVN  
Resolution:|  Keywords:  raw_id_fields
 Stage:  Unreviewed| Has_patch:  1
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by Guilherme Gondim ):

 * cc: seme...@taurinus.org (added)

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #5515: CSRF has hard-encoded error page

[Django]

#5515: CSRF has hard-encoded error page
+---
  Reporter:  Piotr Lewandowski   | 
Owner: 
Status:  closed | 
Milestone: 
 Component:  Contrib apps   |   
Version:  SVN
Resolution:  duplicate  |  
Keywords: 
 Stage:  Design decision needed | 
Has_patch:  1  
Needs_docs:  0  |   
Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Comment (by anonymous):

 Does the patch in #9977 provide for a 403.html template for
 PermissionDenied errors? I just installed this patch so I could create
 user-friendly Permimssion Denied pages.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #11561: raw_id_fields requires that the user has change permissions on the model class that is being linked to

[Django]

#11561: raw_id_fields requires that the user has change permissions on the model
class that is being linked to
---+
 Reporter:  dhow...@gmail.com  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  django.contrib.admin   | Version:  1.0   
 Keywords:  raw_if_fields permissions  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Unlike a plain ForeignKey field which uses a select box, the raw_id_fields
 listing/search interface requires that the user has change permissions on
 the model in your ForeignKey.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r11342 - django/branches/releases/1.0.X/django/conf/locale/it/LC_MESSAGES

[noreply]

Author: tekNico
Date: 2009-07-27 04:12:14 -0500 (Mon, 27 Jul 2009)
New Revision: 11342

Modified:
   django/branches/releases/1.0.X/django/conf/locale/it/LC_MESSAGES/django.mo
   django/branches/releases/1.0.X/django/conf/locale/it/LC_MESSAGES/django.po
Log:
[1.0.X] Italian translation: further corrections

Modified: 
django/branches/releases/1.0.X/django/conf/locale/it/LC_MESSAGES/django.mo
===
(Binary files differ)

Modified: 
django/branches/releases/1.0.X/django/conf/locale/it/LC_MESSAGES/django.po
===
--- django/branches/releases/1.0.X/django/conf/locale/it/LC_MESSAGES/django.po  
2009-07-27 09:11:41 UTC (rev 11341)
+++ django/branches/releases/1.0.X/django/conf/locale/it/LC_MESSAGES/django.po  
2009-07-27 09:12:14 UTC (rev 11342)
@@ -6,8 +6,8 @@
 msgstr ""
 "Project-Id-Version: Django 1.0.3\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2009-07-26 18:55+0200\n"
-"PO-Revision-Date: 2009-07-26 19:15+0200\n"
+"POT-Creation-Date: 2009-07-27 11:12+0200\n"
+"PO-Revision-Date: 2009-07-27 11:10+0200\n"
 "Last-Translator: Nicola Larosa \n"
 "Language-Team: Italian \n"
 "MIME-Version: 1.0\n"
@@ -202,7 +202,7 @@
 
 #: conf/global_settings.py:90
 msgid "Thai"
-msgstr "thai"
+msgstr "tailandese"
 
 #: conf/global_settings.py:91
 msgid "Turkish"
@@ -2140,7 +2140,7 @@
 
 #: contrib/localflavor/de/de_states.py:20
 msgid "Thuringia"
-msgstr "Thuringia"
+msgstr "Turingia"
 
 #: contrib/localflavor/de/forms.py:14 contrib/localflavor/fi/forms.py:12
 #: contrib/localflavor/fr/forms.py:15
@@ -3525,27 +3525,27 @@
 
 #: contrib/localflavor/uk/uk_regions.py:55
 msgid "County Antrim"
-msgstr "County Antrim"
+msgstr "Contea di Antrim"
 
 #: contrib/localflavor/uk/uk_regions.py:56
 msgid "County Armagh"
-msgstr "County Armagh"
+msgstr "Contea di Armagh"
 
 #: contrib/localflavor/uk/uk_regions.py:57
 msgid "County Down"
-msgstr "County Down"
+msgstr "Contea di Down"
 
 #: contrib/localflavor/uk/uk_regions.py:58
 msgid "County Fermanagh"
-msgstr "County Fermanagh"
+msgstr "Contea di Fermanagh"
 
 #: contrib/localflavor/uk/uk_regions.py:59
 msgid "County Londonderry"
-msgstr "County Londonderry"
+msgstr "Contea di Londonderry"
 
 #: contrib/localflavor/uk/uk_regions.py:60
 msgid "County Tyrone"
-msgstr "County Tyrone"
+msgstr "Contea di Tyrone"
 
 #: contrib/localflavor/uk/uk_regions.py:64
 msgid "Clwyd"


--~--~-~--~~~---~--~~
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r11341 - django/trunk/django/conf/locale/it/LC_MESSAGES

[noreply]

Author: tekNico
Date: 2009-07-27 04:11:41 -0500 (Mon, 27 Jul 2009)
New Revision: 11341

Modified:
   django/trunk/django/conf/locale/it/LC_MESSAGES/django.mo
   django/trunk/django/conf/locale/it/LC_MESSAGES/django.po
Log:
Italian translation: further corrections

Modified: django/trunk/django/conf/locale/it/LC_MESSAGES/django.mo
===
(Binary files differ)

Modified: django/trunk/django/conf/locale/it/LC_MESSAGES/django.po
===
--- django/trunk/django/conf/locale/it/LC_MESSAGES/django.po2009-07-27 
04:21:31 UTC (rev 11340)
+++ django/trunk/django/conf/locale/it/LC_MESSAGES/django.po2009-07-27 
09:11:41 UTC (rev 11341)
@@ -6,8 +6,8 @@
 msgstr ""
 "Project-Id-Version: django\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2009-07-26 17:43+0200\n"
-"PO-Revision-Date: 2009-07-26 19:15+0200\n"
+"POT-Creation-Date: 2009-07-27 11:12+0200\n"
+"PO-Revision-Date: 2009-07-27 11:10+0200\n"
 "Last-Translator: Nicola Larosa \n"
 "Language-Team: Italian \n"
 "MIME-Version: 1.0\n"
@@ -202,7 +202,7 @@
 
 #: conf/global_settings.py:90
 msgid "Thai"
-msgstr "thai"
+msgstr "tailandese"
 
 #: conf/global_settings.py:91
 msgid "Turkish"
@@ -2271,7 +2271,7 @@
 
 #: contrib/localflavor/de/de_states.py:20
 msgid "Thuringia"
-msgstr "Thuringia"
+msgstr "Turingia"
 
 #: contrib/localflavor/de/forms.py:14 contrib/localflavor/fi/forms.py:12
 #: contrib/localflavor/fr/forms.py:15
@@ -3647,27 +3647,27 @@
 
 #: contrib/localflavor/uk/uk_regions.py:55
 msgid "County Antrim"
-msgstr "County Antrim"
+msgstr "Contea di Antrim"
 
 #: contrib/localflavor/uk/uk_regions.py:56
 msgid "County Armagh"
-msgstr "County Armagh"
+msgstr "Contea di Armagh"
 
 #: contrib/localflavor/uk/uk_regions.py:57
 msgid "County Down"
-msgstr "County Down"
+msgstr "Contea di Down"
 
 #: contrib/localflavor/uk/uk_regions.py:58
 msgid "County Fermanagh"
-msgstr "County Fermanagh"
+msgstr "Contea di Fermanagh"
 
 #: contrib/localflavor/uk/uk_regions.py:59
 msgid "County Londonderry"
-msgstr "County Londonderry"
+msgstr "Contea di Londonderry"
 
 #: contrib/localflavor/uk/uk_regions.py:60
 msgid "County Tyrone"
-msgstr "County Tyrone"
+msgstr "Contea di Tyrone"
 
 #: contrib/localflavor/uk/uk_regions.py:64
 msgid "Clwyd"


--~--~-~--~~~---~--~~
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #6507: [proposal] Create extension to Python Cookie module

[Django]

#6507: [proposal] Create extension to Python Cookie module
+---
  Reporter:  dcramer| Owner:  nobody
Status:  new| Milestone:  1.2   
 Component:  HTTP handling  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Someday/Maybe  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  1 
Needs_better_patch:  0  |  
+---
Changes (by qingfeng):

  * milestone:  => 1.2

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---