#11688: verbose_name should allow dynamical translation based on a number
--------------------------------------+------------------------------------
Reporter: mitar | Owner: nobody
Type: New feature | Status: reopened
Component: Internationalization | Version: 1.1
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Comment (by sirex):
Replying to [comment:9 lukeplant]:
> I'm sure there are many other things of which I'm unaware. Essentially,
any attempt to build up sentences by substituting words into a template is
going to fail. This is a hard problem.
Using model class name, in human readable context is already a fail. And
yes, fixing it is a hard problem. For English language it is already
fixed, by adding 's' or using 'verbose_name_plural' for exceptional cases.
But current implementation does not work of most languages. What I'm
trying to do is to make it more flexible and extendible to support most
Indo-European languages and probably most other languages. I'm sure, that
this approach will not cover all possible cases, but at least it will
cover much much more languages, than we have now.
If you think, that having model class name in human readable context is
fail, then we should drop this feature at all, to make it work for all
languages. If you thing, that we should leave this feature, then why you
refuse to fix all those English-only related places?
> The questions we can ask are:
>
> * how many and how bad are the current failures?
Current Django admin implementation is heavily hardcoded for English only
language. My company can't offer Django admin for any client, because out
of the box, many places uses incorrect word forms. It sounds some thing
like this: "10 book", that should be "10 books", actually things are much
worse, because for example Lithuanian language has 15 noun forms and
Django uses only 2 of them, so most places are incorrect. Unless you
think, that saying "10 book" is OK?
I tried to do workarounds with translation files by doing some thing like:
"New: '{{ name }}'", but it sound unnatural and many places are hardcoded
in Django admin templates, so even these workarounds are not possible, for
example in such places like this:
{{{
{{ cl.result_count }} {% ifequal cl.result_count 1 %}{{
cl.opts.verbose_name }}{% else %}{{ cl.opts.verbose_name_plural }}{%
endifequal %}
}}}
So if we want to go this way, we should replace all places in Django admin
to neutral forms, such like these: "New: {{ name }}", or "Number of {{
name }} items: {{ count }}". But of course this will sound unnatural. Much
better "Add {{ name }}" and "{{ count }} {{ name }}".
> * what fraction would be fixed by adding a certain mechanism (e.g.
ability to distinguish case)?
At least for Lithuanian language, separating singular/plural forms,
replacing all number contexts with ungettext and adding ability to
distinguish grammatical case would solve all places, all texts would sound
natural and would be correct. I believe, same approach will work form most
other Indo-European languages, that has nouns with several grammatical
cases.
> * how much will the mechanism require to implement, for Django core
developers, for template authors and for translators?
Proposed mechanism is fully backward compatible, since it replace
verbose_name to string-like object with additional features. And for this,
to take effect, all places, where verbose_name is used, must be adjusted,
to correct contextual form, for example: "Add {{
model.verbose_name.accusative }}". If verbose_name will be left as is,
then nothing changes. Template authors will have ability to use correct
model verbose name form if they want.
Translators of languages with several grammatical cases will have more
strings to translate, but for languages like English with two noun forms,
nothing changes.
> * is the mechanism extendable to deal with things we haven't thought of
yet?
Currently, mechanism provides full flexibility for single model verbose
name text. If a language needs more context, to decide correct noun form,
this context can be added easily.
What I can think of is that this mechanism will not work for such cases,
where not only model name has forms, but surrounding text also some how
depends on model verbose name case (I'm not sure if any language has
this).
> I'm inclined to think that mechanisms that depend on specific language
features (e.g. agreement, case etc) are the wrong approach, and a more
generic 'context' should be added that allows specific translations for
specific sentences.
Agreement is for verbs, verbs are very complicated, at least in Lithuanian
language, usually, one verb in Lithuanian language has more than 200
forms. But model names are nouns, because all names of some thing are
nouns.
Now Django already uses language specific features, like singular/plural
forms. But currently it lacks number forms and grammatical cases, that are
very common in other languages. So if Django already have language
specific features, then we should make them more complete.
--
Ticket URL: <https://code.djangoproject.com/ticket/11688#comment:11>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
