Opened 17 years ago

Last modified 5 months ago

#5518 new Cleanup/optimization

Capitalized verbose names for models

Reported by: Petr Marhoun <petr.marhoun@…> Owned by:
Component: Internationalization Version: newforms-admin
Severity: Normal Keywords: admin, verbose_name, nfa-someday i18n-nofix
Cc: djbenji@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

There is a difference between models and forms, now the preferred format is:

class Contact(models.Model):
    email = models.CharField(verbose_name=_('email'))

class ContactForm(forms.Form):
    email = forms.CharField(label=_('Email'))

Why is once 'email' and once 'Email'? I think it is quite
inconsistent.

But it is specially bad for translators. Example: I have a model with
ten fields. I use form_for_model and form_for_instance. I realize that
I need a form with seven fields from model and some new fields. So I
have to translate the fields again - gettext doesn't know that 'email'
is similar to 'Email'.

I think it should be possible (not necessary) to use capitalized
verbose names in models. It means to uncapitalized some words in admin

  • but it is possible, I do it in my personal branch.

I thought that this kind of change should be sent to django-developers mailing list first. But there was no answer so there is a ticket.

Ticket #5426 is precondition for it.

I would like to create patch - if you think that it can be applied.

Attachments (1)

05-uncapfirst-verbose-name.diff (14.2 KB ) - added by Petr Marhoun <petr.marhoun@…> 16 years ago.

Download all attachments as: .zip

Change History (23)

comment:1 by James Bennett, 16 years ago

Triage Stage: UnreviewedDesign decision needed

comment:2 by anonymous, 16 years ago

Cc: djbenji@… added

by Petr Marhoun <petr.marhoun@…>, 16 years ago

comment:3 by Petr Marhoun <petr.marhoun@…>, 16 years ago

Support for capitalized and uncapitalized verbose names means that everywhere in admin have to be used with capfirst or with uncapfirst.

I am sorry, my patch depends on some other patches - it is for simple merging. So my patch can't be applied without problem. But I would like to prepare proper patch, if it would be accepted.

comment:4 by jkocherhans, 16 years ago

Resolution: wontfix
Status: newclosed

While I agree that _('Email') and _('email') is inconsistent, I don't see _('Email') anywhere in Django's code. What's preventing you from using the lower filter where you need it, or using all lowercase in your code? Enforcing capitalization in other people's code is none of Django's business. Is there any specific code in Django itself that you find inconsistent? If so, please open new tickets regarding those inconsistencies.

in reply to:  4 comment:5 by Petr Marhoun <petr.marhoun@…>, 16 years ago

Resolution: wontfix
Status: closedreopened

Replying to jkocherhans:

What's preventing you from using the lower filter where you need it, or using all lowercase in your code?

  1. Can I use "capfirst" verbose_name in my models? No, I can't - django.contrib.admin is broken in this situation. Try to use it in your models and check titles and messages in admin.
  1. Can I use "uncapfirst" labels in my forms? No, I can't - django.contrib.admin is broken again. Try to return a field with low first letter from ModelAdmin.formfield_for_dbfield (only an example, there are many methods how to use your own formfields in admin) and check labels in admin. It also breaks some utility functions from core (for example BaseForm.as_table).

(When I say "broken" I mean it doesn't look nice.)

I don't know if I can reopen the ticket it this situation (I am sorry if I can't), but I disagree with your arguments. Application django.contrib.admin prevents me to be consistent in my own code - so I want to fix the application. (This ticket is not about django core.)

