Re: Form field labels change proposal

[Daniele Procida]

On Sat, Jul 2, 2016, Sergei Maertens  wrote:

>I've talked with some other core developers at the sprint, and the proposed 
>flow is more in line with the initial proposal again:
>
>* The deprecation cycle would include a settings (let's call it 
>CAPFIRST_MODELFORM_LABEL), defaulting to False (the new behaviour). Users 
>who wish to keep the old behaviour for a while set this to True
>* The capfirst calls (there are 2 relevant ones) are replaced by wrappers 
>that check the CAPFIRST_MODELFORM_LABEL setting. If it's set to True, the 
>real capfirst is applied to field.verbose_name, else the raw 
>field.verbose_name is returned.
>* The Django admin css can be updated to include the CSS rule, so it looks 
>still the same. Drawback is that this breaks tests if people are actively 
>checking the labels/HTML for forms. The recommended approach here is to 
>provide the capitalized strings in verbose_name
>* For the front-end, the example CSS can be documented, or the option to 
>capitalize the verbose_name.
>
>Note that the new behaviour would be the default in the setting.

We've discussed this at the sprint; this seems like a pretty good approach to 
me. I'm not convinced by the label names, but that's a detail.

>One other drawback I just thought of is that validation errors sometimes 
>include the verbose_name (I think). This can look weird if the 
>end-developer has specified a capitalized verbose_name, but that's also the 
>case already. The recommended approach here would be to do the capitalizing 
>in CSS.

I think the main issue here is the possibility of weird-looking sentences 
coming out generally, but especially in languages that follow different rules 
from English.

Daniele

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20160703143638.1832271735%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Form field labels change proposal

[Sergei Maertens]

I've talked with some other core developers at the sprint, and the proposed 
flow is more in line with the initial proposal again:

* The deprecation cycle would include a settings (let's call it 
CAPFIRST_MODELFORM_LABEL), defaulting to False (the new behaviour). Users 
who wish to keep the old behaviour for a while set this to True
* The capfirst calls (there are 2 relevant ones) are replaced by wrappers 
that check the CAPFIRST_MODELFORM_LABEL setting. If it's set to True, the 
real capfirst is applied to field.verbose_name, else the raw 
field.verbose_name is returned.
* The Django admin css can be updated to include the CSS rule, so it looks 
still the same. Drawback is that this breaks tests if people are actively 
checking the labels/HTML for forms. The recommended approach here is to 
provide the capitalized strings in verbose_name
* For the front-end, the example CSS can be documented, or the option to 
capitalize the verbose_name.

Note that the new behaviour would be the default in the setting.

One other drawback I just thought of is that validation errors sometimes 
include the verbose_name (I think). This can look weird if the 
end-developer has specified a capitalized verbose_name, but that's also the 
case already. The recommended approach here would be to do the capitalizing 
in CSS.

On Saturday, July 2, 2016 at 3:28:58 PM UTC+2, Tim Graham wrote:
>
> How would projects opt-in to the new behavior and silence the deprecation 
> warning?
>
> On Saturday, July 2, 2016 at 8:04:23 AM UTC-4, Sergei Maertens wrote:
>>
>> So, this is the follow up from the discussion with Markus.
>>
>> Implementation wise, we would only apply the capfirst on ModelForm fields 
>> if the model field has no explicit verbose_name set. That way, you can 
>> control the capitalization on the model level without having to specify it 
>> on the form again.
>>
>> This could go through the usual deprecation cycle, with a warnings filter 
>> so that the warning is only emited once. An example of that already exists 
>> in the migrations: django.db.migrations.state.ModelState.render:
>> ...
>> with warnings.catch_warnings():
>> warnings.filterwarnings(
>> "ignore", "Managers from concrete parents will soon 
>> qualify as default managers",
>> RemovedInDjango20Warning)
>> ...
>>
>> In our case, the 'ignore' would become 'once'.
>>
>> The admin CSS would be updated to include the CSS selector for labels so 
>> that the capitalization is applied in CSS.
>>
>> The placeholder issue for djangoproject.com would then have to be 
>> handled in the djangoproject.com code, unfortunately there's no easy way 
>> around that.
>>
>> This gives the developer using Django full control over the labels in a 
>> DRY way.
>>
>> This approach matches Sven's latest reply.
>>
>> On Wednesday, November 11, 2015 at 4:59:46 PM UTC+1, Sergei Maertens 
>> 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 

Re: Form field labels change proposal

[Sergei Maertens]

https://github.com/sergei-maertens/django/tree/capfirst-deprecation 
contains a simple POC with the warning filtering.

On a fairly large project with a lot of ModelForms and explicit 
verbose_name's, I see the warning three times on startup.

On Saturday, July 2, 2016 at 4:03:14 PM UTC+2, Sergei Maertens wrote:
>
> I am experimenting with warnings.filterwarnings('once', ...), which 
> reduces the total warning output to 4 warnings, while there are about 10-15 
> calls. I haven't been able to completely silence it, probably because there 
> are certain imports happening before a custom filter comes into pla
>
> Opting in to the new behaviour is not covered. My personal feeling about 
> this is that adding machinery to be able to opt in and silencing the 
> warnings would be much more work than making the actual change. Extra 
> settings were opted before, I don't like it because of the 
> extra-machinery-reason I just mentioned. It *feels* as if it's either make 
> the (backwards incompatible) change at once, or go through the entire 
> deprecation cycle.
>
> I'm open for suggestions, since obviously I don't have all the answers 
> myself...
>
> On Saturday, July 2, 2016 at 3:28:58 PM UTC+2, Tim Graham wrote:
>>
>> How would projects opt-in to the new behavior and silence the deprecation 
>> warning?
>>
>> On Saturday, July 2, 2016 at 8:04:23 AM UTC-4, Sergei Maertens wrote:
>>>
>>> So, this is the follow up from the discussion with Markus.
>>>
>>> Implementation wise, we would only apply the capfirst on ModelForm 
>>> fields if the model field has no explicit verbose_name set. That way, you 
>>> can control the capitalization on the model level without having to specify 
>>> it on the form again.
>>>
>>> This could go through the usual deprecation cycle, with a warnings 
>>> filter so that the warning is only emited once. An example of that already 
>>> exists in the migrations: django.db.migrations.state.ModelState.render:
>>> ...
>>> with warnings.catch_warnings():
>>> warnings.filterwarnings(
>>> "ignore", "Managers from concrete parents will soon 
>>> qualify as default managers",
>>> RemovedInDjango20Warning)
>>> ...
>>>
>>> In our case, the 'ignore' would become 'once'.
>>>
>>> The admin CSS would be updated to include the CSS selector for labels so 
>>> that the capitalization is applied in CSS.
>>>
>>> The placeholder issue for djangoproject.com would then have to be 
>>> handled in the djangoproject.com code, unfortunately there's no easy 
>>> way around that.
>>>
>>> This gives the developer using Django full control over the labels in a 
>>> DRY way.
>>>
>>> This approach matches Sven's latest reply.
>>>
>>> On Wednesday, November 11, 2015 at 4:59:46 PM UTC+1, Sergei Maertens 
>>> 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 

