Opened 9 months ago

Last modified 6 months ago

#22887 new Cleanup/optimization

unique_for_date error message in Field has untranslated param lookup_type

Reported by: Tuttle Owned by: synasius
Component: Internationalization Version: master
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 Tuttle 7 months ago.

Download all attachments as: .zip

Change History (15)

comment:1 Changed 9 months ago by Tuttle

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 follow-up: Changed 9 months ago by claudep

  • Triage Stage changed from Unreviewed to Accepted

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 Changed 7 months ago by gmunumel

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 Changed 7 months ago by synasius

  • Owner changed from nobody to synasius
  • Status changed from new to assigned

Working on this during EP14 sprints.

Last edited 7 months ago by synasius (previous) (diff)

comment:5 Changed 7 months ago by synasius

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 Changed 7 months ago by Claude Paroz <claude@…>

  • Resolution set to fixed
  • Status changed from assigned to closed

In 6eed751162f10a3e93f4fa7c1eed2c43b70bb0ca:

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

comment:7 Changed 7 months ago by 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.

comment:8 in reply to: ↑ 2 Changed 7 months ago by Tuttle

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 follow-up: Changed 7 months ago by claudep

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 in reply to: ↑ 9 Changed 7 months ago by Tuttle

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.

Changed 7 months ago by Tuttle

comment:11 Changed 7 months ago by gmunumel

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 7 months ago by gmunumel (previous) (diff)

comment:12 Changed 7 months ago by Tuttle

  • Resolution fixed deleted
  • Status changed from closed to new

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

comment:13 Changed 6 months ago by timgraham

  • Easy pickings unset
  • Has patch set
  • Needs documentation set
  • Triage Stage changed from Accepted to Unreviewed
  • Type changed from Bug to 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 Changed 6 months ago by claudep

  • Triage Stage changed from Unreviewed to 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.

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