date:20090213

Re: [Django] #4656: Allow In-depth serialization by specifying depth to follow relationship

2009-02-13 Thread Django

#4656: Allow In-depth serialization by specifying depth to follow relationship
-+--
  Reporter:  jay.m.mar...@gmail.com  | Owner:  nobody  
Status:  new | Milestone:  post-1.0
 Component:  Serialization   |   Version:  SVN 
Resolution:  |  Keywords:  feature 
 Stage:  Accepted| Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Comment (by Matthew Flanagan ):

 Eric,

 Thanks for taking the time to look at it. I'll rework it as a patch on
 Django's own serializers but I wrote it as a standalone module that can be
 added to a project using the SERIALIZATION_MODULES setting so I didn't
 have to maintain it as a patch against Django trunk in my own projects.

 The extras functionality is a DRY thing for me e.g. putting things like
 get_absolute_url into JSON or other simple non-field properties/methods
 that I don't want to repeat the logic for in my templates. I'm using extjs
 grids for presenting data in an enterprise app and all the grid rows are
 populated with AJAX calls to a REST API using this serializer.

 The relations approach is based off how Rails does it. I'm not
 reimplementing the queryset api nor performng any filtering but specifying
 arguments to pass to subsequent calls to serialize() on each related or
 sub-related object. See handle_fk_field() in
 http://wadofstuff.googlecode.com/svn/trunk/python/django/serializers/python.py
 for gory details.

 For example

 {{{
 
relations={'permissions':{'relations':{'content_type':{'excludes':('app_label',)}
 }}}
 }}}

 Sort of breaks down to pseudocode to:
 {{{
Serialize each permissions relation
 Serialize each content_type relation excluding the app_label field
 }}}

 I find exclusion very handy and quite succinct. Which would you prefer to
 write to exclude a User's password from being serialized:

 {{{
 serializers.serialize('json', User.objects.all(), excludes=('password',))
 }}}

 or

 {{{
 serializers.serialize('json', User.objects.all(), fields=('username',
 'first_name', 'last_name', 'email', 'is_staff', 'is_active',
 'is_superuser', 'last_login', 'date_joined', 'groups', 'user_permissions')
 }}}

-- 
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] #10264: image fileds hard drive storage and database storage in windows conflic names

2009-02-13 Thread Django

#10264: image fileds hard drive storage and database storage in windows conflic
names
--+-
 Reporter:  anonymous |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  File uploads/storage  | Version:  1.0   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 when i trie to upload an image it works properly in windows but when i
 upload my project into linux server i realized that it does not work
 properly because django renames my file name into lowercase and saves that
 into database but it uploads the file withe the real name uppercase in to
 the hard drive itis needed to solve this problem

 thanks
 Mohammad Rafiee
 parsiTech

-- 
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] #4656: Allow In-depth serialization by specifying depth to follow relationship

2009-02-13 Thread Django

#4656: Allow In-depth serialization by specifying depth to follow relationship
-+--
  Reporter:  jay.m.mar...@gmail.com  | Owner:  nobody  
Status:  new | Milestone:  post-1.0
 Component:  Serialization   |   Version:  SVN 
Resolution:  |  Keywords:  feature 
 Stage:  Accepted| Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Comment (by ericholscher):

 Matthew,

 This is some interesting work. I like a lot of the concepts (and following
 relations on serialization is something that I have had to hack myself).
 First off, can you attach a patch on django that shows what you are
 changing instead of posting files. This makes it a lot easier to see what
 you are proposing.

 I think that the excludes functionality is something that is really
 useful. We have the fields option that allows you to be inclusive of
 fields, I think that an "everything but this one" is a useful shortcut.
 Given, it is still possible just by including everything else. I think
 that this is a good idea.

 The extras functionality is interesting, but I don't see a lot of the
 value in it. If you're including the output of functions based on the
 data, why not just include the data? I understand that in your writeup it
 is a trivial example, but I think serializing the output of functions is
 not wise. Functions change a lot more often than model fields, and it
 isn't guarenteed that you can really "deserialize" a function. I'm curious
 how you're implementing this (or if it's even possible). I think it is an
 interesting idea perhaps to provide some kind of documentation inside of
 the fixture, and might have other uses.

 In your implementation of relations you are taking another "include these"
 approach. In the above ticket it talks about having something along those
 lines, but having you be able to specify a depth, and it follows all
 relationsips. That said, the API that you've implemented for the relations
 stuff is a bit cumbersome.

 {{{
 
relations={'permissions':{'relations':{'content_type':{'excludes':('app_label',)
 }}}

 just screams out of a better way of being represented. It seems like
 you're trying to almost reimplement the queryset api. I think that a lot
 of this filtering functionality can come from the queryset that you are
 passing in to be serialized.

 I think that having serializers just dump out all of the relations a model
 points to might lead to some problems, and if included in Django it will
 probably be optional, and off by default. I know the snippet
 http://www.djangosnippets.org/snippets/918/ has implemented ForeignKey and
 ManytoMany relationships, along with adding a "slicing" syntax to
 serializers. The slicing part is for another ticket, but that code might
 be a good reference for trying to have fixtures span relationships.

 So in summary, I think having serializers spanning relationships is a big
 win. The exclusion syntax on the serializer seems like it should be
 included for completeness and because it is useful. The other two bits of
 functionality certainly seem useful, but are probably a bit too specific
 to go into Django. They work nicely as a third party app.

-- 
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] #4656: Allow In-depth serialization by specifying depth to follow relationship

2009-02-13 Thread Django

#4656: Allow In-depth serialization by specifying depth to follow relationship
-+--
  Reporter:  jay.m.mar...@gmail.com  | Owner:  nobody  
Status:  new | Milestone:  post-1.0
 Component:  Serialization   |   Version:  SVN 
Resolution:  |  Keywords:  feature 
 Stage:  Accepted| Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by Matthew Flanagan ):

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

Comment:

 Added some documentation and examples on how to use the classes here
 http://code.google.com/p/wadofstuff/wiki/DjangoFullSerializers

-- 
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] #10263: order_by parameter for inlineformset_factory and BaseInlineFormSet

2009-02-13 Thread Django

#10263: order_by parameter for inlineformset_factory and BaseInlineFormSet
--+-
 Reporter:  Paulo Scardine | 
  Owner:  nobody
   Status:  new   |   
Milestone:
Component:  Forms | 
Version:  1.0   
 Keywords:  inlineformset_factory BaseInlineFormSet inline model formset  | 
  Stage:  Unreviewed
Has_patch:  1 |  
--+-
 == Problem ==

 At inlineformset_factory and BaseInlineFormSet constructor there is no
 option to specify order_by criteria for the resulting queryset.

 The record order at the rendered formset will depend on the order returned
 by the database layer; notably PostgreSQL may change this order after
 every update. When using PRG (Post/Redirect/Get) the result is unpleasant
 and may confuse users.

 == Proposed Solution ==

 I would like to add an order_by parameter to inlineformset_factory and
 BaseInlineFormSet.

-- 
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] #7052: auth fixture fails to import when running test server

2009-02-13 Thread Django

#7052: auth  fixture fails to import when running test server
+---
  Reporter:  jb0t   | Owner:  nobody
 
Status:  new| Milestone:
 
 Component:  Serialization  |   Version:  SVN   
 
Resolution: |  Keywords:  auth_permission 
auth_content fixture import
 Stage:  Accepted   | Has_patch:  0 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  0  |  
+---
Changes (by msaelices):

 * cc: msaelices (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] #10261: Allow to clear object before deleting to avoid data loss because delete cascade behaviour

2009-02-13 Thread Django

