I’ve always been annoyed by having to define lower case model field labels and capitalized form field labels. Inconsistencies always creep in. I would like to see this suggestion implemented, if we can provide a decent upgrade story for Django users.
-- Aymeric. > On 11 nov. 2015, at 16:59, Sergei Maertens <sergeimaert...@gmail.com> wrote: > > This is a proposal to change how Django generates form field labels from > model fields. Currently, `capfirst` is called on `field.verbose_name` (see > https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L872). > This behaviour has been around since pretty much forever and makes sense. > > However, this affects what you put down in your translations - if a > lowercased verbose name is what you want (and you translate it as such), > Django will make your form labels uppercase and there's no clean way around > that. > > There is a very specific use case for this proposal. The house-style of a > design states that all form labels should be lowercase - but names of the > brand should be capitalized. Example: 'you agree to the Brand terms'. This is > not easily feasible: css text-transform will also lowercase the brand name, > and Django uppercases the first letter. Another possible use case could be if > you insist on putting the labels to the right of the form input, but I will > agree that looks silly. > > So the proposal is to get rid of the capfirst call, and in the admin this > could be mitigated for backwards compatibility by modifying the css to > include: > label { > text-transform: capitalize; > } > > This is ofcourse a fairly big backwards-incompatible change towards > front-end/non-vendor code, as people now have to explicitly make sure that > labels are capitalized in their own templates. So this should probably go > through the usual deprecation mechanics (silent, warning, remove), if it > happens at all. > > What are current workarounds for this problem? > explicitly specifying the label value in the ModelForm definition: this > violates the DRY principle, you already defined the verbose_name on the model > field > creating a form mixin that will lowercase the first letter of the label for > all fields > you still have to check if the first word if it's the Brand string, because > then it should stay capitalized > you now have to include this mixin in every single form, and can no longer > rely on implicitly generated form classes in generic CBV > create a templatefilter that decapitalizes the label, and re-capitalizes > 'brand' occurrences to 'Brand' (currently implemented) > you now have to not forget this filter everywhere you render forms > performance hit if this is based on regular expressions (which in this case > it is because subbrand should not become subBrand) > All in all, I'm of the opinion that the flexibility you gain by NOT > manipulating the label in Django outweighs the backwards incompatible change. > I'm also strongly of the opinion that capitalizing labels is something that > should be done entirely in CSS - whether the label is capitalized, lower case > or upper case shouldn't matter for Django's internals. > > Reasons to not do this: > cater to common convention, not clients (quoted from #django-dev on irc): in > my opinion this works 95% of the time, but your forced into violating some of > Django's principles if you divert from this, most notably DRY > maintain backwards compatibility > Reasons to do this: > gain flexibility about the display of form labels > keep the codebase sane > > Bonus: vaguely related ticket: https://code.djangoproject.com/ticket/5518 > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com > <mailto:django-developers+unsubscr...@googlegroups.com>. > To post to this group, send email to django-developers@googlegroups.com > <mailto:django-developers@googlegroups.com>. > Visit this group at http://groups.google.com/group/django-developers > <http://groups.google.com/group/django-developers>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/567142d7-0da1-49ed-9994-a43a834af551%40googlegroups.com > > <https://groups.google.com/d/msgid/django-developers/567142d7-0da1-49ed-9994-a43a834af551%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/AC4192A2-32DC-4C4D-8D28-E3C4473595F3%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