Maybe the resolution is right (I only say that arguments for this resolution aren't right). But I think that django.contrib.admin do some magic anyway - what if I want to have titles in admin with first letter low (an example - class eCommerceType)? I only ask you for a little more - it should'n hurt anyone and it could help some people.

Enforcing capitalization in other people's code is none of Django's business.

This change enforces nothing. On the contrary - now django.contrib.admin enforces not to use capitalization. With this patch django.contrib.admin don't care what other people choose.

comment:6 by Christopher Lenz <cmlenz@…>, 16 years ago

If I understand this patch correctly, this would break languages where nouns are capitalized even inside sentences, such as German.

in reply to:  6 ; comment:7 by Michael Radziej, 16 years ago

Replying to Christopher Lenz <cmlenz@gmx.de>:

If I understand this patch correctly, this would break languages where nouns are capitalized even inside sentences, such as German.

Yes. And I doubt that every language uses capitalization in field labels. A clean solution might require:

  • verbose names be always the "raw" forms, e.g. for English lower case, for German dependant on the category (nouns are upper case)
  • a filter tag label that converts the raw form into the label form. For the languages I know, this is the same as firstcap.

in reply to:  7 comment:8 by jkocherhans, 16 years ago

Replying to mir:

Yes. And I doubt that every language uses capitalization in field labels. A clean solution might require:

  • verbose names be always the "raw" forms, e.g. for English lower case, for German dependant on the category (nouns are upper case)
  • a filter tag label that converts the raw form into the label form. For the languages I know, this is the same as firstcap.

Thanks mir. That sounds like a much more acceptable and flexible solution to me. Petr, would you mind starting a thread on django-i18n about this? I'm sure other languages have different capitalization issues that should be addressed as part of this ticket.

comment:9 by Petr Marhoun <petr.marhoun@…>, 16 years ago

I don't understand I didn't think about it. (My applications are only bilingual, but German is the most probable third language). So my solution is bad but opposite approach should work - to use "uncapfirst" expressions for labels.

I think there are two orthogonal problems:

  1. It should be possible to use the same format in models and forms - django.contrib.admin and some utility functions in core should transform it to the right format.
  2. The transformation function should work for all languages, not only for most of them.

I will try to solve point one. I want to change my verbose_name and labels to have first letter low and to fix all problems with capfirst.

The second idea (to replace capfirst with something better) is quite ambitious. I don't think that django supports localized functions and filters. Maybe mir should post to django-i18n - for me the current task is patch for problem one.

comment:10 by jkocherhans, 16 years ago

Keywords: nfa-someday added

Marking as nfa-someday as this isn't blocking a merge of the newforms-admin branch to trunk. This ticket should be closed as wontfix at the next sprint unless someone figures out an acceptable design though.

comment:11 by Malcolm Tredinnick, 16 years ago

The patch here isn't the right solution to any problem. For consistency and eas of use, verbose names should be in the non-title-case format (lower-case for most languages, probably initial upper case for German, etc). Then places like admin can use the capfirst filter on headings that may start with a model name. That's fixing things in the right place (the same sort of thing as the patch in #5519, which does look like it's solving the root problem).

comment:12 by Petr Marhoun <petr.marhoun@…>, 16 years ago

Resolution: invalid
Status: reopenedclosed

I think this problem is real - but more general. It is problem in all forms, not only in forms from admin. And I have created another ticket which could solved it - #6631. So I think this ticket is invalid and it should be closed.

comment:13 by Malcolm Tredinnick, 16 years ago

Resolution: invalid
Status: closedreopened

This ticket isn't invalid, since it describes quite a valid issue. Perhaps you meant "duplicate", but I'm going to reopen it all the same. This ticket describes a particular issue, #6631 describes a complex solution to a sort of related problem. I'm not convinced that #6631 really is the right solution to the problems it's solving, so I think that deferring this ticket's solution to that one is premature for now. We have the link between the two tickets now, so anybody looking at this will do so considering #6631 as well, but I'd like to keep this open until we have a solution in place, pleaes.

comment:14 by Marc Garcia, 15 years ago

Keywords: i18n-nofix added

comment:15 by Malcolm Tredinnick, 14 years ago

Triage Stage: Design decision neededAccepted

Design decision (after much discussion between jezdez, Russ and myself): whenever the verbose name on a model or form field is specified, we should not run the result through the capfirst filter. If we are auto-generating the label string, we should be using the equivalent of capfirst.

This is not going to be entirely simple to implement, since it moves the capfirst-ing out of the template into the form data generation, perhaps. But it's the only backwards-incompatible, let everything be possible solution we can find that is likely to work.

comment:16 by Jannis Leidel, 13 years ago

Summary: [newform-admin] - capitalized verbose names for modelsCapitalized verbose names for models

comment:17 by Gabriel Hurley, 13 years ago

Severity: Normal
Type: Cleanup/optimization

comment:18 by Aymeric Augustin, 12 years ago

UI/UX: unset

Change UI/UX from NULL to False.

comment:19 by Aymeric Augustin, 12 years ago

Easy pickings: unset

Change Easy pickings from NULL to False.

comment:20 by Aymeric Augustin, 11 years ago

Status: reopenednew

comment:21 by Tom Carrick, 5 months ago

Owner: changed from nobody to Tom Carrick
Status: newassigned

comment:22 by Tom Carrick, 5 months ago

Owner: Tom Carrick removed
Status: assignednew
Note: See TracTickets for help on using tickets.
Back to Top