#10261: Allow to clear object before deleting to avoid data loss because delete
cascade behaviour
---+
  Reporter:  msaelices | Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:  duplicate |  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by Alex):

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

Comment:

 Dupe of #10262

-- 
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] #10262: Allow to clear object before deleting to avoid data loss because delete cascade behaviour

2009-02-13 Thread Django

#10262: Allow to clear object before deleting to avoid data loss because delete
cascade behaviour
--+-
 Reporter:  msaelices |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.0   
 Keywords:|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 Imaging a model like this:
 {{{
 #!python
 class Master(models.Model):
 name = models.CharField(max_length=100)


 class Slave(models.Model):
 name = models.CharField(max_length=100)
 master = models.ForeignKey(Master, null=True)
 }}}

 And this object creation:
 {{{
 #!python
 >>> m1 = Master.objects.create(name="master1")
 >>> s1 = Slave.objects.create(name="slave1", master=m1)

 >>> m1.delete() # this will also delete s1
 }}}

 Django by default, delete in cascade all related objects... even with
 {{{null=True}}}.

 If you want to avoid this, you can do this:
 {{{
 #!python
 >>> m1.slave_set.clear()
 >>> m1.delete()
 }}}

 This is ok, but it was wonderful if I can change behaviour to not delete
 cascade. You can think in admin site for example. If you want to delete a
 Category object you have previously to enter in maybe a hundred objects to
 set null by hand.

 I propose a definition like this:
 {{{
 #!python
 class Slave(models.Model):
 name = models.CharField(max_length=100)
 master = models.ForeignKey(Master, null=True, delete_cascade=False)
 }}}

 With {{{delete_cascade=False}}} (by default would be {{{True}}}),
 {{{delete()}}} method will clear this relation previously deletion.

 I've attached a patch that implements this idea.

-- 
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] #10261: Allow to clear object before deleting to avoid data loss because delete cascade behaviour

2009-02-13 Thread Django

#10261: Allow to clear object before deleting to avoid data loss because delete
cascade behaviour
--+-
 Reporter:  msaelices |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.0   
 Keywords:|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 Imaging a model like this:
 {{{
 #!python
 class Master(models.Model):
 name = models.CharField(max_length=100)


 class Slave(models.Model):
 name = models.CharField(max_length=100)
 master = models.ForeignKey(Master, null=True)
 }}}

 And this object creation:
 {{{
 #!python
 >>> m1 = Master.objects.create(name="master1")
 >>> s1 = Slave.objects.create(name="slave1", master=m1)

 >>> m1.delete() # this will also delete s1
 }}}

 Django by default, delete in cascade all related objects... even with
 {{{null=True}}}.

 If you want to avoid this, you can do this:
 {{{
 #!python
 >>> m1.slave_set.clear()
 >>> m1.delete()
 }}}

 This is ok, but it was wonderful if I can change behaviour to not delete
 cascade. You can think in admin site for example. If you want to delete a
 Category object you have previously to enter in maybe a hundred objects to
 set null by hand.

 I propose a definition like this:
 {{{
 #!python
 class Slave(models.Model):
 name = models.CharField(max_length=100)
 master = models.ForeignKey(Master, null=True, delete_cascade=False)
 }}}

 With {{{delete_cascade=False}}} (by default would be {{{True}}}),
 {{{delete()}}} method will clear this relation previously deletion.

 I've attached a patch that implements this idea.

-- 
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] #10251: Problem with inheritance plus explicit primary_key in child model

2009-02-13 Thread Django

#10251: Problem with inheritance plus explicit primary_key in child model
---+
  Reporter:  kmtracey  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by Alex):

 I'm not advocating the optimization here(well I suppose I am, but it's
 incidental) the point is optimizations of that nature are easier to do if
 this is disallowed, because otherwise we have to trace the entire chain of
 pks and find if any of them aren't actually the parent link.

-- 
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] #10251: Problem with inheritance plus explicit primary_key in child model

2009-02-13 Thread Django

#10251: Problem with inheritance plus explicit primary_key in child model
---+
  Reporter:  kmtracey  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by mtredinnick):

 You can't have two primary keys on a database table (by definition).
 However, we already support non-primary-key links to parent models (due to
 supporting multiple inheritance), so that's why this probably should just
 work. It's just an oversight in an edge-case and should be relatively
 simple to fix. This isn't the place to advocate for the "nifty
 optimisation" in the other ticket. That's independent of 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] #10251: Problem with inheritance plus explicit primary_key in child model

2009-02-13 Thread Django

#10251: Problem with inheritance plus explicit primary_key in child model
---+
  Reporter:  kmtracey  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 I wouldn't cry if we made this an error.

 However, since multi-inheritance is permitted, it's clearly not a
 ''requirement'' of the internals that all relations to parent models are
 primary keys. So maybe we can accommodate 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] #9394: Reverse relation lookups with a multi-table inherited model produces extraneous queries

2009-02-13 Thread Django

#9394: Reverse relation lookups with a multi-table inherited model produces
extraneous queries
---+
  Reporter:  ikelly| Owner:  mtredinnick
Status:  assigned  | Milestone: 
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by Alex):

 If the decision on 10251 is that it's disallowed(which I personally favor)
 then the patch I supplied should work fine and remedy the issue.

-- 
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] #9394: Reverse relation lookups with a multi-table inherited model produces extraneous queries

2009-02-13 Thread Django

#9394: Reverse relation lookups with a multi-table inherited model produces
extraneous queries
---+
  Reporter:  ikelly| Owner:  mtredinnick
Status:  assigned  | Milestone: 
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by JasonCreighton):

 See #10251 in relation to having a separate primary key for the child
 class.

-- 
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] #9394: Reverse relation lookups with a multi-table inherited model produces extraneous queries

2009-02-13 Thread Django

#9394: Reverse relation lookups with a multi-table inherited model produces
extraneous queries
---+
  Reporter:  ikelly| Owner:  mtredinnick
Status:  assigned  | Milestone: 
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by Alex):

 On further review this patch would break when you have an subclass that
 has a primary key that isn't the parent link, is that allowed?

-- 
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] #10260: i18n documentation refactoring

2009-02-13 Thread Django

#10260: i18n documentation refactoring
+---
  Reporter:  ramiro | Owner:  nobody
  
Status:  new| Milestone:
  
 Component:  Documentation  |   Version:  SVN   
  
Resolution: |  Keywords:  l10n i18n translation 
message files localization intrnationalization
 Stage:  Unreviewed | Has_patch:  1 
  
Needs_docs:  0  |   Needs_tests:  0 
  
Needs_better_patch:  0  |  
+---
Changes (by ramiro):

  * keywords:  => l10n i18n translation message files localization
   intrnationalization
  * needs_better_patch:  => 0
  * has_patch:  0 => 1
  * needs_tests:  => 0
  * needs_docs:  => 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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #10260: i18n documentation refactoring

2009-02-13 Thread Django

