unique_for_date error message in Field has untranslated param lookup_type

[Vlada Macek]

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. :-)

[Claude Paroz]

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.

[Gabriel Muñumel]

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)?

[Federico Frenguelli]

Working on this during EP14 sprints.

[Federico Frenguelli]

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.

[Claude Paroz <claude@…>]

In 6eed751162f10a3e93f4fa7c1eed2c43b70bb0ca:

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

[Claude Paroz <claude@…>]

In bc3d401b9f95ebc5bd25488708b5a82074c53ebb:

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

Backport of 6eed751162 from master.

[Vlada Macek]

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.

[Claude Paroz]

I don't completely exclude having different messages, but I fear potential code complexity. Maybe having a patch would help evaluate the feasibility.

[Vlada Macek]

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.

[Gabriel Muñumel]

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?

[Vlada Macek]

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

[Tim Graham]

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.

[Claude Paroz]

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.