Re: Form field labels change proposal

[Sergei Maertens]

I am experimenting with warnings.filterwarnings('once', ...), which reduces 
the total warning output to 4 warnings, while there are about 10-15 calls. 
I haven't been able to completely silence it, probably because there are 
certain imports happening before a custom filter comes into pla

Opting in to the new behaviour is not covered. My personal feeling about 
this is that adding machinery to be able to opt in and silencing the 
warnings would be much more work than making the actual change. Extra 
settings were opted before, I don't like it because of the 
extra-machinery-reason I just mentioned. It *feels* as if it's either make 
the (backwards incompatible) change at once, or go through the entire 
deprecation cycle.

I'm open for suggestions, since obviously I don't have all the answers 
myself...

On Saturday, July 2, 2016 at 3:28:58 PM UTC+2, Tim Graham wrote:
>
> How would projects opt-in to the new behavior and silence the deprecation 
> warning?
>
> On Saturday, July 2, 2016 at 8:04:23 AM UTC-4, Sergei Maertens wrote:
>>
>> So, this is the follow up from the discussion with Markus.
>>
>> Implementation wise, we would only apply the capfirst on ModelForm fields 
>> if the model field has no explicit verbose_name set. That way, you can 
>> control the capitalization on the model level without having to specify it 
>> on the form again.
>>
>> This could go through the usual deprecation cycle, with a warnings filter 
>> so that the warning is only emited once. An example of that already exists 
>> in the migrations: django.db.migrations.state.ModelState.render:
>> ...
>> with warnings.catch_warnings():
>> warnings.filterwarnings(
>> "ignore", "Managers from concrete parents will soon 
>> qualify as default managers",
>> RemovedInDjango20Warning)
>> ...
>>
>> In our case, the 'ignore' would become 'once'.
>>
>> The admin CSS would be updated to include the CSS selector for labels so 
>> that the capitalization is applied in CSS.
>>
>> The placeholder issue for djangoproject.com would then have to be 
>> handled in the djangoproject.com code, unfortunately there's no easy way 
>> around that.
>>
>> This gives the developer using Django full control over the labels in a 
>> DRY way.
>>
>> This approach matches Sven's latest reply.
>>
>> On Wednesday, November 11, 2015 at 4:59:46 PM UTC+1, Sergei Maertens 
>> 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 

Re: Form field labels change proposal

[Tim Graham]

How would projects opt-in to the new behavior and silence the deprecation 
warning?

On Saturday, July 2, 2016 at 8:04:23 AM UTC-4, Sergei Maertens wrote:
>
> So, this is the follow up from the discussion with Markus.
>
> Implementation wise, we would only apply the capfirst on ModelForm fields 
> if the model field has no explicit verbose_name set. That way, you can 
> control the capitalization on the model level without having to specify it 
> on the form again.
>
> This could go through the usual deprecation cycle, with a warnings filter 
> so that the warning is only emited once. An example of that already exists 
> in the migrations: django.db.migrations.state.ModelState.render:
> ...
> with warnings.catch_warnings():
> warnings.filterwarnings(
> "ignore", "Managers from concrete parents will soon 
> qualify as default managers",
> RemovedInDjango20Warning)
> ...
>
> In our case, the 'ignore' would become 'once'.
>
> The admin CSS would be updated to include the CSS selector for labels so 
> that the capitalization is applied in CSS.
>
> The placeholder issue for djangoproject.com would then have to be handled 
> in the djangoproject.com code, unfortunately there's no easy way around 
> that.
>
> This gives the developer using Django full control over the labels in a 
> DRY way.
>
> This approach matches Sven's latest reply.
>
> On Wednesday, November 11, 2015 at 4:59:46 PM UTC+1, Sergei Maertens 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: 

Re: Form field labels change proposal

[Sergei Maertens]

This is the reworked patch assuming the deprecation process was 
completed: 
https://github.com/django/django/compare/master...sergei-maertens:modelform-capfirst?expand=1

On Wednesday, November 11, 2015 at 4:59:46 PM UTC+1, Sergei Maertens 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.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c749d578-9464-419f-a972-a21b25ac3aec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Form field labels change proposal

[Sergei Maertens]

So, this is the follow up from the discussion with Markus.

Implementation wise, we would only apply the capfirst on ModelForm fields 
if the model field has no explicit verbose_name set. That way, you can 
control the capitalization on the model level without having to specify it 
on the form again.

This could go through the usual deprecation cycle, with a warnings filter 
so that the warning is only emited once. An example of that already exists 
in the migrations: django.db.migrations.state.ModelState.render:
...
with warnings.catch_warnings():
warnings.filterwarnings(
"ignore", "Managers from concrete parents will soon qualify 
as default managers",
RemovedInDjango20Warning)
...

In our case, the 'ignore' would become 'once'.

The admin CSS would be updated to include the CSS selector for labels so 
that the capitalization is applied in CSS.

The placeholder issue for djangoproject.com would then have to be handled 
in the djangoproject.com code, unfortunately there's no easy way around 
that.

This gives the developer using Django full control over the labels in a DRY 
way.

This approach matches Sven's latest reply.

On Wednesday, November 11, 2015 at 4:59:46 PM UTC+1, Sergei Maertens 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 

Re: Form field labels change proposal

[Sven R. Kunze]

Good evening everybody. :) I would like to reference this 
ticket: https://code.djangoproject.com/ticket/26497#comment:11

It appears we stumbled over this issue as well while designing a new model 
form. Quoting my comment from the ticket:


Would it make sense to separate concepts here?

1) *user-defined* verbose_name: Django should not touch it
2) *auto-generated* verbose_name: Django generates the verbose_name from 
the field's name


In both cases, once the label of a form field is set, Django should only 
touch it (except on the designers behalf).