#10260: i18n documentation refactoring
---+
 Reporter:  ramiro |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 The attached code reshuffles and modifies the internationalization docs in
 the following way:

  * Divided the documentation in: An introductory document (with links to
 the other docs and to a couple of external resources) plus thee documents
 describing different tasks: internationalization, localization and
 deployment.
  * i18n doc: Consolidated the sections that talk about ''lazy
 translations'' and put the ''Pluralization'' section before them.
  * Put the sections about !JavaScript on the i18n doc and at the same
 level as the Python and template translatable string marking up sections,
 only a section about how to extract and compile message catalogs from JS
 has been kept in the l10n doc.
  * Removed the content about translating Django itself that was scattered
 all over the document(s). Because of that it  wasn't helpful to the minor
 audience interested in it and confused things for the major audience:
 people dealing with apps i18n. Moved the non-redundant text to the already
 existing relevant `internals/contributing.txt` section.
  * Moved text about how to create a minimal Django translation (to be able
 to activate an app translation to a given language) from the locale
 middleware notes (now in the deployment doc) to the l10n doc, leaving only
 a small note and a reference. The description of Django ''technical
 messages'' got moved to `internals/contributing.txt`.
  * Put the ''gettext on win32'' section on the l10n doc.
  * Small typo fixes.
  * Unfied treatment given to `.po` files. They are now refered to as
 ''message files'' in all documents. The section about creating/updating
 these files from !JavaScript code refered to them as ''message catalogs'',
 it wasn´t wrong but was inconsistent and could be confused with a
 different thing: the data served by the `javascript_catalog` (the section
 describing it does even calls it ''message catalogs'')

 '''Things for further thought:'''

  * What to do with the ''Using translations in your own projects'' section
 (now on the l10n doc)? Currently it's a mix of things (duplicate info, app
 architecture, integration and deployment advice).
  * Move some content to the ``howto/`` Django doc sub-tree?

-- 
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] #9394: Reverse relation lookups with a multi-table inherited model produces extraneous queries

2009-02-13 Thread Django

#9394: Reverse relation lookups with a multi-table inherited model produces
extraneous queries
---+
  Reporter:  ikelly| Owner:  mtredinnick
Status:  assigned  | Milestone: 
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by JasonCreighton):

 I'm running into what I think is the same bug. I'm using 1.0.2. Given
 these models:

 {{{
 class Base(models.Model):
 base_info = models.CharField(max_length=50)

 class Extra(Base):
 extra_info = models.CharField(max_length=50)

 class ExtraRelatedData(models.Model):
 extra = models.ForeignKey(Extra)
 related_data = models.CharField(max_length=50)
 }}}

 And some pre-populated data:

 {{{
 >>> e = Extra(base_info="foo", extra_info="bar")
 >>> e.save()
 >>> ed = ExtraRelatedData(extra=e, related_data="quux")
 >>> ed.save()
 }}}

 If I later run:

 {{{
 >>> e = Extra.objects.get(pk=1)
 >>> ExtraRelatedData.objects.filter(extra=e)
 []
 >>> for q in connection.queries: print repr(q)
 ...
 {'time': '0.001', 'sql': u'SELECT
 "inheritance_base"."id", "inheritance_base"."base_info",
 "inheritance_extra"."base_ptr_id", "inheritance_extra"."extra_info"
 FROM "inheritance_extra"
 INNER JOIN "inheritance_base" ON ("inheritance_extra"."base_ptr_id" =
 "inheritance_base"."id")
 WHERE "inheritance_extra"."base_ptr_id" = 1 '}
 {'time': '0.000', 'sql': u'SELECT
 "inheritance_base"."id", "inheritance_base"."base_info"
 FROM "inheritance_base" WHERE "inheritance_base"."id" = 1 '}
 {'time': '0.000', 'sql': u'SELECT
 "inheritance_extrarelateddata"."id",
 "inheritance_extrarelateddata"."extra_id",
 "inheritance_extrarelateddata"."related_data"
 FROM "inheritance_extrarelateddata"
 WHERE "inheritance_extrarelateddata"."extra_id" = 1  LIMIT 21'}
 }}}

 Even though "e" is already loaded, Django loads it again. (To get the pk?)
 I can workaround it like so:

 {{{
 >>> e = Extra.objects.get(pk=1)
 >>> ExtraRelatedData.objects.filter(extra__pk=e.pk)
 []
 >>> for q in connection.queries: print repr(q)
 ...
 {'time': '0.001', 'sql': u'SELECT
 "inheritance_base"."id", "inheritance_base"."base_info",
 "inheritance_extra"."base_ptr_id", "inheritance_extra"."extra_info"
 FROM "inheritance_extra"
 INNER JOIN "inheritance_base" ON ("inheritance_extra"."base_ptr_id" =
 "inheritance_base"."id")
 WHERE "inheritance_extra"."base_ptr_id" = 1 '}
 {'time': '0.000', 'sql': u'SELECT
 "inheritance_extrarelateddata"."id",
 "inheritance_extrarelateddata"."extra_id",
 "inheritance_extrarelateddata"."related_data"
 FROM "inheritance_extrarelateddata"
 WHERE "inheritance_extrarelateddata"."extra_id" = 1  LIMIT 21'}
 }}}

 [ SQL reformatted slightly ]

 It seems completely wrong to me that there's a case where
 {{{filter(foo=foo)}}} is not that same as {{{filter(foo__pk=foo.pk)}}}.

 So is this the same bug, or should I open a new ticket?

-- 
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] #10246: Bug with Inlines for non-standard primary keys

2009-02-13 Thread Django

#10246: Bug with Inlines for non-standard primary keys
---+
  Reporter:  cklein| Owner:  nobody  
Status:  closed| Milestone:  post-1.0
 Component:  django.contrib.admin  |   Version:  1.0 
Resolution:  duplicate |  Keywords:  
 Stage:  Unreviewed| Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

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

Comment:

 Duplicate of #8903

-- 
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] #9650: Initial value for CharField primary key is not hidden in admin's inline form

2009-02-13 Thread Django

#9650: Initial value for CharField primary key is not hidden in admin's inline
form
---+
  Reporter:  Tarken| Owner:  nobody
Status:  closed| Milestone:
 Component:  django.contrib.admin  |   Version:  1.0   
Resolution:  duplicate |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

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

Comment:

 Duplicate of #8903

-- 
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] #937: Autoreload reloads for every request.

2009-02-13 Thread Django

#937: Autoreload reloads for every request.
+---
  Reporter:  ric...@entrian.com | Owner:  adrian
Status:  reopened   | Milestone:
 Component:  django-admin.py runserver  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by anonymous):

 == ''


 {{{
 [[BR]]
 ''
 }}}
 '' ==

-- 
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] #10259: Error in Mac OS X installation documentation

2009-02-13 Thread Django

#10259: Error in Mac OS X installation documentation
---+
 Reporter:  davegallagher  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 This refers to this webpage:
 http://docs.djangoproject.com/en/dev/misc/distributions/#misc-
 distributions

 It lists running either of these two commands to install the Mac OS X
 version of Django using MacPorts.  Currently these don't work:

 Python 2.4:  sudo port install py-django-devel
 Python 2.5:  sudo port install py25-django-devel

 MacPorts probably changed the package names recently.  Here are the
 available Django packages on MacPorts:

 $ port echo *django*
 py25-django
 py26-django

 The commands in the documentation should be changed as follows:

 Python 2.4:  ...doesn't seem to exist anymore on MacPorts (I was using the
 Universal Leopard build of MacPorts)...
 Python 2.5:  sudo port install py25-django
 Python 2.6:  sudo port install py26-django

 I hope that helps!  :)

 -Dave Gallagher

-- 
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] #10254: The use of 'FileField' Upload file missing Chinese characters (non-ascii)

2009-02-13 Thread Django

#10254: The use of 'FileField' Upload file missing Chinese characters 
(non-ascii)
---+
  Reporter:  isoem...@163. com | Owner:  nobody 
 
Status:  new   | Milestone: 
 
 Component:  File uploads/storage  |   Version:  1.0
 
