On Mon, Nov 28, 2011 at 9:45 PM, Sergiy Kuzmenko <s.kuzme...@gmail.com> wrote:
> My two cents:
>
> 1. Plural translation should output a fully translated phrase, e.g.:
> ungettext('%(count)d poll', '%(count)d polls, count) % {'count': count, }
> instead of noun alone, as in:
> ungettext_lazy('poll', 'polls', count)
>
I think we all agree with this, i.e having full phrases being marked up
for translation is better than composing phrases with translated
fragments.
Problem is that the replacement for `Meta.verbose_name` and
`Meta.verbose_name_plural` we finally come up with also needs to:
* Maintain backward compatibility
* Not change verbose names behavior when i18n isn't being used. IMHO
disrupting the workflow native English developers (especially
English-speaking Django core developers) use (and the results
they get) the least possible this is particularly important to
increase the chances of a proposed fix being finally committed.)
* Simply accept the fact that bare human readable model verbose
names are also needed and very useful in many contexts. I believe that
if for some UI work one needs the 'Poll' literal (or its translation)
and instead one gets '1 Poll' it would be surprising to say the
least, not matter what locale is in effect.
So, making the implementation to always execute something like
ungettext('%(count)d poll', '%(count)d polls, count) % {'count': count, }
isn't the right thing to do either. At least with this particular API.
By the way, there is a piece of code in the admin app that after the patch
looks like this (`changecount` is the int variable that contains the number of
model instances involved)::
name = force_unicode(model.get_verbose_name(changecount))
msg = ungettext("%(count)s %(name)s was changed successfully.",
"%(count)s %(name)s were changed successfully.",
changecount) % {'count': changecount,
'name': name}
self.message_user(request, msg)
Here, we aren't using full phrase translation but we still are setting
things up in way so a) Translators can reorder the words, they just need
to keep in mind that the 'name' var will contain the right verbose name
for the plural form in use and b) Final users are shown correct model
verbose names in all locales.
(Having said this, I have been doing some work to see how a fix for
[1]#14844 -- "Getting the ``blocktrans` template tag to select the right
plural model verbose name for every locale" would look like, based on
the work for this ticket and at the same time to validate the proposed
implementation. Will attach my WIP patch to that ticket and post a
follow-up email to this thread with some further findings and thoughts
because they are related to this kind of problems.)
> The advantage is that we provide translators with a complete translation
> string and thus there is no need to do stitching in the template with a
> specific word order in mind. Numeral + noun is not the universally
> acceptable word order [1].
>
> [1] http://wals.info/chapter/89
Wow that links is a very good resource, thanks for sharing it.
> 2. I'm not very clear why we need both verbose_names and get_verbose_name.
> If get_verbose_name is going to be the published interface we probably don't
> need additional class methods, do we?
This is also related to the three constraints I mentioned above.
In fact my initial plan (reflected in the first patch) was to make
get_verbose_name() effectively a published interface but for consumers
that need model verbose name literals.
We need it to always exist because we need that it always returns
something more or less sane (be it what the model developer implemented
with the non-mandatory verbose_names() method or one of the backward
compatibility fallbacks)
(Remember that the developer that creates a model has the freedom to
provide or not a verbose_names() method, and to make it return
values for any subset of the plural forms. This freedom is needed to
mirror the one the developer has when using Meta.verbose_name and
Meta.verbose_name_plural.)
But in further discussion with Jannis Leidel via IRC we decided to not
leave get_verbose_name() at the model level and make it a method of the
still non-public inner `_meta` Options instance (possibly postponing its
publication until `_meta` gets officially documented). So, code that
needs to consume model verbose names need to stop using
`<Model class>._name._verbose_name*` and call `<Model
class>._name.get_verbose_name()`
instead.
I've changed this in a [2]second version of the patch I've just attached
to the ticket.
Thanks for reviewing and commenting.
1. https://code.djangoproject.com/ticket/14844
2.
https://code.djangoproject.com/attachment/ticket/11688/11688-verbose_name_plural_evolution-2.diff
--
Ramiro Morales
--
You received this message because you are subscribed to the Google Groups
"Django internationalization and localization" group.
To post to this group, send email to django-i18n@googlegroups.com.
To unsubscribe from this group, send email to
django-i18n+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-i18n?hl=en.
