Permissions don't get translated in admin interface

[Rudolph Froger]

The permissions don't get translated/localized in the admin interface (in User and Group model).

[Adrian Holovaty]

The permissions are stored in the database and don't get translated.

[Adrian Holovaty]

Milestone Version 0.92 deleted

[Henrique C. Alves]

I don't see why this was set wontfix - storing in the database isn't a reason, as it could be inserted already localized. Django could do the right thing (TM) and use a localized version for the permission name.

The relevant code is at django/contrib/auth/management/init__.py:12

def _get_all_permissions(opts):
    "Returns (codename, name) for all permissions in the given opts."
    perms = []
    for action in ('add', 'change', 'delete'):
        perms.append((_get_permission_codename(action, opts), u'Can %s %s' % (action, opts.verbose_name_raw)))
    return perms + list(opts.permissions)

I tried a patch (see 11beta1.diff), and created translation strings for my locale (pt_BR), but looks like syncdb doesn't take translations into account, and inserts the original string on DB.

Looking for an insight on this, fixing this should be trivial, and would help a lot those using contrib.auth (today I need to edit all my permission's names by hand after syncdb, it sucks).

[Alex Gaynor]

Please don't reopen tickets closed by a core committer, if you disagree with the decision the right place to have this discussion is on the django-dev mailing list.

[Henrique C. Alves]

Replying to Alex:

Please don't reopen tickets closed by a core committer, if you disagree with the decision the right place to have this discussion is on the django-dev mailing list.

Sorry, I didn't knew that. I'm filling a new ticket instead.

[Artem Skoretskiy]

Unfortunately, all tickets that covers the functionality are closed because of being dupe of this ticket so I have to say here.

Please, look at the comment that resulted in closing this issue:

The permissions are stored in the database and don't get translated.

That says not it is implemented *now*. That covers the implementation point of view (implementation idea is not perfect), not the rationale of the issue (that is very useful for not-english).

There are a lot of ways to get needed functionality:

• We may get rid of auth_permissions.name column and generate translated names on fly using auth_permissions.codename value.
• We may store *translated* text in auth_permissions.name (I know that name is not translated *now*) Is there any reason not to store non-english text there?

If the rationale of this ticket makes sense (having translated permissions shown in admin) please keep this ticket open or point me to the ticket that has this rationale covered so I can work on it.

[Thibaud Colas]

In case anyone follows updates here, link to a recent discussion about this on the django-developers mailing list: ​https://groups.google.com/g/django-developers/c/Jv1GqGlp3ao.

I have shared a ​proof of concept fixing this without changing the fact that permission names are stored in the database, at least for default permission names. And for all permissions, as far as I can see there’s no reason to use the (untranslated) app name. Verbose app names are translate-able and can just be switched to.

[Claude Paroz]

+1 from me to reopen if we have a way foward.

[Thibaud Colas]

🙌 as suggested by @nessita on Discord, I’ve taken this to the Django Forum in Django Internals: ​https://forum.djangoproject.com/t/permissions-dont-get-translated-in-admin-interface/21324.

Let’s try to keep the discussion going over there!

[David Smith]

Re-opening following discussion both here and on the forum thread.

[Thibaud Colas]

I’m not 100% sure but I believe fixing this with the approach I suggested in ​my PoC would also fix #26756. And possibly help with #27489.

[Natalia Bidart]

Replying to Thibaud Colas:

I’m not 100% sure but I believe fixing this with the approach I suggested in ​my PoC would also fix #26756. And possibly help with #27489.

Would you have time to confirm whether that's the case? And, relatedly, I don't have clarity on whether the linked PoC is in a "reviewable" state or not. I wanna help, what would be the next useful step? Thank you!

[Sebastian Rode]

I looked into #26756 as part of a Django sprint, it seems like the underlying problem is the same. In both cases the verbose model_name is written as permission.name to the database when creating it. This is not updated when the verbose_name changes. The existing PR from a previous author uses the migration plan to update the permission name explicitly when any changes of verbose name happen. In my opinion the approach here of not hard-coding the verbose model name to the database, is good, but might have the potential of introducing breaking changes. I cannot really judge this. Would be good to get some input.

[Thibaud Colas]

Yes Sebastian that’s right!

As part of Djangonaut Space, team Neptune worked on the prototype together and we arrived at this new version: ​https://github.com/django/django/pull/18885. This extends the previous POC to demonstrate that this approach works even for custom permission names (at least as far as we can tell so far).

Assigning to @emmebravo to take this from quick POC to a fully-fledged PR with unit tests, docs changes and all.

---

As far as we could tell, though what’s described in #26756 would technically still apply, the changes as part of ticket #1688 would make #26756 any further changes redundant. And for #27489, I believe it wouldn’t fix that ticket / might help a bit but not much.