Resolution:|  Keywords:  FileField  
non-ascii
 Stage:  Accepted  | Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by kmtracey):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 This has been reported before, see #3119 and #6009, and apparently thought
 to have been fixed, but it isn't fixed.  (Also, near as I can tell this is
 not a recent regression, this part of the issues identified in those
 earlier tickets just was never addressed, so far as I can see).  Earlier
 there were two problems: an exception on upload of a file with non-ASCII
 chars in the name, and stripping of non-ASCII chars from the filename.
 The 1st seems to have been fixed, the 2nd is still in place.

 django/utils/text.py get_valid_filename still strips non-ASCII chars from
 the filename, and this routine is called by core/files/storage.py to
 generate a "valid" file name when a !FileField is saved.  Though r7987
 added a test to ensure that uploading files with non-ASCII names "works",
 the part of the test that checks that the name is preserved simply checks
 the file name in cleaned_data, and this stripping of non-ASCII chars is
 done long after form validation.  So while the file name remains "correct"
 in what can be seen in the form's cleaned_data, that name is stripped of
 its non-ASCII chars (and perhaps spaces are turned into underscores and
 additional underscores are appended to the name to avoid overwriting an
 existing file of the same name).  So the name you can see in cleaned_data
 isn't necessarily the name the file will be stored under.

 I don't know the right way to fix this, but the existing
 get_valid_filename in django/utils/text.py certainly seems over-
 restrictive in terms of what is an allowed character in a file name.

-- 
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] #10258: many files with the same file name cannot be saved correctly

2009-02-13 Thread Django

#10258: many files with the same file name cannot be saved correctly
--+-
 Reporter:  liangent  |   Owner:  nobody
   Status:  new   |   Milestone:  post-1.0  
Component:  File uploads/storage  | Version:  1.0   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 The current Django code add '_' to file name in order to avoid overwrite
 saved files.
 However, if I save many files with the same file name, Django will add
 many '_'s.
 If the file name is too long, file will be saved correctly, but path in
 database will be truncated.

 {{{
 /var/lib/python-support/python2.5/django/db/backends/mysql/base.py:83:
 Warning: Data truncated for column 'output' at row 1
   return self.cursor.execute(query, args)
 }}}

 Then when I try to get that file according to the path saved in database,
 it will fail...

-- 
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] #10257: documentation for form creation parameters

2009-02-13 Thread Django

#10257: documentation for form creation parameters
---+
 Reporter:  galund |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 The 'Forms API' page, where most aspects of the form class are documented,
 is missing an explanation of the 'initial' constructor argument, which is
 in fact described @ http://docs.djangoproject.com/en/dev/ref/forms/fields
 /#dynamic-initial-values

-- 
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] #10121: ImageField loses data when re-saving from admin

2009-02-13 Thread Django

#10121: ImageField loses data when re-saving from admin
---+
  Reporter:  Uninen| Owner: 

Status:  new   | Milestone: 

 Component:  django.contrib.admin  |   Version:  SVN

Resolution:|  Keywords:  admin, ImageField, 
save
 Stage:  Unreviewed| Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Comment (by ramiro):

 #10255 reported the same problem with `FileField`s and was closed as 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 this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #10255: FileField overwrite existing value with empty one

2009-02-13 Thread Django

#10255: FileField overwrite existing value with empty one
---+
  Reporter:  pierpaolodf   | Owner:  nobody   
Status:  closed| Milestone:   
 Component:  django.contrib.admin  |   Version:  SVN  
Resolution:  duplicate |  Keywords:  FileField
 Stage:  Unreviewed| Has_patch:  0
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by ramiro):

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

Comment:

 This has been already reported in #10121, although it was about
 `ImageField` I'm closing this as a duplicate because `ImageField` is a
 sublcass of `FileField`

-- 
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] #6392: django.contrib.humanize should be locale aware

2009-02-13 Thread Django

#6392: django.contrib.humanize should be locale aware
-+--
  Reporter:  telenieko   | Owner:  hlian  
Status:  assigned| Milestone: 
 Component:  Contrib apps|   Version:  SVN
Resolution:  |  Keywords:  i18n-rf
 Stage:  Design decision needed  | Has_patch:  1  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Changes (by garcia_marc):

  * keywords:  => i18n-rf

-- 
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] #10253: sessions.base.py random.SystemRandom() fails

2009-02-13 Thread Django

#10253: sessions.base.py random.SystemRandom() fails
+---
  Reporter:  monkut | Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by ramiro):

 I'd say this is either a) a Python (the project) programing bug when
 running in that platform, b) a bug in the Python package/port (if
 installed in such ways) or the set of options choosen when building python
 (if complied manually) or c) a sysadmin problem with the RNG setup in the
 system.

 In all cases, it's in a lower level of the stack than Django and it would
 be better to explore/ask for support/fill bugs with the relevant provider.

-- 
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] #8836: Translation update for Slovenian

2009-02-13 Thread Django

#8836: Translation update for Slovenian
---+
  Reporter:  gasperzejn| Owner:  nobody
Status:  closed| Milestone:  1.0   
 Component:  Translations  |   Version:  SVN   
Resolution:  fixed |  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by telenieko):

 Done. Please open a new ticket when submitting updates. Thanks!

-- 
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] r9832 - django/trunk/django/conf/locale/sl/LC_MESSAGES

2009-02-13 Thread noreply


Author: telenieko
Date: 2009-02-13 05:04:19 -0600 (Fri, 13 Feb 2009)
New Revision: 9832

Modified:
   django/trunk/django/conf/locale/sl/LC_MESSAGES/django.mo
   django/trunk/django/conf/locale/sl/LC_MESSAGES/django.po
Log:
Closes #8836, Updated translation for Slovenian.

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

Modified: django/trunk/django/conf/locale/sl/LC_MESSAGES/django.po
===
--- django/trunk/django/conf/locale/sl/LC_MESSAGES/django.po2009-02-13 
11:03:16 UTC (rev 9831)
+++ django/trunk/django/conf/locale/sl/LC_MESSAGES/django.po2009-02-13 
11:04:19 UTC (rev 9832)
@@ -7,7 +7,7 @@
 "Project-Id-Version: django\n"
 "Report-Msgid-Bugs-To: \n"
 "POT-Creation-Date: 2008-09-03 10:02+0200\n"
-"PO-Revision-Date: 2008-09-03 15:21+0200\n"
+"PO-Revision-Date: 2009-02-13 12:01+0100\n"
 "Last-Translator: Gasper Zejn \n"
 "Language-Team:  \n"
 "MIME-Version: 1.0\n"
@@ -666,7 +666,7 @@
 #: contrib/admin/templates/admin/object_history.html:30
 #: utils/translation/trans_real.py:404
 msgid "DATETIME_FORMAT"
-msgstr "N j, Y, P"
+msgstr "j. F Y, H:i:s"
 
 #: contrib/admin/templates/admin/object_history.html:38
 msgid ""
@@ -4010,19 +4010,19 @@
 
 #: utils/translation/trans_real.py:403
 msgid "DATE_FORMAT"
-msgstr "N j, Y"
+msgstr "j.n.Y"
 
 #: utils/translation/trans_real.py:405
 msgid "TIME_FORMAT"
-msgstr "P"
+msgstr "H:i:s"
 
 #: utils/translation/trans_real.py:421
 msgid "YEAR_MONTH_FORMAT"
-msgstr "YEAR_MONTH_FORMAT"
+msgstr "F Y"
 
 #: utils/translation/trans_real.py:422
 msgid "MONTH_DAY_FORMAT"
-msgstr "MONTH_DAY_FORMAT"
+msgstr "j. F"
 
 #: views/generic/create_update.py:114
 #, python-format


--~--~-~--~~~---~--~~
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] r9831 - django/branches/releases/1.0.X/django/conf/locale/sl/LC_MESSAGES

