Re: Proposal: Django Admin Site and "pretty" app name

[Sergiy Kuzmenko]

As an alternative to creating AppConfig class, what about registering app names, just like we register ModelAdmin instances:

admin.site.register_app_label("myapp", _("My awesome web app"))

- Sergiy

On Thu, Dec 6, 2012 at 11:57 PM, Pedro J. Aramburu <para...@tres42.com.ar> wrote:

As I explained on the Django users forums (https://groups.google.com/forum/?fromgroups=#!topic/django-users/ZUxZHi_-5ug) I'm spanish speaking so my users are too. Writing code in spanish isn't pretty and with characters like "á" or "ñ" it's very difficult to name the apps a way that would make sense to show on the Admin site.

That being said, I would like to propose a solution because all the tickets and solutions I found won't work properly or are very outdated but I need consent and guidance on how to approach it and with the internals of django.contrib.admin and django.db.

My solution consists on a class on the __init__.py file on the module (app), maybe it can be call AppConfig, where some metadata about the app can be stored. Then, django.contrib.admin could pick it up to name the app and maybe add a description or help_text and if it's not there it could fall back to the previous method with app_label.

As an example:

__init__.py

class AppConfig:

    verbose_name = 'app pretty name in any'

    description = 'app short description'

I chose verbose_name to keep it consistent with fields and models but it could be called however you want (even pretty_name). Maybe on the future AppConfig could be used for other purposes but it has to start somewhere. This way you could also use ugettext_lazy to translate the name and description.

django.db.models won't need to be touched because they don't need the "pretty name" but django.contrib.admin could try to pick up the AppConfig to get the pretty name.

https://github.com/django/django/blob/1.4.2/django/contrib/admin/sites.py#L365

https://github.com/django/django/blob/1.4.2/django/contrib/admin/sites.py#L421

There it could return the verbose_name.title() or fall back to the app_label.title() so then in the template there will be no need to change anything (if we don't implement any other functionality yet).

What do you think? Please let me know if it's the best approach and if it would be considered to merge it on the project. Mostly because non-english speakers need some default solution to make the django admin work for their sites but keeping the code in english.

Thank you in advance for your thoughts on this.

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/hwUExTid2UEJ.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

[Marijonas Petrauskas]

This is important not only for internationalization, but also for English app names, consisting of several words. Neither Siteconfig nor Site_config look pretty.

I think that app name should not be defined as a static variable in __init__.py file for this reason: if we want to translate the label, we write _('Site config'), which depends on django.utils.translation, and translation depends on settings. So, this means that whenever we import any submodule/subpackage of the app, we also import much of Django machinery.

One alternative (and probably the best one) as suggested by Sergiy is to put it in admin.py file. Another is to define a function get_app_name() in __init__.py file.

[Aymeric Augustin]

FYI the latest efforts on this topic are here:

https://github.com/ptone/django/compare/app-loading

http://code.djangoproject.com/ticket/3591

--
Aymeric.

[Pedro J. Aramburu]

I read the tickets. Many are outdated and the approach in the trac ticket below I believe it's not very well defined. About putting app names on the INSTALLED_APPS, I don't think it would be good for packaging. That's why I believe it should be somewhere on the app itself. About using admin.py for registering the app, I think it would only scope the information to the admin site.

What I want to accomplish is some way to store app metadata for the use where it's needed and be able to translate it to multiple languages. Maybe on the future it exist a template tag so it could be used on the frontend as well without passing it through every view. Maybe we should create another module called "app.py" instead of using the "__init__.py" file.

On the other hand I believe we shouldn't modify yet the way the apps are loaded. Mainly because now there is an AppCache but it's tightly coupled in the db package (https://github.com/django/django/blob/master/django/db/models/loading.py) and I don't think it's being used above that scope. It would be a hassle. I think we need a starting point, that's why a simple class with the information, that could be instantiated when needed, should be the best approach. Maybe later we could extend the app registry idea by extending the same class, decoupling the AppCache from the db module and rewriting the way models are loaded into the new app registry. That way for example in the case of the models in subpackages, we could load them from the app config class instead of using the app_label approach.

I will put a link to this discussion in the trac ticket seeking for more opinions.

[Ramiro Morales]

Exactly,

The issue described in this thread is already reported as ticket [1]10436.
The fix for it depends on 3591[2] wich should introduce first class app
entities that could carry this and other meta-data.

Please read the story of the former ticket for more details.

--
Ramiro Morales


1. https://code.djangoproject.com/ticket/10436
2. https://code.djangoproject.com/ticket/3591

[Pedro J. Aramburu]

Ramiro, I've read the ticket but it seems stuck. I just want it to go forward because I think it's a major UI/UX issue for non-programmers the lack of "pretty" app names. But I want it to be done right with a proper app metadata handling.

The thing is that there isn't any consensus about the way to go so I'm terrified of starting with my ideas without anyone accepting them and also because I don't know if anyone is already working on them (as the tickets are open) but there seems to be no constant activity on them. That's why I need some guidance from someone experienced with the process.

[Russell Keith-Magee]

On Sat, Dec 8, 2012 at 9:29 AM, Pedro J. Aramburu <para...@tres42.com.ar> wrote:

Ramiro, I've read the ticket but it seems stuck. I just want it to go forward because I think it's a major UI/UX issue for non-programmers the lack of "pretty" app names. But I want it to be done right with a proper app metadata handling.

You won't get any argument from me, or anyone else in the core team. This *is* an important issue. The problem is that the issue *isn't* entirely cosmetic. It's very easy to say that we "just" need to attach a configurable name to applications -- but in order to do this, you need to address the more fundamental issue of what an application *is*. In having that discussion, you hit a whole raft of *other* problems that are related to Django's definition of apps. That's why this patch has taken so long to come to fruition.

The thing is that there isn't any consensus about the way to go so I'm terrified of starting with my ideas without anyone accepting them and also because I don't know if anyone is already working on them (as the tickets are open) but there seems to be no constant activity on them. That's why I need some guidance from someone experienced with the process.

There's plenty of consensus about the broad strokes. The disagreement is about the little details. There's no constant activity because it's a big problem; that means we've gone through multiple maintainers over time, and the activity level rises and falls as attention is drawn onto other priorities (such as bug fixing for the 1.5 release).

I last looked at Preston's Github branch during the DjangoCon US sprints, and at that time, it was extremely close to being ready for merging -- it mostly just needed eyeballs, testing, and documentation. If you want to help out, I'd suggest grabbing that code, and trying to (a) get it up to date, and (b) testing it with your own projects, and © helping to stub out documentation.

I'd very much like to see this patch land as part of the 1.6 cycle -- App name translations aren't a big issue for me personally, but all the other related features -- such as having a reliable startup sequence, a place for application-level configuration, and a place for one-time initialisation -- *are* an issue for me, and fixing these problems are all side effects of adding an application configuration object.

Yours,

Russ Magee %-)

[Pedro J. Aramburu]

Which one is the branch? I can't seem to find it.

[Russell Keith-Magee]

It's Preston Holme's app-loading branch - the Github branch Ramiro referenced earlier in this thread.

https://github.com/ptone/django/tree/app-loading

Yours,

Russ Magee %-)

--

You received this message because you are subscribed to the Google Groups "Django developers" group.

To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/KqGTJ8TPPgcJ.

[ptone]

Just to add a quick update here.

Not much has happened on the branch since Djangocon - but we had some valuable discussions. I'm hoping to get some time over the holidays to get this back up to a more current form.

Russ and Karen gave some great feedback, and there is some straightforward but somewhat tedious cleanup - mostly involving backing out the metaclass pattern for app objects.

The crux will be a way to introduce this in form that provides some limited, targeted benefits such as the verbose app name, without opening too much of a pandora's box of enabling a range of unintended "features" centered on abuse  of the app-cache.

As Russ said - this has always had the potential to be a ginormous bike-shed, and if any Django specific interfaces on a application class that go beyond "its just a Python class" are to be introduced, they have to be done so with due consideration.

-Preston