#22716: The unique error message uses incorrect grammar
-------------------------------+--------------------------------------
Reporter: jdufresne | Owner: nobody
Type: Uncategorized | Status: closed
Component: Uncategorized | Version: 1.6
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------
Comment (by jdufresne):
> When we refer to a field or its contents in writing, it's perfectly
normal to capitalise the name of the field. The same goes for the names of
menus, buttons and so on.
Just to be clear, are you arguing that it is *ideal* that the field name
is capitalized in the middle of the sentence or merely arguing that it is
acceptable and wish to take no action out of convenience? If the later,
why not strive for the ideal?
> For example, "%(model_name)s with this %(field_labels)s already exists."
-- if we remove capfirst from model_name then the sentence wouldn't start
with a capital (yes, maybe we could capfirst the entire sentence to fix
that). If someone is using a custom error message where field_label is
first, then they will have to make a fix if we stop capitalizing
field_label.
Ah I see. So the end result is not the compatibility issue, but the
meaning of the placeholder `field_label`. Got it. That makes sense.
I agree that sentences starting with the field name should continue to be
capitalized properly. I would not want to lose this behavior. There are
default error messages where this is the case. So a solution would need to
be a part of the pull request.
As you mentioned, one solution is to `capfirst` the entire sentence.
However, if a word is intentionally lower cased, this will prevent it from
being lower cased at the beginning of the sentence. I can't think of too
many examples of this, but some creators intentionally title their work
with lower casing. systemd is one such example:
http://www.freedesktop.org/wiki/Software/systemd/.
Another solution would be to introduce a new placeholder
`field_label_capfirst` (or whatever spelling the core devs find
appropriate). This could be introduced in stages to avoid immediate
backwards compatibility issues. Below each step could represent a
sequential release.
0. Introduce `field_label_capfirst`; `field_label` remains as is. Users
can immediately use the capfirst version.
0. Usage of `field_label` produces a warning that behavior will change in
the next release to not be capitalized.
0. Usage of `field_label` changes to not be capitalized.
If necessary, we could do the same for `model_name` at the same time.
So that it two possible solutions. I'm open to others as well. If others
agree this is a good solution, I'm willing to draft a pull request if it
has a real chance of being accepted.
--
Ticket URL: <https://code.djangoproject.com/ticket/22716#comment:7>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/067.451ff114fc6de2b26620635d9415e4e4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