2009-02-13 Thread noreply


Author: telenieko
Date: 2009-02-13 05:03:16 -0600 (Fri, 13 Feb 2009)
New Revision: 9831

Modified:
   django/branches/releases/1.0.X/django/conf/locale/sl/LC_MESSAGES/django.mo
   django/branches/releases/1.0.X/django/conf/locale/sl/LC_MESSAGES/django.po
Log:
[1.0.X] Refs #8836, Updated translation for Slovenian.

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

Modified: 
django/branches/releases/1.0.X/django/conf/locale/sl/LC_MESSAGES/django.po
===
--- django/branches/releases/1.0.X/django/conf/locale/sl/LC_MESSAGES/django.po  
2009-02-13 10:58:40 UTC (rev 9830)
+++ django/branches/releases/1.0.X/django/conf/locale/sl/LC_MESSAGES/django.po  
2009-02-13 11:03:16 UTC (rev 9831)
@@ -7,7 +7,7 @@
 "Project-Id-Version: django\n"
 "Report-Msgid-Bugs-To: \n"
 "POT-Creation-Date: 2008-09-03 10:02+0200\n"
-"PO-Revision-Date: 2008-09-03 15:21+0200\n"
+"PO-Revision-Date: 2009-02-13 12:01+0100\n"
 "Last-Translator: Gasper Zejn \n"
 "Language-Team:  \n"
 "MIME-Version: 1.0\n"
@@ -666,7 +666,7 @@
 #: contrib/admin/templates/admin/object_history.html:30
 #: utils/translation/trans_real.py:404
 msgid "DATETIME_FORMAT"
-msgstr "N j, Y, P"
+msgstr "j. F Y, H:i:s"
 
 #: contrib/admin/templates/admin/object_history.html:38
 msgid ""
@@ -4010,19 +4010,19 @@
 
 #: utils/translation/trans_real.py:403
 msgid "DATE_FORMAT"
-msgstr "N j, Y"
+msgstr "j.n.Y"
 
 #: utils/translation/trans_real.py:405
 msgid "TIME_FORMAT"
-msgstr "P"
+msgstr "H:i:s"
 
 #: utils/translation/trans_real.py:421
 msgid "YEAR_MONTH_FORMAT"
-msgstr "YEAR_MONTH_FORMAT"
+msgstr "F Y"
 
 #: utils/translation/trans_real.py:422
 msgid "MONTH_DAY_FORMAT"
-msgstr "MONTH_DAY_FORMAT"
+msgstr "j. F"
 
 #: views/generic/create_update.py:114
 #, python-format


--~--~-~--~~~---~--~~
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] r9830 - django/branches/releases/1.0.X/django/conf/locale/ca/LC_MESSAGES

2009-02-13 Thread noreply


Author: telenieko
Date: 2009-02-13 04:58:40 -0600 (Fri, 13 Feb 2009)
New Revision: 9830

Modified:
   django/branches/releases/1.0.X/django/conf/locale/ca/LC_MESSAGES/django.mo
   django/branches/releases/1.0.X/django/conf/locale/ca/LC_MESSAGES/django.po
Log:
[1.0.X] Updated Catalan translation.

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

Modified: 
django/branches/releases/1.0.X/django/conf/locale/ca/LC_MESSAGES/django.po
===
--- django/branches/releases/1.0.X/django/conf/locale/ca/LC_MESSAGES/django.po  
2009-02-13 10:58:08 UTC (rev 9829)
+++ django/branches/releases/1.0.X/django/conf/locale/ca/LC_MESSAGES/django.po  
2009-02-13 10:58:40 UTC (rev 9830)
@@ -5,8 +5,8 @@
 msgstr ""
 "Project-Id-Version: Django\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2008-11-13 19:01+0100\n"
-"PO-Revision-Date: 2008-11-13 19:04+0100\n"
+"POT-Creation-Date: 2009-02-13 10:45+0100\n"
+"PO-Revision-Date: 2009-02-13 10:49+0100\n"
 "Last-Translator: Django Catalan Group \n"
 "Language-Team: Catalan \n"
 "MIME-Version: 1.0\n"
@@ -99,118 +99,122 @@
 msgstr "hebreu"
 
 #: conf/global_settings.py:65
+msgid "Hindi"
+msgstr "hindi"
+
+#: conf/global_settings.py:66
 msgid "Croatian"
 msgstr "croat"
 
-#: conf/global_settings.py:66
+#: conf/global_settings.py:67
 msgid "Icelandic"
 msgstr "islandès"
 
-#: conf/global_settings.py:67
+#: conf/global_settings.py:68
 msgid "Italian"
 msgstr "italià"
 
-#: conf/global_settings.py:68
+#: conf/global_settings.py:69
 msgid "Japanese"
 msgstr "japonès"
 
-#: conf/global_settings.py:69
+#: conf/global_settings.py:70
 msgid "Georgian"
 msgstr "georgià"
 
-#: conf/global_settings.py:70
+#: conf/global_settings.py:71
 msgid "Korean"
 msgstr "coreà"
 
-#: conf/global_settings.py:71
+#: conf/global_settings.py:72
 msgid "Khmer"
 msgstr "khmer"
 
-#: conf/global_settings.py:72
+#: conf/global_settings.py:73
 msgid "Kannada"
 msgstr "canès"
 
-#: conf/global_settings.py:73
+#: conf/global_settings.py:74
 msgid "Latvian"
 msgstr "letó"
 
-#: conf/global_settings.py:74
+#: conf/global_settings.py:75
 msgid "Lithuanian"
 msgstr "lituà"
 
-#: conf/global_settings.py:75
+#: conf/global_settings.py:76
 msgid "Macedonian"
 msgstr "macedoni"
 
-#: conf/global_settings.py:76
+#: conf/global_settings.py:77
 msgid "Dutch"
 msgstr "holandès"
 
-#: conf/global_settings.py:77
+#: conf/global_settings.py:78
 msgid "Norwegian"
 msgstr "norueg"
 
-#: conf/global_settings.py:78
+#: conf/global_settings.py:79
 msgid "Polish"
 msgstr "polac"
 
-#: conf/global_settings.py:79
+#: conf/global_settings.py:80
 msgid "Portuguese"
 msgstr "portuguès"
 
-#: conf/global_settings.py:80
+#: conf/global_settings.py:81
 msgid "Brazilian Portuguese"
 msgstr "portuguès de brasil"
 
-#: conf/global_settings.py:81
+#: conf/global_settings.py:82
 msgid "Romanian"
 msgstr "rumanès"
 
-#: conf/global_settings.py:82
+#: conf/global_settings.py:83
 msgid "Russian"
 msgstr "rús"
 
-#: conf/global_settings.py:83
+#: conf/global_settings.py:84
 msgid "Slovak"
 msgstr "eslovac"
 
-#: conf/global_settings.py:84
+#: conf/global_settings.py:85
 msgid "Slovenian"
 msgstr "esloveni"
 
-#: conf/global_settings.py:85
+#: conf/global_settings.py:86
 msgid "Serbian"
 msgstr "serbi"
 
-#: conf/global_settings.py:86
+#: conf/global_settings.py:87
 msgid "Swedish"
 msgstr "suec"
 
-#: conf/global_settings.py:87
+#: conf/global_settings.py:88
 msgid "Tamil"
 msgstr "tàmil"
 
-#: conf/global_settings.py:88
+#: conf/global_settings.py:89
 msgid "Telugu"
 msgstr "telugu"
 
-#: conf/global_settings.py:89
+#: conf/global_settings.py:90
 msgid "Thai"
 msgstr "tailandès"
 
