#13861 closed (duplicate)
Translate permissions
Reported by: | Artem Skoretskiy | Owned by: | nobody |
---|---|---|---|
Component: | contrib.auth | Version: | dev |
Severity: | Keywords: | ||
Cc: | tonn81@… | Triage Stage: | Unreviewed |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
When permissions are generated by /manage.py syncdb
they must respect defined language (settings.LANGUAGE_CODE
) so permissions become translated.
That makes sense for non-English users that should take advantage of the language they selected.
In admin I should see translated permissions, for example for Russian (need better translation for that):
"admin | entry | Can add log entry" instead of "admin | log entry | Может добавлять объекты log"
Entries names should be translated too (we have Model.verbose_name
for that).
If user want to generate permissions in English - he should change his settings.LANGUAGE_CODE
to en
, create tables and revert language back.
Change History (8)
comment:1 by , 14 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
comment:2 by , 14 years ago
Please, look at the table auth_persissions - it has following structure (and data - trimmed):
Here's a small piece of data:
+-----+-----------------------------------------------+-----------------+----------------------------------------+ | id | name | content_type_id | codename | +-----+-----------------------------------------------+-----------------+----------------------------------------+ | 1 | Can add permission | 1 | add_permission | | 2 | Can change permission | 1 | change_permission | | 3 | Can delete permission | 1 | delete_permission |
As you see - codename is in English and may be - and it is done - easily parsed - that should stay English for sure.
"name" is human-readable name that is not used for parsing and SHOULD be translated into the user language.
The question is where it should be made - in runtime, syncdb or permissions generation.
comment:3 by , 14 years ago
Resolution: | duplicate |
---|---|
Status: | closed → reopened |
#1688 was closed without any relevant answer regarding to the issue itself (not the form it was expressed). Please, look here once more.
comment:4 by , 14 years ago
started discussion on django-dev mailist (assuming ther would be no answer as usually)
comment:5 by , 14 years ago
Resolution: | → duplicate |
---|---|
Status: | reopened → closed |
The answer provided on #1688 *is* relevant -- database content isn't translated. Ever. If you look at the list of other duplicate tickets provided by ramiro, you will see that #6460 isn't closed -- that is a ticket addressing the general problem of multilingual content in databases.
By the by -- passive aggressive comments like "no answer as usually" are a grand example of how to *not* get the help you need. We're all volunteers. We do what we can, when we can spare the time, on the issues that we see as a priority. Your bugs are not the only bugs. If nobody on django-dev has answered your question, you might want to consider some possible reasons:
- Nobody understood your description of the problem, or the potential severity of it
- People understood your problem, but disagree about the severity of it
- People understood your problem, but can't spare the time *right now* to help you deal with it
- People understood the problem, and can spare the time, but decided to help someone else that wasn't engaging in a passive-agressive attack while asking for help.
comment:6 by , 14 years ago
Replying to russellm:
By the by -- passive aggressive comments like "no answer as usually" are a grand example of how to *not* get the help you need
Thanks for pointing that. Reading your post I realized that at the time of writing I was just disappointed in workflow of bugs accepting - dev discussion (decision) is needed, dev sometimes don't respond as issue is simply closed (not even marked as "to be done one day")
Please, look at the comment that resulted in closing #1688 - http://code.djangoproject.com/ticket/1688#comment:1
The permissions are stored in the database and don't get translated.
That's it! 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?
Another ticket you pointed to is #6460 that is much more generic issue and has not a word about permissions or auth module - that says about translating model fields into several languages. E.g. Article.text -> Article.text_ru + Article.text_en
Please have no doubt that I read and understood the tickets you pointed before making such statement as "answer is not relevant".
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 - as a volunteer - work on it.
comment:7 by , 14 years ago
And please understand that I have read the tickets too, and have acted the way I have for a reason. This ticket is an exact duplicate of the feature request made in #1688, as well as #11105 and #12396. Which is why it I closed this ticket as a duplicate.
If you disagree with a decision that has been made, then you need to make your case on django-developers. You aren't guaranteed to get a response, so if one attempt fails, try again after a while. Or try to get the attention of someone on IRC. Eventually, either someone will have the spare time to respond, or it will become clear from your inability to generate a response that your proposal isn't as important to everyone else as it is to you.
This process isn't perfect -- unfortunately, some requests do get ignored -- but it's what we've got, and it's served us reasonably well. If you have any better ideas for how to allocate resources when the list of requests for help and decisions *vastly* exceeds the available resources, we're open to suggestions.
Duplicate of #1688, #6460. See also #12396, #10616, #11105.