[GSoC 2014 proposal]. Improving admin translation and formalizing Meta objects.

[Алексей Сидаш]

Hello there!

My name is Alexey and I would like to do some work for django project. I'm from Russia, and English is not my native language(my native one is Russian). Russian localization of django admin is poor. It is even worse then my English :D. Of course, I do not like it, I believe that Meta property of Admin-related objects (like ModelAdmins and Inlines, for example) are suitable for storing all the custom letters(Such as "Add new %modelname%") from admin-forms. To get it done, we need formalizing meta objects and adding custom fields for labels in admin forms. then, we only need to make some template changes.This will make admin panel more customizable and translatable. 

Also, I think we may add custom admin widgets for every application, for example, we define a Meta class in application __init__.py, where we make add property widget_template, and add there something custom instead of default links.

Good luck, thanks for your time. 

P.S. I have got some open-source experience connected with django, see https://github.com/iLikeKoffee/tiny_feedback . It is not ready enough for usage, but you can see my code. I want to make possible adding feedback functionality by couple of shell commands and config variables.

[Florian Apolloner]

Hi Alexey,

On Wednesday, March 12, 2014 7:52:59 PM UTC+1, Алексей Сидаш wrote:

Russian localization of django admin is poor. It is even worse then my English :D.

How so? Can you provide a few examples -- I know that numbering can be a problem for Russian translations, but that's hardly a problem of the admin itself.

Of course, I do not like it, I believe that Meta property of Admin-related objects (like ModelAdmins and Inlines, for example) are suitable for storing all the custom letters(Such as "Add new %modelname%") from admin-forms.

I don't think abusing Meta for that would be a good idea, gettext fits that purpose (relatively) fine -- again, we'd need concrete examples.
 

Also, I think we may add custom admin widgets for every application, for example, we define a Meta class in application __init__.py, where we make add property widget_template, and add there something custom instead of default links. 

I don't see any benefit in this, you'll need to explain this in more detail.

Best regards,
Florian

P.S.: If you intend this to be your actual proposal, you'll have to flesh it out a bit like for instance https://groups.google.com/d/msg/django-developers/e0-rOIkrXaQ/w5aiW_R6aFYJ -- You also might want to checkout https://code.djangoproject.com/wiki/SummerOfCode2014

[Алексей Сидаш]

How so? Can you provide a few examples -- I know that numbering can be a problem for Russian translations, but that's hardly a problem of the admin itself.

 

There are three grammatical genders in Russian, and all the words in sentense should match gender of subject. You seem to be right about abusing meta with this work, gettext functionality may be enough, gettext `context` feature may help. See this question. We need to make some changes in templates, admin tempates to add apropriate context for needed letters.

For example, we have two models. Article and Post. 

In English we say "Add new Article" and "Add new Post", right?

But in Russian article's grammatical gender is "female", but post's grammatical gender is "male", so we should say "Добавить новую Статью" for "Add new Article" and "Добавить новый Пост" for "Add new Post".

The suffix (bold) depends on noun's(Model name in this case) grammatical gender.

I believe, this problem takes place not only in Russian, but, unfortunately, I speak only Russian and English.

One of the solutions is providing gettext_context field in model's Meta(or in more suitable place) and select aproppriate translation, depending on this property using contextual markers.

 

Also, I think we may add custom admin widgets for every application, for example, we define a Meta class in application __init__.py, where we make add property widget_template, and add there something custom instead of default links. 

I don't see any benefit in this, you'll need to explain this in more detail.

Do you see red line? Here, instad of simple link, some custom information may be shown. For example, "N new users registered in last 24 hours" and staff like that.

Also, notifications in main page of admin panel may be useful, for example: Blog application, where admins can publish posts and users can comment them. When post, published by me is commented, Blog application pushes new notification, and I can see an active button in admin(Something like github notifications).

Thank you for your answer,

Best regards, 

Alexey 

[Baptiste Mispelon]

Hi,

Regarding the translation issues, there's a lengthy discussion on https://code.djangoproject.com/ticket/11688 which you might find interesting.

--
Baptiste

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/de489d7d-dd72-42fc-9497-785771ad23a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrew Pashkin]

The problem is actually exists, I also want to find a way, how to rid my cleints of that crazy wording in admin-site.
I've found promising package - pymorphy2 (https://github.com/kmike/pymorphy2), it can find grammatical information for words and translate words to needed forms. So all what is needed to solve this problem - is some way, in Django, that would allow to inject pymorphy in admi, and Django actually has it - for now I think it would be enough to override templates of admin and use pymorphy within them.

[Adam Mesha]

2014-03-13 11:00 GMT+02:00 Алексей Сидаш <alexey...@gmail.com>:

For example, we have two models. Article and Post. 

In English we say "Add new Article" and "Add new Post", right?

But in Russian article's grammatical gender is "female", but post's grammatical gender is "male", so we should say "Добавить новую Статью" for "Add new Article" and "Добавить новый Пост" for "Add new Post".

The problem is a lot more complicated in that, because in addition to gender agreement, in Russian and a lot of languages you need to use the accusative and not the nominative in sentences like this ("post" happens to have the same form here but "article" changes from статья to статью).  Moreover, whatever the set of forms you decide to allow to be defined in the admin, there will always a language which needs another form.  And one language may need one form in a given sentence while another language needs a different form in that sentence (say a genitive versus a dative), so you need to allow the translator to say which form is going to be used in the sentence, not the programmer.  So it's quite a complicated problem if you really want to allow high quality translations.

--
Adam Mesha <adam....@gmail.com>
Life is either a daring adventure, or nothing. - Helen Keller