-#: conf/global_settings.py:90
+#: conf/global_settings.py:91
 msgid "Turkish"
 msgstr "turc"
 
-#: conf/global_settings.py:91
+#: conf/global_settings.py:92
 msgid "Ukrainian"
 msgstr "ucranià"
 
-#: conf/global_settings.py:92
+#: conf/global_settings.py:93
 msgid "Simplified Chinese"
 msgstr "xinès simplificat"
 
-#: conf/global_settings.py:93
+#: conf/global_settings.py:94
 msgid "Traditional Chinese"
 msgstr "xinès tradicional"
 
@@ -298,7 +302,7 @@
 msgstr "Modificat %s."
 
 #: contrib/admin/options.py:338 contrib/admin/options.py:348
-#: contrib/comments/templates/comments/preview.html:15 forms/models.py:288
+#: contrib/comments/templates/comments/preview.html:15 forms/models.py:294
 msgid "and"
 msgstr "i"
 
@@ -321,13 +325,13 @@
 msgid "No fields changed."
 msgstr "Cap camp canviat."
 
-#: contrib/admin/options.py:417 contrib/auth/admin.py:51
+#: contrib/admin/options.py:417 contrib/auth/admin.py:61
 #, python-format
 msgid "The %(name)s \"%(obj)s\" was added successfully."
 msgstr "El/la %(name)s \"%(obj)s\".ha estat afegit/da amb èxit."
 
 #: contrib/admin/options.py:421 contrib/admin/options.py:454
-#: contrib/auth/admin.py:59
+#:

[Changeset] r9829 - django/branches/releases/1.0.X/django/conf/locale/es/LC_MESSAGES

2009-02-13 Thread noreply


Author: telenieko
Date: 2009-02-13 04:58:08 -0600 (Fri, 13 Feb 2009)
New Revision: 9829

Modified:
   django/branches/releases/1.0.X/django/conf/locale/es/LC_MESSAGES/django.mo
   django/branches/releases/1.0.X/django/conf/locale/es/LC_MESSAGES/django.po
Log:
[1.0.X] Updated Spanish Translation.

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

Modified: 
django/branches/releases/1.0.X/django/conf/locale/es/LC_MESSAGES/django.po
===
--- django/branches/releases/1.0.X/django/conf/locale/es/LC_MESSAGES/django.po  
2009-02-13 10:57:31 UTC (rev 9828)
+++ django/branches/releases/1.0.X/django/conf/locale/es/LC_MESSAGES/django.po  
2009-02-13 10:58:08 UTC (rev 9829)
@@ -5,8 +5,8 @@
 msgstr ""
 "Project-Id-Version: Django\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2008-11-13 18:56+0100\n"
-"PO-Revision-Date: 2008-11-13 19:00+0100\n"
+"POT-Creation-Date: 2009-02-13 10:41+0100\n"
+"PO-Revision-Date: 2009-02-13 10:43+0100\n"
 "Last-Translator: Django Spanish Team Language-"
 "Team: Django Spanish Team MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
@@ -98,118 +98,122 @@
 msgstr "hebreo"
 
 #: conf/global_settings.py:65
+msgid "Hindi"
+msgstr "hindi"
+
+#: conf/global_settings.py:66
 msgid "Croatian"
 msgstr "croata"
 
-#: conf/global_settings.py:66
+#: conf/global_settings.py:67
 msgid "Icelandic"
 msgstr "islandés"
 
-#: conf/global_settings.py:67
+#: conf/global_settings.py:68
 msgid "Italian"
 msgstr "italiano"
 
-#: conf/global_settings.py:68
+#: conf/global_settings.py:69
 msgid "Japanese"
 msgstr "japonés"
 
-#: conf/global_settings.py:69
+#: conf/global_settings.py:70
 msgid "Georgian"
 msgstr "georgiano"
 
-#: conf/global_settings.py:70
+#: conf/global_settings.py:71
 msgid "Korean"
 msgstr "koreano"
 
-#: conf/global_settings.py:71
+#: conf/global_settings.py:72
 msgid "Khmer"
 msgstr "khmer"
 
-#: conf/global_settings.py:72
+#: conf/global_settings.py:73
 msgid "Kannada"
 msgstr "kannada"
 
-#: conf/global_settings.py:73
+#: conf/global_settings.py:74
 msgid "Latvian"
 msgstr "letón"
 
-#: conf/global_settings.py:74
+#: conf/global_settings.py:75
 msgid "Lithuanian"
 msgstr "lituano"
 
-#: conf/global_settings.py:75
+#: conf/global_settings.py:76
 msgid "Macedonian"
 msgstr "macedonio"
 
-#: conf/global_settings.py:76
+#: conf/global_settings.py:77
 msgid "Dutch"
 msgstr "holandés"
 
-#: conf/global_settings.py:77
+#: conf/global_settings.py:78
 msgid "Norwegian"
 msgstr "noruego"
 
-#: conf/global_settings.py:78
+#: conf/global_settings.py:79
 msgid "Polish"
 msgstr "polaco"
 
-#: conf/global_settings.py:79
+#: conf/global_settings.py:80
 msgid "Portuguese"
 msgstr "portugués"
 
-#: conf/global_settings.py:80
+#: conf/global_settings.py:81
 msgid "Brazilian Portuguese"
 msgstr "portugués de Brasil"
 
-#: conf/global_settings.py:81
+#: conf/global_settings.py:82
 msgid "Romanian"
 msgstr "rumano"
 
-#: conf/global_settings.py:82
+#: conf/global_settings.py:83
 msgid "Russian"
 msgstr "ruso"
 
-#: conf/global_settings.py:83
+#: conf/global_settings.py:84
 msgid "Slovak"
 msgstr "eslovaco"
 
-#: conf/global_settings.py:84
+#: conf/global_settings.py:85
 msgid "Slovenian"
 msgstr "esloveno"
 
-#: conf/global_settings.py:85
+#: conf/global_settings.py:86
 msgid "Serbian"
 msgstr "serbio"
 
-#: conf/global_settings.py:86
+#: conf/global_settings.py:87
 msgid "Swedish"
 msgstr "sueco"
 
-#: conf/global_settings.py:87
+#: conf/global_settings.py:88
 msgid "Tamil"
 msgstr "tamil"
 
-#: conf/global_settings.py:88
+#: conf/global_settings.py:89
 msgid "Telugu"
 msgstr "telugu"
 
-#: conf/global_settings.py:89
+#: conf/global_settings.py:90
 msgid "Thai"
 msgstr "tailandés"
 
-#: conf/global_settings.py:90
+#: conf/global_settings.py:91
 msgid "Turkish"
 msgstr "turco"
 
-#: conf/global_settings.py:91
+#: conf/global_settings.py:92
 msgid "Ukrainian"
 msgstr "ucraniano"
 
-#: conf/global_settings.py:92
+#: conf/global_settings.py:93
 msgid "Simplified Chinese"
 msgstr "chino simplificado"
 
-#: conf/global_settings.py:93
+#: conf/global_settings.py:94
 msgid "Traditional Chinese"
 msgstr "chino tradicional"
 
@@ -297,7 +301,7 @@
 msgstr "Modificado/a %s."
 
 #: contrib/admin/options.py:338 contrib/admin/options.py:348
-#: contrib/comments/templates/comments/preview.html:15 forms/models.py:288
+#: contrib/comments/templates/comments/preview.html:15 forms/models.py:294
 msgid "and"
 msgstr "y"
 
@@ -320,13 +324,13 @@
 msgid "No fields changed."
 msgstr "No ha cambiado ningún campo."
 
