Opened 10 years ago

Last modified 13 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)

proposal-22887.patch (7.9 KB ) - added by Vlada Macek 10 years ago.

Download all attachments as: .zip

Change History (17)

comment:1 by Vlada Macek, 10 years ago

comment:2 by Claude Paroz, 10 years ago

Triage Stage: UnreviewedAccepted

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.

comment:3 by Gabriel Muñumel, 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 Federico Frenguelli, 10 years ago

Owner: changed from nobody to Federico Frenguelli
Status: newassigned

Working on this during EP14 sprints.

Last edited 10 years ago by Federico Frenguelli (previous) (diff)

comment:5 by Federico Frenguelli, 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 Claude Paroz <claude@…>, 10 years ago

Resolution: fixed
Status: assignedclosed

In 6eed751162f10a3e93f4fa7c1eed2c43b70bb0ca:

Fixed #22887 -- Added comment for translators on unique_for_date error message

comment:7 by Claude Paroz <claude@…>, 10 years ago

In bc3d401b9f95ebc5bd25488708b5a82074c53ebb:

[1.7.x] Fixed #22887 -- Added comment for translators on unique_for_date error message

Backport of 6eed751162 from master.

in reply to:  2 comment:8 by Vlada Macek, 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.

comment:9 by Claude Paroz, 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.

in reply to:  9 comment:10 by Vlada Macek, 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 Vlada Macek, 10 years ago

Attachment: proposal-22887.patch added

comment:11 by Gabriel Muñumel, 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?

Last edited 10 years ago by Gabriel Muñumel (previous) (diff)

comment:12 by Vlada Macek, 10 years ago

Resolution: fixed
Status: closednew

I hope you don't mind if I reopen so it can be reconsidered. Thanks.

comment:13 by Tim Graham, 10 years ago

Easy pickings: unset
Has patch: set
Needs documentation: set
Triage Stage: AcceptedUnreviewed
Type: BugCleanup/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 Claude Paroz, 10 years ago

Triage Stage: UnreviewedAccepted

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 Mariusz Felisiak, 13 months ago

Owner: Federico Frenguelli removed
Status: newassigned

comment:16 by Mariusz Felisiak, 13 months ago

Status: assignednew
Note: See TracTickets for help on using tickets.
Back to Top