{{{%(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. :-)
--
Ticket URL: <https://code.djangoproject.com/ticket/22887>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/22887#comment:1>
* stage: Unreviewed => Accepted
Comment:
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.`
--
Ticket URL: <https://code.djangoproject.com/ticket/22887#comment:2>
Comment (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)?
--
Ticket URL: <https://code.djangoproject.com/ticket/22887#comment:3>
* status: new => assigned
* owner: nobody => synasius
--
Ticket URL: <https://code.djangoproject.com/ticket/22887#comment:4>
Comment (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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22887#comment:5>
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"6eed751162f10a3e93f4fa7c1eed2c43b70bb0ca"]:
{{{
#!CommitTicketReference repository=""
revision="6eed751162f10a3e93f4fa7c1eed2c43b70bb0ca"
Fixed #22887 -- Added comment for translators on unique_for_date error
message
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/22887#comment:6>
Comment (by Claude Paroz <claude@…>):
In [changeset:"bc3d401b9f95ebc5bd25488708b5a82074c53ebb"]:
{{{
#!CommitTicketReference repository=""
revision="bc3d401b9f95ebc5bd25488708b5a82074c53ebb"
[1.7.x] Fixed #22887 -- Added comment for translators on unique_for_date
error message
Backport of 6eed751162 from master.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/22887#comment:7>
Comment (by Tuttle):
Replying to [comment:2 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22887#comment:8>
Comment (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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22887#comment:9>
Comment (by Tuttle):
Replying to [comment:9 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22887#comment:10>
Comment (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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22887#comment:11>
* status: closed => new
* resolution: fixed =>
Comment:
I hope you don't mind if I reopen so it can be reconsidered. Thanks.
--
Ticket URL: <https://code.djangoproject.com/ticket/22887#comment:12>
* needs_docs: 0 => 1
* has_patch: 0 => 1
* type: Bug => Cleanup/optimization
* easy: 1 => 0
* stage: Accepted => Unreviewed
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22887#comment:13>
* stage: Unreviewed => Accepted
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22887#comment:14>
* owner: Federico Frenguelli => (none)
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/22887#comment:15>
* status: assigned => new
--
Ticket URL: <https://code.djangoproject.com/ticket/22887#comment:16>