Opened 13 years ago
Closed 12 years ago
#18483 closed Bug (fixed)
HiddenInput validation i18n trouble
Reported by: | Owned by: | EmilStenstrom | |
---|---|---|---|
Component: | Forms | Version: | 1.4 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | yes | UI/UX: | no |
Description
I have a model with ForeignKey filed and an ModelForm where i do set the Hidden Input widget for this filed.
I have these issues with required validation.
- if the field is empty i get an validation error that is only partially in my language.
- The error is printed out as non_field_error when i use form.as_p, but its not printed by the form.non_filed_error alone since the behavior is inconsistent.
I have tracked the issue to the module <django.forms.forms> line 152:
top_errors.extend([u'(Hidden field %s) %s' % (name, force_unicode(e)) for e in bf_errors])
To my (limited) knowledge i cannot solve the i18n by myself an easy way (dirty solution would by overriding the BaseForm class).
as for to second part i understand that this is an attempt to output the error somehow as i use form.as_xxx but when using hiddenInput on required filed, it is to be expected that i have to output the form myself to display the error on the page where i need to display it.
The best solution to solve both problems would probabbly be to loose the line 152.
Other solution is to loose the (Hidden filed %s part and ignore the inconstancy #2.
only workaround currently is not to use the form.as_xxx methods on an i18n project which implies that the line 152 sucks :)
Change History (3)
comment:1 by , 12 years ago
Component: | Uncategorized → Forms |
---|---|
Easy pickings: | set |
Triage Stage: | Unreviewed → Accepted |
Type: | Cleanup/optimization → Bug |
comment:2 by , 12 years ago
Has patch: | set |
---|---|
Owner: | changed from | to
This patch just makes this string in question translatable. We don't think this needs a test.
Here's the patch: https://github.com/django/django/pull/525
comment:3 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
1) If the default error string of django.forms.forms, line 152, is ever displayed to an end user, he has no way to fix his submission, since the error is on an hidden field. That said, we can translate this string — as a matter of principle. I'm accepting the ticket on the basis.
2) Generally speaking, there's no obvious way to display errors on hidden fields. The
form.as_xxx
methods display them as global errors, which is as good as a generic solution can be. If your form may have validation errors on hidden fields, you'd better write some appropriate code to explain how to fix them. Otherwise your form could be very hard to use! So I think Django's behavior is reasonable here.In my opinion it's best to avoid validation errors on hidden fields, rather than avoid the
form.as_xxx
methods :)