-#: contrib/admin/options.py:417 contrib/auth/admin.py:51
+#: contrib/admin/options.py:417 contrib/auth/admin.py:61
 #, python-format
 msgid "The %(name)s \"%(obj)s\" was added successfully."
 msgstr "Se añadió con éxito el %(name)s \"%(obj)s\"."
 
 #:

[Changeset] r9828 - django/trunk/django/conf/locale/es/LC_MESSAGES

2009-02-13 Thread noreply


Author: telenieko
Date: 2009-02-13 04:57:31 -0600 (Fri, 13 Feb 2009)
New Revision: 9828

Modified:
   django/trunk/django/conf/locale/es/LC_MESSAGES/django.mo
   django/trunk/django/conf/locale/es/LC_MESSAGES/django.po
Log:
Updated Spanish translation.

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

Modified: django/trunk/django/conf/locale/es/LC_MESSAGES/django.po
===
--- django/trunk/django/conf/locale/es/LC_MESSAGES/django.po2009-02-13 
10:57:06 UTC (rev 9827)
+++ django/trunk/django/conf/locale/es/LC_MESSAGES/django.po2009-02-13 
10:57:31 UTC (rev 9828)
@@ -5,8 +5,8 @@
 msgstr ""
 "Project-Id-Version: Django\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2008-11-13 18:56+0100\n"
-"PO-Revision-Date: 2008-11-13 19:09+0100\n"
+"POT-Creation-Date: 2009-02-13 11:55+0100\n"
+"PO-Revision-Date: 2009-02-13 11:56+0100\n"
 "Last-Translator: Django Spanish Team Language-"
 "Team: Django Spanish Team MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
@@ -98,118 +98,122 @@
 msgstr "hebreo"
 
 #: conf/global_settings.py:65
+msgid "Hindi"
+msgstr "hindi"
+
+#: conf/global_settings.py:66
 msgid "Croatian"
 msgstr "croata"
 
-#: conf/global_settings.py:66
+#: conf/global_settings.py:67
 msgid "Icelandic"
 msgstr "islandés"
 
-#: conf/global_settings.py:67
+#: conf/global_settings.py:68
 msgid "Italian"
 msgstr "italiano"
 
-#: conf/global_settings.py:68
+#: conf/global_settings.py:69
 msgid "Japanese"
 msgstr "japonés"
 
-#: conf/global_settings.py:69
+#: conf/global_settings.py:70
 msgid "Georgian"
 msgstr "georgiano"
 
-#: conf/global_settings.py:70
+#: conf/global_settings.py:71
 msgid "Korean"
 msgstr "koreano"
 
-#: conf/global_settings.py:71
+#: conf/global_settings.py:72
 msgid "Khmer"
 msgstr "khmer"
 
-#: conf/global_settings.py:72
+#: conf/global_settings.py:73
 msgid "Kannada"
 msgstr "kannada"
 
-#: conf/global_settings.py:73
+#: conf/global_settings.py:74
 msgid "Latvian"
 msgstr "letón"
 
-#: conf/global_settings.py:74
+#: conf/global_settings.py:75
 msgid "Lithuanian"
 msgstr "lituano"
 
-#: conf/global_settings.py:75
+#: conf/global_settings.py:76
 msgid "Macedonian"
 msgstr "macedonio"
 
-#: conf/global_settings.py:76
+#: conf/global_settings.py:77
 msgid "Dutch"
 msgstr "holandés"
 
-#: conf/global_settings.py:77
+#: conf/global_settings.py:78
 msgid "Norwegian"
 msgstr "noruego"
 
-#: conf/global_settings.py:78
+#: conf/global_settings.py:79
 msgid "Polish"
 msgstr "polaco"
 
-#: conf/global_settings.py:79
+#: conf/global_settings.py:80
 msgid "Portuguese"
 msgstr "portugués"
 
-#: conf/global_settings.py:80
+#: conf/global_settings.py:81
 msgid "Brazilian Portuguese"
 msgstr "portugués de Brasil"
 
-#: conf/global_settings.py:81
+#: conf/global_settings.py:82
 msgid "Romanian"
 msgstr "rumano"
 
-#: conf/global_settings.py:82
+#: conf/global_settings.py:83
 msgid "Russian"
 msgstr "ruso"
 
-#: conf/global_settings.py:83
+#: conf/global_settings.py:84
 msgid "Slovak"
 msgstr "eslovaco"
 
-#: conf/global_settings.py:84
+#: conf/global_settings.py:85
 msgid "Slovenian"
 msgstr "esloveno"
 
-#: conf/global_settings.py:85
+#: conf/global_settings.py:86
 msgid "Serbian"
 msgstr "serbio"
 
-#: conf/global_settings.py:86
+#: conf/global_settings.py:87
 msgid "Swedish"
 msgstr "sueco"
 
-#: conf/global_settings.py:87
+#: conf/global_settings.py:88
 msgid "Tamil"
 msgstr "tamil"
 
-#: conf/global_settings.py:88
+#: conf/global_settings.py:89
 msgid "Telugu"
 msgstr "telugu"
 
-#: conf/global_settings.py:89
+#: conf/global_settings.py:90
 msgid "Thai"
 msgstr "tailandés"
 
-#: conf/global_settings.py:90
+#: conf/global_settings.py:91
 msgid "Turkish"
 msgstr "turco"
 
-#: conf/global_settings.py:91
+#: conf/global_settings.py:92
 msgid "Ukrainian"
 msgstr "ucraniano"
 
-#: conf/global_settings.py:92
+#: conf/global_settings.py:93
 msgid "Simplified Chinese"
 msgstr "chino simplificado"
 
-#: conf/global_settings.py:93
+#: conf/global_settings.py:94
 msgid "Traditional Chinese"
 msgstr "chino tradicional"
 
@@ -287,100 +291,100 @@
 msgid "log entries"
 msgstr "entradas de registro"
 
-#: contrib/admin/options.py:60 contrib/admin/options.py:121
+#: contrib/admin/options.py:129 contrib/admin/options.py:143
 msgid "None"
 msgstr "Ninguno"
 
-#: contrib/admin/options.py:338
+#: contrib/admin/options.py:375
 #, python-format
 msgid "Changed %s."
 msgstr "Modificado/a %s."
 
-#: contrib/admin/options.py:338 contrib/admin/options.py:348
-#: contrib/comments/templates/comments/preview.html:15 forms/models.py:288
+#: contrib/admin/options.py:375 contrib/admin/options.py:385
+#: contrib/comments/templates/comments/preview.html:15 forms/models.py:294
 msgid "and"
 msgstr "y"
 
-#: contrib/admin/options.py:343
+#: contrib/admin/options.py:380
 #, python-format

[Changeset] r9827 - django/trunk/django/conf/locale/ca/LC_MESSAGES

2009-02-13 Thread noreply


Author: telenieko
Date: 2009-02-13 04:57:06 -0600 (Fri, 13 Feb 2009)
New Revision: 9827

Modified:
   django/trunk/django/conf/locale/ca/LC_MESSAGES/django.mo
   django/trunk/django/conf/locale/ca/LC_MESSAGES/django.po
Log:
Updated Catalan translation

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

Modified: django/trunk/django/conf/locale/ca/LC_MESSAGES/django.po
===
--- django/trunk/django/conf/locale/ca/LC_MESSAGES/django.po2009-02-12 
02:55:32 UTC (rev 9826)
+++ django/trunk/django/conf/locale/ca/LC_MESSAGES/django.po2009-02-13 
10:57:06 UTC (rev 9827)
@@ -5,8 +5,8 @@
 msgstr ""
 "Project-Id-Version: Django\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2008-11-13 19:01+0100\n"
