Opened 14 years ago
Closed 14 years ago
#15505 closed (invalid)
Feature request: disable localization in some model fields
Reported by: | Denilson Figueiredo de Sá | Owned by: | nobody |
---|---|---|---|
Component: | Uncategorized | Version: | 1.2 |
Severity: | Keywords: | ||
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
In 1.2, we now have L10N, so now Integer fields automatically have the thousand separator. That's a neat addition.
Also, we have a "localize" parameter to Form fields, setting if they should be localized or not.
http://docs.djangoproject.com/en/dev/ref/forms/fields/#localize
However... I miss such "localize" parameter at the Model itself. For me, it makes sense to set some fields as "do not localize". For instance, suppose I have a IntegerField that holds a barcode. It makes no sense to ever localize such field, so I would like to tell this to Django.
Suggestion: add "localize" parameter also to model fields.
Change History (3)
comment:1 by , 14 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:2 by , 14 years ago
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
I disagree because I was thinking about using them in templates without Forms.
In other words, if a template receives a model instance, or a list of model instances, then it will directly render the model fields, without using any Form. After all, I believe there are many use cases where a Form is not needed (e.g. a list of objects).
I know I can just "|unlocalize", but IMHO it makes sense to tell Django to never localize some fields.
I'm reopening, if you still disagree, just close again.
comment:3 by , 14 years ago
Resolution: | → invalid |
---|---|
Status: | reopened → closed |
Ubernostrum is right; this is a presentation layer problem, not a data layer problem.
While I can see the desire to have this in Django, I don't think it's a good idea. Localization of values, etc., is basically just an issue of how the data is presented when displayed in a form, so forms are the right place to do this. Models shouldn't know or have to know this much about how their data will be presented.