|Re: Proposal: Django Admin Site and "pretty" app name||Sergiy Kuzmenko||12/7/12 6:09 AM|
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"))
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.
|Re: Proposal: Django Admin Site and "pretty" app name||Marijonas Petrauskas||12/7/12 6:13 AM|
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.
|Re: Proposal: Django Admin Site and "pretty" app name||Aymeric Augustin||12/7/12 6:18 AM|
|Re: Proposal: Django Admin Site and "pretty" app name||Pedro Joaquín Aramburu||12/7/12 11:25 AM|
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.
|Re: Proposal: Django Admin Site and "pretty" app name||Ramiro Morales||12/7/12 6:27 AM|
The issue described in this thread is already reported as ticket 10436.
The fix for it depends on 3591 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.
|Re: Proposal: Django Admin Site and "pretty" app name||Pedro Joaquín Aramburu||12/7/12 5:29 PM|
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.
|Re: Proposal: Django Admin Site and "pretty" app name||Russell Keith-Magee||12/7/12 5:41 PM|
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.
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.
Russ Magee %-)
|Re: Proposal: Django Admin Site and "pretty" app name||Pedro Joaquín Aramburu||12/7/12 8:02 PM|
Which one is the branch? I can't seem to find it.
|Re: Proposal: Django Admin Site and "pretty" app name||Russell Keith-Magee||12/7/12 8:09 PM|
It's Preston Holme's app-loading branch - the Github branch Ramiro referenced earlier in this thread.
Russ Magee %-)
--To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/KqGTJ8TPPgcJ.
|Re: Proposal: Django Admin Site and "pretty" app name||ptone||12/10/12 12:14 PM|
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.