[Алексей Сидаш]

Hello

Yes, Adam Mesha seems to be right. The problem of translation is very complicated.

I see only one solution, all the text in admin panel should not be generated dynamically.

I mean, that code like "Add new {{ model.verbose_name }}" makes translation to languages like Russian very difficult, because of grammatical matching between words in sentenses.(For example, subject(noun) and predicate(verb) in Russian must have the same grammatical gender and etc). That's why, words should not be translated in isolation, sentenses must be "atomical" unit of translation.

No doubdt, we need some consultation from other language speakers, unfortunately, I speak only Russian and English, but I strongly believe that "atomicity" of sentenses is the most suitable solution for this case. It is not too much complicated as pymorphy, but good enough to solve existing problems. 

Rough "plan" is:

1. Put all the letters from admin panel into *.po files as message ids.
2. Including dynamically generated, because every single one should have own translation.
   
3. Second item means, that this files should be generated with shell command(for example).
4. If there are no translations yet, framework should fallback to current solution, or to English(Fallback should be discussed).

For example, in application directory django-admin.py translate-admin command creates folder named admin-translations with structure like this:

admin-translations/

|____ModelOneLetters.po

|____ModelTwoLetters.po

|____...

And example of ModelOneLetters.po file is:

#: Add new item to database letter.

msgid "Add new ModelOne item"

msgstr "Добавить первую модель"

#: Edit item letter.

msgid "Edit ModelOne"

msgstr "Редактировать первую модель"

...

P.S. Feel free to criticize it, especially, if your native language has translation problems. I believe that this problem's solution cannot be found without consultation with different language speakers. 

[Adam Mesha]

MediaWiki has a well evolved and mature translation system that deals with a very large range of languages, and I think it would be worthwhile to check out how they do it there in detail.  I believe that there is a better solution than requiring that all strings be retranslated for every new app that you create, it's just not as trivial as the naive solution that Django currently uses.

--

You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/c75be3e4-0280-4ead-9204-76d632c33503%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Алексей Сидаш]

Hello, 

I believe that there is a better solution than requiring that all strings be retranslated for every new app that you create, it's just not as trivial as the naive solution that Django currently uses.

 Yes, retranslatiog all the strings every time does not seem to be a good idea.

As far, as I know, current solution is good enough for English language, all the english strings are grammatically correct and I strongly believe that there are languages, whoose translation is good enough now. These languages translation need no changes, don't them?

That's why *.po files in  admin-translations/ folder should have pre-generated translation.

This directory may have structure like this":

admin-translations/

|____en/

        |____default.po # English is OK now, no need to do any changes

|____ru/

        |____default.po # Fallback for models with no-translations

        |____ModelOne.po # translation for first model, by default generated in the same way as now.

Thanks for your time,

Best regards,

Alexey

[Алексей Сидаш]

P.S.

Ooops, looks like I forgot about this:

MediaWiki has a well evolved and mature translation system that deals with a very large range of languages, and I think it would be worthwhile to check out how they do it there in detail. 

Great thanks, I will check it out. 

[Andrew Pashkin]

Proof of concept for pymorphy solution:
https://gist.github.com/StillNewb/9703843

[gsa...@gmail.com]

+1 from pt-br

-mensag. original-
Assunto: Re: [GSoC 2014 proposal]. Improving admin translation and formalizing Meta objects.
De: Andrew Pashkin <andrew....@gmx.co.uk>
Data: 22-03-2014 06:44

Proof of concept for pymorphy solution:
https://gist.github.com/StillNewb/9703843

On Saturday, March 15, 2014 9:20:24 PM UTC+4, Алексей Сидаш wrote:
>
> Hello
>
> Yes, Adam Mesha seems to be right. The problem of translation is very
> complicated.
> I see only one solution, all the text in admin panel should not be
> generated dynamically.

> I mean, that code like *"Add new {{ model.verbose_name }}"* makes

> translation to languages like Russian very difficult, because of
> grammatical matching between words in sentenses.(For example, subject(noun)
> and predicate(verb) in Russian must have the same grammatical gender and
> etc). That's why, words should not be translated in isolation, sentenses
> must be "atomical" unit of translation.
> No doubdt, we need some consultation from other language speakers,
> unfortunately, I speak only Russian and English, but I strongly believe
> that "atomicity" of sentenses is the most suitable solution for this case.
> It is not too much complicated as pymorphy, but good enough to solve
> existing problems.
> Rough "plan" is:
>

> 1. Put all the letters from admin panel into *.po files as message ids.
> 2. Including dynamically generated, because every single one should
> have own translation.
> 3. Second item means, that this files should be generated with shell
> command(for example).
> 4. If there are no translations yet, framework should fallback to

> current solution, or to English(Fallback should be discussed).
>

> For example, in application directory *django-admin.py translate-admin *command

> creates folder named admin-translations with structure like this:
>
> admin-translations/
> |____ModelOneLetters.po
> |____ModelTwoLetters.po
> |____...
>
> And example of ModelOneLetters.po file is:
>
> #: Add new item to database letter.
> msgid "Add new ModelOne item"
> msgstr "Добавить первую модель"
>
> #: Edit item letter.
>
> msgid "Edit ModelOne"
>
> msgstr "Редактировать первую модель"
>
> ...
>
> P.S. Feel free to criticize it, especially, if your native language has
> translation problems. I believe that this problem's solution cannot be
> found without consultation with different language speakers.
>

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9f82a32d-80ba-4e46-b750-e20fe11f3043%40googlegroups.com.