Opened 3 years ago

Closed 3 years ago

#18483 closed Bug (fixed)

HiddenInput validation i18n trouble

Reported by: Evil Clay <clay.evil@…> 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.

  1. if the field is empty i get an validation error that is only partially in my language.
  2. 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 Changed 3 years ago by aaugustin

  • Component changed from Uncategorized to Forms
  • Easy pickings set
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted
  • Type changed from Cleanup/optimization to Bug

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 :)

comment:2 Changed 3 years ago by EmilStenstrom

  • Has patch set
  • Owner changed from nobody to EmilStenstrom

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 Changed 3 years ago by Claude Paroz <claude@…>

  • Resolution set to fixed
  • Status changed from new to closed

In 962f133f72abe2a1174d48baa52aa8549762a022:

Fixed #18483 -- Marked hidden field error string for translation

Thanks Evil Clay for the report and Emil Stenstrom for the initial
patch.

Note: See TracTickets for help on using tickets.
Back to Top