Opened 18 years ago

Last modified 8 weeks ago

#1688 new defect

Permissions don't get translated in admin interface

Reported by: Rudolph Froger Owned by: hugo
Component: Internationalization Version: 1.2
Severity: normal Keywords:
Cc: thepapermen Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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

Attachments (1)

11beta1.diff (1.1 KB ) - added by Henrique C. Alves 15 years ago.

Download all attachments as: .zip

Change History (16)

comment:1 by Adrian Holovaty, 18 years ago

Resolution: wontfix
Status: newclosed

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

comment:2 by Adrian Holovaty, 17 years ago

milestone: Version 0.92

Milestone Version 0.92 deleted

by Henrique C. Alves, 15 years ago

Attachment: 11beta1.diff added

comment:3 by Henrique C. Alves, 15 years ago

Has patch: set
Resolution: wontfix
Status: closedreopened
Summary: Permissions don't get translated in admin interfacePermissions don't get translated on syncdb
Version: magic-removal1.1-beta-1

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).

comment:4 by Alex Gaynor, 15 years ago

Resolution: wontfix
Status: reopenedclosed

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.

in reply to:  4 comment:5 by Henrique C. Alves, 15 years ago

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.

comment:6 by Henrique C. Alves, 15 years ago

Summary: Permissions don't get translated on syncdbPermissions don't get translated in admin interface

comment:7 by Artem Skoretskiy, 13 years ago

Version: 1.1-beta-11.2

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.

comment:8 by thepapermen, 12 years ago

Cc: thepapermen added
Easy pickings: unset
UI/UX: unset

comment:9 by Thibaud Colas, 10 months ago

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.

Last edited 10 months ago by Thibaud Colas (previous) (diff)

comment:10 by Claude Paroz, 10 months ago

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

comment:11 by Thibaud Colas, 10 months ago

🙌 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!

comment:12 by David Smith, 9 months ago

Has patch: unset
Resolution: wontfix
Status: closednew
Triage Stage: UnreviewedAccepted

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

comment:13 by Thibaud Colas, 5 months ago

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.

in reply to:  13 comment:14 by Natalia Bidart, 5 months ago

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!

comment:15 by Sebastian Rode, 8 weeks ago

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.

Note: See TracTickets for help on using tickets.
Back to Top