*Deprecation phase*:
a) make global capitalization optional via settings (or form variable) with 
True as default for status quo.
b) auto-generated verbose_names are generated using a format string which 
can also be specified by a settings variable (or form variable). Default 
should result in current output (with the capitalization)
c) disable global capitalization by default


Does this makes sense?

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/94da855b-c159-4c17-a24f-16f843096ae7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Form field labels change proposal

[Sergei Maertens]

Thanks for these specific use cases, I'll see if I can come up with some
acceptable solutions in a reasonable time
On Apr 13, 2016 6:47 PM, "Tim Graham"  wrote:

> Took a quick look at djangoproject.com with this change. I noticed we're
> using the label to construct an input placeholder [0]. I think adapting
> that for this change isn't so easy to do in a cross-browser way via CSS [1]
> but we could add capfirst in the code.
>
> The question of a deprecation seems to be whether it's better to ask every
> Django project opt into the new behavior in the next two releases via some
> temporary setting or if we force all projects to adapt their CSS (and
> possibly code, as the example above shows) for Django 1.10. I'm not too
> happy with either path.
>
> I'm not sure about the validation messages. If we stop capitalizing the
> label, the message "%(field_label)s must be unique for" won't start with a
> capital anymore. On the other hand, capitalizing field_label is awkward if
> a custom message that doesn't put field_label at the start of the sentence
> is used.
>
> [0]
> https://github.com/django/djangoproject.com/blob/7fd780c061e4244982ca5bdd914fd004c6fe90af/members/forms.py#L25
> [1] http://stackoverflow.com/a/2610741/5112
>
> On Sunday, January 31, 2016 at 4:30:09 PM UTC-5, Sergei Maertens wrote:
>>
>> I've done the initial work for a patch, assuming a 'hard' change without
>> deprecation path, the branch is here:
>> https://github.com/sergei-maertens/django/commit/2f3c1d8dd56522dc69448ec20aac28d4ddc70ac4
>> .
>> Tests should be passing.
>>
>> I've also taken a quick glance at django-admin-tools to check if they do
>> anything special with decapitalizing/capitalizing things, but all seems to
>> be well. Django injects the form css in the block extrastyle within
>> change_form.html. For Grappelli/django-xadmin that block is present, but
>> Grappelli overrides change_form.html, so that would probably need updating.
>> I haven't looked at any other admin-theme packages, but the change would be
>> trivial for them as well - providing a proper documentation notion.
>>
>> The only things so far I'm not really sure of are:
>>
>>- Is deprecation required or not (input needed from other core devs I
>>presume)
>>- what with the validation error messages: as it stands, field labels
>>are capitalized at the moment, and they're not in a  tag. Examples
>>can be found
>>in: django.db.models.base.Model.(date_error_message|unique_error_message)
>>
>> In the tests I also noticed that there are cases where the label itself
>> is not wrapped in a  tag
>> (django.tests.forms_tests.tests.test_forms.FormsTestCase.test_templates_with_forms).
>>
>> On Friday, November 20, 2015 at 8:31:55 PM UTC+1, Tim Graham wrote:
>>>
>>> Looks easy enough. I was going to write, "Seems to me that there's more
>>> complexity in a deprecation path that requires a temporary opt-in setting
>>> rather than simply making the backwards incompatible change. Unless I
>>> missed something, adding CSS like that shouldn't cause problems for any
>>> apps maintaining compatibility with older versions of Django." but then I
>>> thought of a different case where it could be trickier to upgrade:
>>> developers who are specifying label='lower string' in some places to
>>> workaround the current behavior (but still want uppercased labels
>>> everywhere else). I guess the solution would be to use the text-transform
>>> rule you mentioned and another CSS rule targeting all labels IDs that you
>>> want to remain lowercased.
>>>
>>> I'd like other opinions about whether or not a deprecation seems helpful
>>> for this. Personally, I'd rather just fix my CSS when upgrading rather than
>>> fix my CSS *and* add a setting for a few Django versions to silence the
>>> deprecation. I guess some people might like a few Django versions to update
>>> their CSS though (also we promised to try to provide fairly seamless
>>> upgrades from one LTS to the next).
>>>
>>> On Friday, November 20, 2015 at 11:38:53 AM UTC-5, Sergei Maertens wrote:

 In
 https://github.com/django/django/blob/master/django/contrib/admin/static/admin/css/forms.css#L31
 ,
 after
 label {
font-weight: normal;
color:#666;
font-size:13px;
 }

 you would add
 label::first-letter {
text-transform: capitalize;
 }

 (see https://css-tricks.com/almanac/selectors/f/first-letter/)

 text-transform: capitalize on the label itself would capitalize all
 words, which is not wanted. The ::first-letter pseudo-selector is 

Re: Form field labels change proposal

[Tim Graham]

Took a quick look at djangoproject.com with this change. I noticed we're 
using the label to construct an input placeholder [0]. I think adapting 
that for this change isn't so easy to do in a cross-browser way via CSS [1] 
but we could add capfirst in the code.

The question of a deprecation seems to be whether it's better to ask every 
Django project opt into the new behavior in the next two releases via some 
temporary setting or if we force all projects to adapt their CSS (and 
possibly code, as the example above shows) for Django 1.10. I'm not too 
happy with either path.

I'm not sure about the validation messages. If we stop capitalizing the 
label, the message "%(field_label)s must be unique for" won't start with a 
capital anymore. On the other hand, capitalizing field_label is awkward if 
a custom message that doesn't put field_label at the start of the sentence 
is used.

[0] 
https://github.com/django/djangoproject.com/blob/7fd780c061e4244982ca5bdd914fd004c6fe90af/members/forms.py#L25
[1] http://stackoverflow.com/a/2610741/5112

On Sunday, January 31, 2016 at 4:30:09 PM UTC-5, Sergei Maertens wrote:
>
> I've done the initial work for a patch, assuming a 'hard' change without 
> deprecation path, the branch is here: 
> https://github.com/sergei-maertens/django/commit/2f3c1d8dd56522dc69448ec20aac28d4ddc70ac4
>  
> .
>  
> Tests should be passing.
>
> I've also taken a quick glance at django-admin-tools to check if they do 
> anything special with decapitalizing/capitalizing things, but all seems to 
> be well. Django injects the form css in the block extrastyle within 
> change_form.html. For Grappelli/django-xadmin that block is present, but 
> Grappelli overrides change_form.html, so that would probably need updating. 
> I haven't looked at any other admin-theme packages, but the change would be 
> trivial for them as well - providing a proper documentation notion.
>
> The only things so far I'm not really sure of are:
>
>- Is deprecation required or not (input needed from other core devs I 
>presume)
>- what with the validation error messages: as it stands, field labels 
>are capitalized at the moment, and they're not in a  tag. Examples 
>can be found 
>in: django.db.models.base.Model.(date_error_message|unique_error_message)
>
> In the tests I also noticed that there are cases where the label itself is 
> not wrapped in a  tag 
> (django.tests.forms_tests.tests.test_forms.FormsTestCase.test_templates_with_forms).
>
> On Friday, November 20, 2015 at 8:31:55 PM UTC+1, Tim Graham wrote:
>>
>> Looks easy enough. I was going to write, "Seems to me that there's more 
>> complexity in a deprecation path that requires a temporary opt-in setting 
>> rather than simply making the backwards incompatible change. Unless I 
>> missed something, adding CSS like that shouldn't cause problems for any 
>> apps maintaining compatibility with older versions of Django." but then I 
>> thought of a different case where it could be trickier to upgrade: 
>> developers who are specifying label='lower string' in some places to 
>> workaround the current behavior (but still want uppercased labels 
>> everywhere else). I guess the solution would be to use the text-transform 
>> rule you mentioned and another CSS rule targeting all labels IDs that you 
>> want to remain lowercased.
>>
>> I'd like other opinions about whether or not a deprecation seems helpful 
>> for this. Personally, I'd rather just fix my CSS when upgrading rather than 
>> fix my CSS *and* add a setting for a few Django versions to silence the 
>> deprecation. I guess some people might like a few Django versions to update 
>> their CSS though (also we promised to try to provide fairly seamless 
>> upgrades from one LTS to the next).
>>
>> On Friday, November 20, 2015 at 11:38:53 AM UTC-5, Sergei Maertens wrote:
>>>
>>> In 
>>> https://github.com/django/django/blob/master/django/contrib/admin/static/admin/css/forms.css#L31
>>>  
>>> ,
>>>  
>>> after
>>> label {
>>>font-weight: normal;
>>>color:#666;
>>>font-size:13px;
>>> }
>>>
>>> you would add
>>> label::first-letter {
>>>text-transform: capitalize;
>>> }
>>>
>>> (see https://css-tricks.com/almanac/selectors/f/first-letter/)
>>>
>>> text-transform: capitalize on the label itself would capitalize all 
>>> words, which is not wanted. The ::first-letter pseudo-selector is supported 
>>> on all browsers, for IE 8 and lower you need a sigle colon instead of a 
>>> double colon.
>>>
>>>
>>> On Thursday, November 19, 2015 at 11:23:48 PM UTC+1, Tim Graham wrote:

 I'd like to see the admin's CSS 

Re: Form field labels change proposal

[Sergei Maertens]

I've done the initial work for a patch, assuming a 'hard' change without 
deprecation path, the branch is 
here: 
https://github.com/sergei-maertens/django/commit/2f3c1d8dd56522dc69448ec20aac28d4ddc70ac4.
 
Tests should be passing.

I've also taken a quick glance at django-admin-tools to check if they do 
anything special with decapitalizing/capitalizing things, but all seems to 
be well. Django injects the form css in the block extrastyle within 
change_form.html. For Grappelli/django-xadmin that block is present, but 
Grappelli overrides change_form.html, so that would probably need updating. 
I haven't looked at any other admin-theme packages, but the change would be 
trivial for them as well - providing a proper documentation notion.

The only things so far I'm not really sure of are:

   - Is deprecation required or not (input needed from other core devs I 
   presume)
   - what with the validation error messages: as it stands, field labels 
   are capitalized at the moment, and they're not in a  tag. Examples 
   can be found 
   in: django.db.models.base.Model.(date_error_message|unique_error_message)

In the tests I also noticed that there are cases where the label itself is 
not wrapped in a  tag 
(django.tests.forms_tests.tests.test_forms.FormsTestCase.test_templates_with_forms).

On Friday, November 20, 2015 at 8:31:55 PM UTC+1, Tim Graham wrote:
>
> Looks easy enough. I was going to write, "Seems to me that there's more 
> complexity in a deprecation path that requires a temporary opt-in setting 
> rather than simply making the backwards incompatible change. Unless I 
> missed something, adding CSS like that shouldn't cause problems for any 
> apps maintaining compatibility with older versions of Django." but then I 
> thought of a different case where it could be trickier to upgrade: 
> developers who are specifying label='lower string' in some places to 
> workaround the current behavior (but still want uppercased labels 
> everywhere else). I guess the solution would be to use the text-transform 
> rule you mentioned and another CSS rule targeting all labels IDs that you 
> want to remain lowercased.
>
> I'd like other opinions about whether or not a deprecation seems helpful 
> for this. Personally, I'd rather just fix my CSS when upgrading rather than 
> fix my CSS *and* add a setting for a few Django versions to silence the 
> deprecation. I guess some people might like a few Django versions to update 
> their CSS though (also we promised to try to provide fairly seamless 
> upgrades from one LTS to the next).
>
> On Friday, November 20, 2015 at 11:38:53 AM UTC-5, Sergei Maertens wrote:
>>
>> In 
>> https://github.com/django/django/blob/master/django/contrib/admin/static/admin/css/forms.css#L31
>>  
>> ,
>>  
>> after
>> label {
>>font-weight: normal;
>>color:#666;
>>font-size:13px;
>> }
>>
>> you would add
>> label::first-letter {
>>text-transform: capitalize;
>> }
>>
>> (see https://css-tricks.com/almanac/selectors/f/first-letter/)
>>
>> text-transform: capitalize on the label itself would capitalize all 
>> words, which is not wanted. The ::first-letter pseudo-selector is supported 
>> on all browsers, for IE 8 and lower you need a sigle colon instead of a 
>> double colon.
>>
>>
>> On Thursday, November 19, 2015 at 11:23:48 PM UTC+1, Tim Graham wrote:
>>>
>>> I'd like to see the admin's CSS updated under the assumption that this 
>>> change moves forward to better understand the extent of changes that would 
>>> be required from Django users to maintain the current behavior.
>>>
>>> On Thursday, November 19, 2015 at 4:52:57 PM UTC-5, Sergei Maertens 
>>> wrote:

 Yes, I've thought about a setting as well briefly but quickly discarded 
 it because it would be 'yet another setting'. But this one would ofcourse 
 be temporarily, and if that's been applied successfully in the past, then 
 that's probably the best way to tackle this.

 I'd be happy to write the patch for this myself if no objections turn 
 up.

 On Thursday, November 19, 2015 at 10:49:49 PM UTC+1, Tim Graham wrote:
>
> The best solution I can think of at the moment would be a setting 
> allowing users to opt-in to the new behavior which would then silence the 
> warning. That leaves you with a defunct setting once the deprecation 
> period 
> completes. That's basically how SessionAuthenticationMiddleware 
> worked when we decided to require it.
>
> On Thursday, November 19, 2015 at 4:13:40 PM UTC-5, Sergei Maertens 
> wrote:
>>
>> Good catch.
>>
>> I'm not sure, haven't there been similar cases in the past? First 
>> thing I can think of is using naive datetimes when timezone-support is 
>> enabled, and then 

Re: Form field labels change proposal

[sven]

It has been said before but CSS was made for this and we should not mix 
content with design. I'd like to see this implemented with or without the 
deprecation path.

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/024bd636-be28-4fd3-8a6f-d1a07f88b423%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Form field labels change proposal

[Tim Graham]

Looks easy enough. I was going to write, "Seems to me that there's more 
complexity in a deprecation path that requires a temporary opt-in setting 
rather than simply making the backwards incompatible change. Unless I 
missed something, adding CSS like that shouldn't cause problems for any 
apps maintaining compatibility with older versions of Django." but then I 
thought of a different case where it could be trickier to upgrade: 
developers who are specifying label='lower string' in some places to 
workaround the current behavior (but still want uppercased labels 
everywhere else). I guess the solution would be to use the text-transform 
rule you mentioned and another CSS rule targeting all labels IDs that you 
want to remain lowercased.

I'd like other opinions about whether or not a deprecation seems helpful 
for this. Personally, I'd rather just fix my CSS when upgrading rather than 
fix my CSS *and* add a setting for a few Django versions to silence the 
deprecation. I guess some people might like a few Django versions to update 
their CSS though (also we promised to try to provide fairly seamless 
upgrades from one LTS to the next).

On Friday, November 20, 2015 at 11:38:53 AM UTC-5, Sergei Maertens wrote:
>
> In 
> https://github.com/django/django/blob/master/django/contrib/admin/static/admin/css/forms.css#L31
>  
> ,
>  
> after
> label {
>font-weight: normal;
>color:#666;
>font-size:13px;
> }
>
> you would add
> label::first-letter {
>text-transform: capitalize;
> }
>
> (see https://css-tricks.com/almanac/selectors/f/first-letter/)
>
> text-transform: capitalize on the label itself would capitalize all words, 
> which is not wanted. The ::first-letter pseudo-selector is supported on all 
> browsers, for IE 8 and lower you need a sigle colon instead of a double 
> colon.
>
>
> On Thursday, November 19, 2015 at 11:23:48 PM UTC+1, Tim Graham wrote:
>>
>> I'd like to see the admin's CSS updated under the assumption that this 
>> change moves forward to better understand the extent of changes that would 
>> be required from Django users to maintain the current behavior.
>>
>> On Thursday, November 19, 2015 at 4:52:57 PM UTC-5, Sergei Maertens wrote:
>>>
>>> Yes, I've thought about a setting as well briefly but quickly discarded 
>>> it because it would be 'yet another setting'. But this one would ofcourse 
>>> be temporarily, and if that's been applied successfully in the past, then 
>>> that's probably the best way to tackle this.
>>>
>>> I'd be happy to write the patch for this myself if no objections turn up.
>>>
>>> On Thursday, November 19, 2015 at 10:49:49 PM UTC+1, Tim Graham wrote:

 The best solution I can think of at the moment would be a setting 
 allowing users to opt-in to the new behavior which would then silence the 
 warning. That leaves you with a defunct setting once the deprecation 
 period 
 completes. That's basically how SessionAuthenticationMiddleware worked 
 when we decided to require it.

 On Thursday, November 19, 2015 at 4:13:40 PM UTC-5, Sergei Maertens 
 wrote:
>
> Good catch.
>
> I'm not sure, haven't there been similar cases in the past? First 
> thing I can think of is using naive datetimes when timezone-support is 
> enabled, and then you get a warning for each naive datetime you use, but 
> that's of course different then a DeprecationWarning.
>
> It's probably not best practice, but maybe it could be tracked with a 
> module-level flag/constant, to check if the warning has been emited or 
> not, 
> ensuring that it gets only emited once during the lifetime of a thread?
>
> On Thursday, November 19, 2015 at 7:27:18 PM UTC+1, Tim Graham wrote:
>>
>> How would a developer acknowledge/silence that deprecation warning? 
>> It seems to me that if it's emitted for every form field in a project 
>> that's not really going to be helpful.
>>
>> On Wednesday, November 11, 2015 at 11:47:46 AM UTC-5, Sergei Maertens 
>> wrote:
>>>
>>> I think I would start with locally creating a wrapper capfirst that 
>>> is only called in the referenced line and 
>>> https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L2069
>>>  
>>> (missed that one in the previous post) and possible other ocurrences. 
>>> Emit 
>>> a PendingDeprecationWarning, something along the lines of
>>>
>>> def deprecated_capfirst(value):
>>> warnings.warn(
>>> "form field labels generated from model field 'verbose_name' 
>>> will no longer automatically be capitalized",
>>> PendingDeprecationWarning, stacklevel=2
>>> )
>>> return capfirst(value)
>>>
>>> and 

Re: Form field labels change proposal

[Sergei Maertens]

In 
https://github.com/django/django/blob/master/django/contrib/admin/static/admin/css/forms.css#L31,
 
after
label {
   font-weight: normal;
   color:#666;
   font-size:13px;
}

you would add
label::first-letter {
   text-transform: capitalize;
}

(see https://css-tricks.com/almanac/selectors/f/first-letter/)

text-transform: capitalize on the label itself would capitalize all words, 
which is not wanted. The ::first-letter pseudo-selector is supported on all 
browsers, for IE 8 and lower you need a sigle colon instead of a double 
colon.


On Thursday, November 19, 2015 at 11:23:48 PM UTC+1, Tim Graham wrote:
>
> I'd like to see the admin's CSS updated under the assumption that this 
> change moves forward to better understand the extent of changes that would 
> be required from Django users to maintain the current behavior.
>
> On Thursday, November 19, 2015 at 4:52:57 PM UTC-5, Sergei Maertens wrote:
>>
>> Yes, I've thought about a setting as well briefly but quickly discarded 
>> it because it would be 'yet another setting'. But this one would ofcourse 
>> be temporarily, and if that's been applied successfully in the past, then 
>> that's probably the best way to tackle this.
>>
>> I'd be happy to write the patch for this myself if no objections turn up.
>>
>> On Thursday, November 19, 2015 at 10:49:49 PM UTC+1, Tim Graham wrote:
>>>
>>> The best solution I can think of at the moment would be a setting 
>>> allowing users to opt-in to the new behavior which would then silence the 
>>> warning. That leaves you with a defunct setting once the deprecation period 
>>> completes. That's basically how SessionAuthenticationMiddleware worked 
>>> when we decided to require it.
>>>
>>> On Thursday, November 19, 2015 at 4:13:40 PM UTC-5, Sergei Maertens 
>>> wrote:

 Good catch.

 I'm not sure, haven't there been similar cases in the past? First thing 
 I can think of is using naive datetimes when timezone-support is enabled, 
 and then you get a warning for each naive datetime you use, but that's of 
 course different then a DeprecationWarning.

 It's probably not best practice, but maybe it could be tracked with a 
 module-level flag/constant, to check if the warning has been emited or 
 not, 
 ensuring that it gets only emited once during the lifetime of a thread?

 On Thursday, November 19, 2015 at 7:27:18 PM UTC+1, Tim Graham wrote:
>
> How would a developer acknowledge/silence that deprecation warning? It 
> seems to me that if it's emitted for every form field in a project that's 
> not really going to be helpful.
>
> On Wednesday, November 11, 2015 at 11:47:46 AM UTC-5, Sergei Maertens 
> wrote:
>>
>> I think I would start with locally creating a wrapper capfirst that 
>> is only called in the referenced line and 
>> https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L2069
>>  
>> (missed that one in the previous post) and possible other ocurrences. 
>> Emit 
>> a PendingDeprecationWarning, something along the lines of
>>
>> def deprecated_capfirst(value):
>> warnings.warn(
>> "form field labels generated from model field 'verbose_name' 
>> will no longer automatically be capitalized",
>> PendingDeprecationWarning, stacklevel=2
>> )
>> return capfirst(value)
>>
>> and replace the capfirst with deprecated_capfirst ofcourse. At the 
>> same time, in the admin the CSS for labels can be added to 
>> text-transform 
>> them to capitalize.
>>
>> In the next Django version this becomes loud, and in the next+1 
>> version it is effectively removed.
>>
>> As soon as the PendingDeprecation is added, the entry should be added 
>> to the docs with example CSS to make your own templates/styling 
>> capitalize 
>> the labels - and/or mention the `capfirst` template filter.
>>
>> Thoughts?
>>
>>
>> On Wednesday, November 11, 2015 at 5:32:57 PM UTC+1, Tim Graham wrote:
>>>
>>> How do you envision putting this through a deprecation cycle?
>>>
>>> On Wednesday, November 11, 2015 at 10:59:46 AM UTC-5, Sergei 
>>> Maertens 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 

Re: Form field labels change proposal

[Tim Graham]

I'd like to see the admin's CSS updated under the assumption that this 
change moves forward to better understand the extent of changes that would 
be required from Django users to maintain the current behavior.

On Thursday, November 19, 2015 at 4:52:57 PM UTC-5, Sergei Maertens wrote:
>
> Yes, I've thought about a setting as well briefly but quickly discarded it 
> because it would be 'yet another setting'. But this one would ofcourse be 
> temporarily, and if that's been applied successfully in the past, then 
> that's probably the best way to tackle this.
>
> I'd be happy to write the patch for this myself if no objections turn up.
>
> On Thursday, November 19, 2015 at 10:49:49 PM UTC+1, Tim Graham wrote:
>>
>> The best solution I can think of at the moment would be a setting 
>> allowing users to opt-in to the new behavior which would then silence the 
>> warning. That leaves you with a defunct setting once the deprecation period 
>> completes. That's basically how SessionAuthenticationMiddleware worked 
>> when we decided to require it.
>>
>> On Thursday, November 19, 2015 at 4:13:40 PM UTC-5, Sergei Maertens wrote:
>>>
>>> Good catch.
>>>
>>> I'm not sure, haven't there been similar cases in the past? First thing 
>>> I can think of is using naive datetimes when timezone-support is enabled, 
>>> and then you get a warning for each naive datetime you use, but that's of 
>>> course different then a DeprecationWarning.
>>>
>>> It's probably not best practice, but maybe it could be tracked with a 
>>> module-level flag/constant, to check if the warning has been emited or not, 
>>> ensuring that it gets only emited once during the lifetime of a thread?
>>>
>>> On Thursday, November 19, 2015 at 7:27:18 PM UTC+1, Tim Graham wrote:

 How would a developer acknowledge/silence that deprecation warning? It 
 seems to me that if it's emitted for every form field in a project that's 
 not really going to be helpful.

 On Wednesday, November 11, 2015 at 11:47:46 AM UTC-5, Sergei Maertens 
 wrote:
>
> I think I would start with locally creating a wrapper capfirst that is 
> only called in the referenced line and 
> https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L2069
>  
> (missed that one in the previous post) and possible other ocurrences. 
> Emit 
> a PendingDeprecationWarning, something along the lines of
>
> def deprecated_capfirst(value):
> warnings.warn(
> "form field labels generated from model field 'verbose_name' 
> will no longer automatically be capitalized",
> PendingDeprecationWarning, stacklevel=2
> )
> return capfirst(value)
>
> and replace the capfirst with deprecated_capfirst ofcourse. At the 
> same time, in the admin the CSS for labels can be added to text-transform 
> them to capitalize.
>
> In the next Django version this becomes loud, and in the next+1 
> version it is effectively removed.
>
> As soon as the PendingDeprecation is added, the entry should be added 
> to the docs with example CSS to make your own templates/styling 
> capitalize 
> the labels - and/or mention the `capfirst` template filter.
>
> Thoughts?
>
>
> On Wednesday, November 11, 2015 at 5:32:57 PM UTC+1, Tim Graham wrote:
>>
>> How do you envision putting this through a deprecation cycle?
>>
>> On Wednesday, November 11, 2015 at 10:59:46 AM UTC-5, Sergei Maertens 
>> 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 

Re: Form field labels change proposal

[Sergei Maertens]

Yes, I've thought about a setting as well briefly but quickly discarded it 
because it would be 'yet another setting'. But this one would ofcourse be 
temporarily, and if that's been applied successfully in the past, then 
that's probably the best way to tackle this.

I'd be happy to write the patch for this myself if no objections turn up.

On Thursday, November 19, 2015 at 10:49:49 PM UTC+1, Tim Graham wrote:
>
> The best solution I can think of at the moment would be a setting allowing 
> users to opt-in to the new behavior which would then silence the warning. 
> That leaves you with a defunct setting once the deprecation period 
> completes. That's basically how SessionAuthenticationMiddleware worked 
> when we decided to require it.
>
> On Thursday, November 19, 2015 at 4:13:40 PM UTC-5, Sergei Maertens wrote:
>>
>> Good catch.
>>
>> I'm not sure, haven't there been similar cases in the past? First thing I 
>> can think of is using naive datetimes when timezone-support is enabled, and 
>> then you get a warning for each naive datetime you use, but that's of 
>> course different then a DeprecationWarning.
>>
>> It's probably not best practice, but maybe it could be tracked with a 
>> module-level flag/constant, to check if the warning has been emited or not, 
>> ensuring that it gets only emited once during the lifetime of a thread?
>>
>> On Thursday, November 19, 2015 at 7:27:18 PM UTC+1, Tim Graham wrote:
>>>
>>> How would a developer acknowledge/silence that deprecation warning? It 
>>> seems to me that if it's emitted for every form field in a project that's 
>>> not really going to be helpful.
>>>
>>> On Wednesday, November 11, 2015 at 11:47:46 AM UTC-5, Sergei Maertens 
>>> wrote:

 I think I would start with locally creating a wrapper capfirst that is 
 only called in the referenced line and 
 https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L2069
  
 (missed that one in the previous post) and possible other ocurrences. Emit 
 a PendingDeprecationWarning, something along the lines of

 def deprecated_capfirst(value):
 warnings.warn(
 "form field labels generated from model field 'verbose_name' 
 will no longer automatically be capitalized",
 PendingDeprecationWarning, stacklevel=2
 )
 return capfirst(value)

 and replace the capfirst with deprecated_capfirst ofcourse. At the same 
 time, in the admin the CSS for labels can be added to text-transform them 
 to capitalize.

 In the next Django version this becomes loud, and in the next+1 version 
 it is effectively removed.

 As soon as the PendingDeprecation is added, the entry should be added 
 to the docs with example CSS to make your own templates/styling capitalize 
 the labels - and/or mention the `capfirst` template filter.

 Thoughts?


 On Wednesday, November 11, 2015 at 5:32:57 PM UTC+1, Tim Graham wrote:
>
> How do you envision putting this through a deprecation cycle?
>
> On Wednesday, November 11, 2015 at 10:59:46 AM UTC-5, Sergei Maertens 
> 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 

Re: Form field labels change proposal

[Tim Graham]

The best solution I can think of at the moment would be a setting allowing 
users to opt-in to the new behavior which would then silence the warning. 
That leaves you with a defunct setting once the deprecation period 
completes. That's basically how SessionAuthenticationMiddleware worked when 
we decided to require it.

On Thursday, November 19, 2015 at 4:13:40 PM UTC-5, Sergei Maertens wrote:
>
> Good catch.
>
> I'm not sure, haven't there been similar cases in the past? First thing I 
> can think of is using naive datetimes when timezone-support is enabled, and 
> then you get a warning for each naive datetime you use, but that's of 
> course different then a DeprecationWarning.
>
> It's probably not best practice, but maybe it could be tracked with a 
> module-level flag/constant, to check if the warning has been emited or not, 
> ensuring that it gets only emited once during the lifetime of a thread?
>
> On Thursday, November 19, 2015 at 7:27:18 PM UTC+1, Tim Graham wrote:
>>
>> How would a developer acknowledge/silence that deprecation warning? It 
>> seems to me that if it's emitted for every form field in a project that's 
>> not really going to be helpful.
>>
>> On Wednesday, November 11, 2015 at 11:47:46 AM UTC-5, Sergei Maertens 
>> wrote:
>>>
>>> I think I would start with locally creating a wrapper capfirst that is 
>>> only called in the referenced line and 
>>> https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L2069
>>>  
>>> (missed that one in the previous post) and possible other ocurrences. Emit 
>>> a PendingDeprecationWarning, something along the lines of
>>>
>>> def deprecated_capfirst(value):
>>> warnings.warn(
>>> "form field labels generated from model field 'verbose_name' 
>>> will no longer automatically be capitalized",
>>> PendingDeprecationWarning, stacklevel=2
>>> )
>>> return capfirst(value)
>>>
>>> and replace the capfirst with deprecated_capfirst ofcourse. At the same 
>>> time, in the admin the CSS for labels can be added to text-transform them 
>>> to capitalize.
>>>
>>> In the next Django version this becomes loud, and in the next+1 version 
>>> it is effectively removed.
>>>
>>> As soon as the PendingDeprecation is added, the entry should be added to 
>>> the docs with example CSS to make your own templates/styling capitalize the 
>>> labels - and/or mention the `capfirst` template filter.
>>>
>>> Thoughts?
>>>
>>>
>>> On Wednesday, November 11, 2015 at 5:32:57 PM UTC+1, Tim Graham wrote:

 How do you envision putting this through a deprecation cycle?

 On Wednesday, November 11, 2015 at 10:59:46 AM UTC-5, Sergei Maertens 
 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 
>   

Re: Form field labels change proposal

[Sergei Maertens]

Good catch.

I'm not sure, haven't there been similar cases in the past? First thing I 
can think of is using naive datetimes when timezone-support is enabled, and 
then you get a warning for each naive datetime you use, but that's of 
course different then a DeprecationWarning.

It's probably not best practice, but maybe it could be tracked with a 
module-level flag/constant, to check if the warning has been emited or not, 
ensuring that it gets only emited once during the lifetime of a thread?

On Thursday, November 19, 2015 at 7:27:18 PM UTC+1, Tim Graham wrote:
>
> How would a developer acknowledge/silence that deprecation warning? It 
> seems to me that if it's emitted for every form field in a project that's 
> not really going to be helpful.
>
> On Wednesday, November 11, 2015 at 11:47:46 AM UTC-5, Sergei Maertens 
> wrote:
>>
>> I think I would start with locally creating a wrapper capfirst that is 
>> only called in the referenced line and 
>> https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L2069
>>  
>> (missed that one in the previous post) and possible other ocurrences. Emit 
>> a PendingDeprecationWarning, something along the lines of
>>
>> def deprecated_capfirst(value):
>> warnings.warn(
>> "form field labels generated from model field 'verbose_name' will 
>> no longer automatically be capitalized",
>> PendingDeprecationWarning, stacklevel=2
>> )
>> return capfirst(value)
>>
>> and replace the capfirst with deprecated_capfirst ofcourse. At the same 
>> time, in the admin the CSS for labels can be added to text-transform them 
>> to capitalize.
>>
>> In the next Django version this becomes loud, and in the next+1 version 
>> it is effectively removed.
>>
>> As soon as the PendingDeprecation is added, the entry should be added to 
>> the docs with example CSS to make your own templates/styling capitalize the 
>> labels - and/or mention the `capfirst` template filter.
>>
>> Thoughts?
>>
>>
>> On Wednesday, November 11, 2015 at 5:32:57 PM UTC+1, Tim Graham wrote:
>>>
>>> How do you envision putting this through a deprecation cycle?
>>>
>>> On Wednesday, November 11, 2015 at 10:59:46 AM UTC-5, Sergei Maertens 
>>> 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 

Re: Form field labels change proposal

[Tim Graham]

How would a developer acknowledge/silence that deprecation warning? It 
seems to me that if it's emitted for every form field in a project that's 
not really going to be helpful.

On Wednesday, November 11, 2015 at 11:47:46 AM UTC-5, Sergei Maertens wrote:
>
> I think I would start with locally creating a wrapper capfirst that is 
> only called in the referenced line and 
> https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L2069
>  
> (missed that one in the previous post) and possible other ocurrences. Emit 
> a PendingDeprecationWarning, something along the lines of
>
> def deprecated_capfirst(value):
> warnings.warn(
> "form field labels generated from model field 'verbose_name' will 
> no longer automatically be capitalized",
> PendingDeprecationWarning, stacklevel=2
> )
> return capfirst(value)
>
> and replace the capfirst with deprecated_capfirst ofcourse. At the same 
> time, in the admin the CSS for labels can be added to text-transform them 
> to capitalize.
>
> In the next Django version this becomes loud, and in the next+1 version it 
> is effectively removed.
>
> As soon as the PendingDeprecation is added, the entry should be added to 
> the docs with example CSS to make your own templates/styling capitalize the 
> labels - and/or mention the `capfirst` template filter.
>
> Thoughts?
>
>
> On Wednesday, November 11, 2015 at 5:32:57 PM UTC+1, Tim Graham wrote:
>>
>> How do you envision putting this through a deprecation cycle?
>>
>> On Wednesday, November 11, 2015 at 10:59:46 AM UTC-5, Sergei Maertens 
>> 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 

Re: Form field labels change proposal

[Aymeric Augustin]

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  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 
> .
> 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/567142d7-0da1-49ed-9994-a43a834af551%40googlegroups.com
>  
> .
> For more options, visit 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 

Re: Form field labels change proposal

[Joeri]

I really don't like text-styling functions in Django that are (even 
indirectly) used in templates. CSS was made for this.

The solution Sergei proposed smoothly transitions the admin. However, alot 
of forms will be affected as well and thus alot of users.
The deprecation warning Sergei proposes warns people that upgrade to a new 
Django version about the change. A changelog suggestion to override the 
label or add some CSS should be straightforward and a small task compared 
to some other changes I've seen with previous upgrades.

And we get a cleaner Django, jeej.


Op woensdag 11 november 2015 17:47:46 UTC+1 schreef Sergei Maertens:
>
> I think I would start with locally creating a wrapper capfirst that is 
> only called in the referenced line and 
> https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L2069
>  
> (missed that one in the previous post) and possible other ocurrences. Emit 
> a PendingDeprecationWarning, something along the lines of
>
> def deprecated_capfirst(value):
> warnings.warn(
> "form field labels generated from model field 'verbose_name' will 
> no longer automatically be capitalized",
> PendingDeprecationWarning, stacklevel=2
> )
> return capfirst(value)
>
> and replace the capfirst with deprecated_capfirst ofcourse. At the same 
> time, in the admin the CSS for labels can be added to text-transform them 
> to capitalize.
>
> In the next Django version this becomes loud, and in the next+1 version it 
> is effectively removed.
>
> As soon as the PendingDeprecation is added, the entry should be added to 
> the docs with example CSS to make your own templates/styling capitalize the 
> labels - and/or mention the `capfirst` template filter.
>
> Thoughts?
>
>
> On Wednesday, November 11, 2015 at 5:32:57 PM UTC+1, Tim Graham wrote:
>>
>> How do you envision putting this through a deprecation cycle?
>>
>> On Wednesday, November 11, 2015 at 10:59:46 AM UTC-5, Sergei Maertens 
>> 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 

Re: Form field labels change proposal

[Sergei Maertens]

I think I would start with locally creating a wrapper capfirst that is only 
called in the referenced line 
and 
https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L2069
 
(missed that one in the previous post) and possible other ocurrences. Emit 
a PendingDeprecationWarning, something along the lines of

def deprecated_capfirst(value):
warnings.warn(
"form field labels generated from model field 'verbose_name' will 
no longer automatically be capitalized",
PendingDeprecationWarning, stacklevel=2
)
return capfirst(value)

and replace the capfirst with deprecated_capfirst ofcourse. At the same 
time, in the admin the CSS for labels can be added to text-transform them 
to capitalize.

In the next Django version this becomes loud, and in the next+1 version it 
is effectively removed.

As soon as the PendingDeprecation is added, the entry should be added to 
the docs with example CSS to make your own templates/styling capitalize the 
labels - and/or mention the `capfirst` template filter.

Thoughts?


On Wednesday, November 11, 2015 at 5:32:57 PM UTC+1, Tim Graham wrote:
>
> How do you envision putting this through a deprecation cycle?
>
> On Wednesday, November 11, 2015 at 10:59:46 AM UTC-5, Sergei Maertens 
> 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: 

Re: Form field labels change proposal

[Tim Graham]

How do you envision putting this through a deprecation cycle?

On Wednesday, November 11, 2015 at 10:59:46 AM UTC-5, Sergei Maertens 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.
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/ae956797-e09c-4489-8b7b-0cd9bb7a12aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.