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 (15)

comment:1 Changed 18 years ago by Adrian Holovaty

Resolution: wontfix
Status: newclosed

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

comment:2 Changed 17 years ago by Adrian Holovaty

milestone: Version 0.92

Milestone Version 0.92 deleted

Changed 15 years ago by Henrique C. Alves

Attachment: 11beta1.diff added

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

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 Changed 15 years ago by Alex Gaynor

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.

comment:5 in reply to:  4 Changed 15 years ago by 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.

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

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

comment:7 Changed 13 years ago by Artem Skoretskiy

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 Changed 12 years ago by thepapermen

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

comment:9 Changed 6 months ago by 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.

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

comment:10 Changed 6 months ago by Claude Paroz

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

comment:11 Changed 6 months ago by 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!

comment:12 Changed 6 months ago by David Smith

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

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

comment:13 Changed 2 months ago by 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.

comment:14 in reply to:  13 Changed 8 weeks ago by 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!

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