-"PO-Revision-Date: 2008-11-13 19:11+0100\n"
+"POT-Creation-Date: 2009-02-13 11:54+0100\n"
+"PO-Revision-Date: 2009-02-13 11:54+0100\n"
 "Last-Translator: Django Catalan Group \n"
 "Language-Team: Catalan \n"
 "MIME-Version: 1.0\n"
@@ -99,118 +99,122 @@
 msgstr "hebreu"
 
 #: conf/global_settings.py:65
+msgid "Hindi"
+msgstr "hindi"
+
+#: conf/global_settings.py:66
 msgid "Croatian"
 msgstr "croat"
 
-#: conf/global_settings.py:66
+#: conf/global_settings.py:67
 msgid "Icelandic"
 msgstr "islandès"
 
-#: conf/global_settings.py:67
+#: conf/global_settings.py:68
 msgid "Italian"
 msgstr "italià"
 
-#: conf/global_settings.py:68
+#: conf/global_settings.py:69
 msgid "Japanese"
 msgstr "japonès"
 
-#: conf/global_settings.py:69
+#: conf/global_settings.py:70
 msgid "Georgian"
 msgstr "georgià"
 
-#: conf/global_settings.py:70
+#: conf/global_settings.py:71
 msgid "Korean"
 msgstr "coreà"
 
-#: conf/global_settings.py:71
+#: conf/global_settings.py:72
 msgid "Khmer"
 msgstr "khmer"
 
-#: conf/global_settings.py:72
+#: conf/global_settings.py:73
 msgid "Kannada"
 msgstr "canès"
 
-#: conf/global_settings.py:73
+#: conf/global_settings.py:74
 msgid "Latvian"
 msgstr "letó"
 
-#: conf/global_settings.py:74
+#: conf/global_settings.py:75
 msgid "Lithuanian"
 msgstr "lituà"
 
-#: conf/global_settings.py:75
+#: conf/global_settings.py:76
 msgid "Macedonian"
 msgstr "macedoni"
 
-#: conf/global_settings.py:76
+#: conf/global_settings.py:77
 msgid "Dutch"
 msgstr "holandès"
 
-#: conf/global_settings.py:77
+#: conf/global_settings.py:78
 msgid "Norwegian"
 msgstr "norueg"
 
-#: conf/global_settings.py:78
+#: conf/global_settings.py:79
 msgid "Polish"
 msgstr "polac"
 
-#: conf/global_settings.py:79
+#: conf/global_settings.py:80
 msgid "Portuguese"
 msgstr "portuguès"
 
-#: conf/global_settings.py:80
+#: conf/global_settings.py:81
 msgid "Brazilian Portuguese"
 msgstr "portuguès de brasil"
 
-#: conf/global_settings.py:81
+#: conf/global_settings.py:82
 msgid "Romanian"
 msgstr "rumanès"
 
-#: conf/global_settings.py:82
+#: conf/global_settings.py:83
 msgid "Russian"
 msgstr "rús"
 
-#: conf/global_settings.py:83
+#: conf/global_settings.py:84
 msgid "Slovak"
 msgstr "eslovac"
 
-#: conf/global_settings.py:84
+#: conf/global_settings.py:85
 msgid "Slovenian"
 msgstr "esloveni"
 
-#: conf/global_settings.py:85
+#: conf/global_settings.py:86
 msgid "Serbian"
 msgstr "serbi"
 
-#: conf/global_settings.py:86
+#: conf/global_settings.py:87
 msgid "Swedish"
 msgstr "suec"
 
-#: conf/global_settings.py:87
+#: conf/global_settings.py:88
 msgid "Tamil"
 msgstr "tàmil"
 
-#: conf/global_settings.py:88
+#: conf/global_settings.py:89
 msgid "Telugu"
 msgstr "telugu"
 
-#: conf/global_settings.py:89
+#: conf/global_settings.py:90
 msgid "Thai"
 msgstr "tailandès"
 
-#: conf/global_settings.py:90
+#: conf/global_settings.py:91
 msgid "Turkish"
 msgstr "turc"
 
-#: conf/global_settings.py:91
+#: conf/global_settings.py:92
 msgid "Ukrainian"
 msgstr "ucranià"
 
-#: conf/global_settings.py:92
+#: conf/global_settings.py:93
 msgid "Simplified Chinese"
 msgstr "xinès simplificat"
 
-#: conf/global_settings.py:93
+#: conf/global_settings.py:94
 msgid "Traditional Chinese"
 msgstr "xinès tradicional"
 
@@ -288,60 +292,60 @@
 msgid "log entries"
 msgstr "entrades del registre"
 
-#: contrib/admin/options.py:60 contrib/admin/options.py:121
+#: contrib/admin/options.py:129 contrib/admin/options.py:143
 msgid "None"
 msgstr "cap"
 
-#: contrib/admin/options.py:338
+#: contrib/admin/options.py:375
 #, python-format
 msgid "Changed %s."
 msgstr "Modificat %s."
 
-#: contrib/admin/options.py:338 contrib/admin/options.py:348
-#: contrib/comments/templates/comments/preview.html:15 forms/models.py:288
+#: contrib/admin/options.py:375 contrib/admin/options.py:385
+#: contrib/comments/templates/comments/preview.html:15 forms/models.py:294
 msgid "and"
 msgstr "i"
 
-#: contrib/admin/options.py:343
+#: contrib/admin/options.py:380
 #, python-format
 msgid "Added %(name)s \"%(object)s\"."
 msgstr "Afegit %(name)s \"%(object)s\""
 
-#:

Re: [Django] #10256: values() and values_list() either include all or no columns from the extra(select=) clause

2009-02-13 Thread Django

#10256: values() and values_list() either include all or no columns from the
extra(select=) clause
---+
  Reporter:  russellm  | Owner:  russellm
Status:  new   | Milestone:  
 Component:  Database layer (models, ORM)  |   Version:  1.0 
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * owner:  nobody => russellm
  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 I'm working on this - I should commit a fix shortly.

-- 
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] #10256: values() and values_list() either include all or no columns from the extra(select=) clause

2009-02-13 Thread Django

#10256: values() and values_list() either include all or no columns from the
extra(select=) clause
--+-
 Reporter:  russellm  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.0   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 By way of example, this is what 1.0.X produces:
 {{{
 >>>
 
Book.objects.extra(select={'a':'name','b':'price','c':'pages'}).values('name','pages','a')
 [{'a': u'Book 1', 'c': 11, 'b': Decimal("11.11"), 'name': u'Book 1',
 'pages': 11}, ...

 >>>
 
Book.objects.extra(select={'a':'name','b':'price','c':'pages'}).values('name','pages')
 [{'name': u'Book 1', 'pages': 11}, ...
 }}}

 That is, if you don't explicitly mention an extra selected column in the
 values() clause, they are omitted (as expected). However, as soon as you
 include a single extra column, _all_ extra columns are included in the
 returned values.

 Analogous behavior exists for values_list().

-- 
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] #10255: FileField overwrite existing value with empty one

2009-02-13 Thread Django

#10255: FileField overwrite existing value with empty one
--+-
 Reporter:  pierpaolodf   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  SVN   
 Keywords:  FileField |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Since revision 9766 editing in admin will cause overwriting existing value
 in FileField with blank value.

 1) create a new record setting FileField to some file and save it

 2) edit the previous record in some field other than the FileField (or
 just save with no change)

 3) check the record to find out that FileField is now empty

-- 
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
-~--~~~~--~~--~--~---

39 matches

Mail list logo