Opened 10 years ago
Last modified 21 months ago
#22887 new Cleanup/optimization
unique_for_date error message in Field has untranslated param lookup_type
Reported by: | Vlada Macek | Owned by: | |
---|---|---|---|
Component: | Internationalization | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | yes |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | yes |
Description
In the error message
%(field_label)s must be unique for %(date_field_label)s %(lookup_type)s.
the lookup_type
is always one of "date", "year", "month" which can only work in English.
I think there should be a separate error message for each lookup_type
.
The key 'unique_for_date' in the default_error_messages dict looks like it is already specific for the lookup_type == "date"
anyway. :-)
Attachments (1)
Change History (17)
comment:1 by , 10 years ago
follow-up: 8 comment:2 by , 10 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:3 by , 10 years ago
I'd like to made this change. But I don't have clear what's it looking for? May I have to translate lookup_type
into three translated words, for example, in spanish would be: fecha(date), año(year) and mes(month)?
comment:4 by , 10 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
Working on this during EP14 sprints.
comment:5 by , 10 years ago
My work is available here: https://github.com/synasius/django/tree/ticket_22887
The aim is to clarify the meaning of the message so it can be easier to translate in different languages.
comment:6 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:8 by , 10 years ago
Replying to claudep:
Accepted on the base that we should at least provide a translator comment for this string. I admit that such constructed sentences might be a nightmare for translators, however there is almost always some solution, by rephrasing the sentence to give more meaning for the target language. For example in French, we translate this with something like
%(field_label)s must be unique for the %(lookup_type)s part of %(date_field_label)s.
Thanks for at least adding the comment for translators. It's a pity the proper solution was not taken as this is IMO one of the very few cases in django-i18n where suboptimal tricks need to be used. Even the presented french way keeps the English word around.
I have nothing against English, but Django is aimed at the broad audience and I value very much how professional the entire django-i18n effort is and I try to keep up for my language.
Once anyone starts to cut corners, all the depending workers will start to see easier and lower quality paths too.
I thought extending default_error_messages
with two additional messages was not very expensive and pretty clean.
follow-up: 10 comment:9 by , 10 years ago
I don't completely exclude having different messages, but I fear potential code complexity. Maybe having a patch would help evaluate the feasibility.
comment:10 by , 10 years ago
Replying to claudep:
I don't completely exclude having different messages, but I fear potential code complexity. Maybe having a patch would help evaluate the feasibility.
Thank you. I think it could be quite terse, offering the patch. makemessages not done.
by , 10 years ago
Attachment: | proposal-22887.patch added |
---|
comment:11 by , 10 years ago
Hahaha. I finished my patch just to realized that @tuttle already made one :S. But at the end it's almost the same as mine. By the way, if the patch is applied every translated language should be updated, right?
comment:12 by , 10 years ago
Resolution: | fixed |
---|---|
Status: | closed → new |
I hope you don't mind if I reopen so it can be reconsidered. Thanks.
comment:13 by , 10 years ago
Easy pickings: | unset |
---|---|
Has patch: | set |
Needs documentation: | set |
Triage Stage: | Accepted → Unreviewed |
Type: | Bug → Cleanup/optimization |
I'm not passing final judgement, but the proposed patch is backwards incompatible for anyone currently using a custom error message with the unique_for_date
key. I will bump it back to unreviewed since this approach hasn't been accepted yet.
comment:14 by , 10 years ago
Triage Stage: | Unreviewed → Accepted |
---|
In any case, it's a compromise. On one side a bit more verbosity with a slight backwards incompatibility, on the other side better translated messages.
After some thoughts, having literal untranslated date
/year
/month
words inside a user-facing message seems really non optimal in my eyes, so I tend to favor the proposed patch. Docs are missing, though.
comment:15 by , 21 months ago
Owner: | removed |
---|---|
Status: | new → assigned |
comment:16 by , 21 months ago
Status: | assigned → new |
---|
Accepted on the base that we should at least provide a translator comment for this string. I admit that such constructed sentences might be a nightmare for translators, however there is almost always some solution, by rephrasing the sentence to give more meaning for the target language. For example in French, we translate this with something like
%(field_label)s must be unique for the %(lookup_type)s part of %(date_field_label)s.