Opened 19 years ago
Last modified 10 months 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)
Change History (16)
comment:1 by , 19 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
by , 15 years ago
Attachment: | 11beta1.diff added |
---|
comment:3 by , 15 years ago
Has patch: | set |
---|---|
Resolution: | wontfix |
Status: | closed → reopened |
Summary: | Permissions don't get translated in admin interface → Permissions don't get translated on syncdb |
Version: | magic-removal → 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).
follow-up: 5 comment:4 by , 15 years ago
Resolution: | → wontfix |
---|---|
Status: | reopened → 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 by , 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 , 15 years ago
Summary: | Permissions don't get translated on syncdb → Permissions don't get translated in admin interface |
---|
comment:7 by , 14 years ago
Version: | 1.1-beta-1 → 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 by , 13 years ago
Cc: | added |
---|---|
Easy pickings: | unset |
UI/UX: | unset |
comment:9 by , 17 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.
comment:11 by , 17 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 , 17 months ago
Has patch: | unset |
---|---|
Resolution: | wontfix |
Status: | closed → new |
Triage Stage: | Unreviewed → Accepted |
Re-opening following discussion both here and on the forum thread.
follow-up: 14 comment:13 by , 13 months ago
comment:14 by , 13 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 , 10 months 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.
The permissions are stored in the database and don't get translated.