Code

Opened 8 years ago

Closed 5 years ago

Last modified 2 years ago

#1688 closed defect (wontfix)

Permissions don't get translated in admin interface

Reported by: Rudolph Owned by: hugo
Component: Internationalization Version: 1.2
Severity: normal Keywords:
Cc: thepapermen Triage Stage: Unreviewed
Has patch: yes 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 hcarvalhoalves 5 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 Changed 8 years ago by adrian

  • Resolution set to wontfix
  • Status changed from new to closed

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

comment:2 Changed 7 years ago by adrian

  • milestone Version 0.92 deleted

Milestone Version 0.92 deleted

Changed 5 years ago by hcarvalhoalves

comment:3 Changed 5 years ago by hcarvalhoalves

  • Has patch set
  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Summary changed from Permissions don't get translated in admin interface to Permissions don't get translated on syncdb
  • Version changed from magic-removal to 1.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 follow-up: Changed 5 years ago by Alex

  • Resolution set to wontfix
  • Status changed from reopened to closed

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 5 years ago by hcarvalhoalves

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 5 years ago by hcarvalhoalves

  • Summary changed from Permissions don't get translated on syncdb to Permissions don't get translated in admin interface

comment:7 Changed 3 years ago by tonnzor

  • Version changed from 1.1-beta-1 to 1.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 2 years ago by thepapermen

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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.