Posted by valokettu on October 18, 2008 at 1:00pm
9 followers
Jump to:
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | language system |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
| Issue tags: | D8MI, language-base, negotiation, Usability |
Issue Summary
My site's default language is Finnish but I need to use English for admin pages. There should be next to Default language option the second one where user could choose the admin language. I tried also to change language from my user account but it didn't make any change (bug?).
Comments
#1
Old Issue, but it's a good question - admin in different language? Available, or move to D8?
#2
Solution in contrib:
http://drupal.org/project/admin_language
Feature request for D8?
#3
Should this live in contrib? If so please set to closed(fixed).
#4
You can certainly set your user preferred language to whatever language you want and browse the site in that language. That sounds like the easiest, no extra module required :)
#5
Marked #263887: Ability to set language of administrative backend as a duplicate.
#6
In D7 it is possible to move the user language detection method on top and having it prevale over URL language. This allows an admin user to set her preferred interface language. I ain't sure we need something more advanced in D8.
#7
Looks like http://drupal.org/project/admin_language sets one global admin language for the whole site. Is that generally accurate? Thinking about this, it sounds like this would be per-user, so that a multilingual site can be managed by people in their own language. I assume the problems solved here include that the language changes when you hit a node that you want to translate for example, from where admin links would get to keep that modified language, that is not desired. I agree it is probably easy to implement per site instead of per user though, given that if we implement per user, it becomes a problem to display the admin language selector to some people on their profile but not to others. It is hard to tell generally if someone has "some kind of admin access" or not.
Maybe we should think of this as a second session language provider that only applies to admin pages (with a block specific for that to let admins set it?). Blocks don't work well with the Seven theme though... Well, just thinking out loud here :)
#8
My current personal recipe for the scenario described in #7 is:
If I wish to have the possibiliy to switch even interface language:
My main doubt is: do we need some usability improvement to make clear that all of this is actually possibile?
Another possibility might introducing a Role language provider that would allow to configure a language for each available role. But all of this looks to me fairly complex to setup for the average user.
#9
Marked #744656: No translations for admin interface and #289114: Set different presentation language for Admin only as duplicates. There is clearly *lots* of interest in this.
#10
Fascinatingly also closed down #427782: All English has gone RTL? as duplicate. Huh.
#11
#12
@plach: I think your suggestions from #8 are not entirely good in that they have front-end consequences, when the requestors only want their admin language changed, not to have users fiddle with language changes persisting in their sessions.
#13
Subscribing.
It should also be possible to hide the admin language from "Language settings" on the user edit account form if the admin language is not one of the "public" languages. And if the site is a single language site where the admin language is different from the default language, it should be possible to hide "Language Settings".
#14
A new 7.x-1.x-dev version of Administration Language has just been released fixing some of what I mentioned in #13.
And it has this feature request: #1239204: Use preferred language on per-user basis instead of global setting
#15
Retitling to better explain the feature request. I've pinged @wulff (the admin_language module maintainer) if he would be interested in integrating some of the module functionality in core. Looking at the code, it seems to be doing numerous other things, like optionally forcing language neutral nodes and path aliases which definitely sound unrelated.
#16
BTW I think the spec for this feature at its most basic form is a language provider that only kicks in for hook_admin_paths() paths, and provides a concrete language. Then this can be enabled on the UI like any other provider. A bonus for it providing a per-user configuration option as well for admin language. Where it gets tricky is that it would change the content language as well with our current default fallback method in core, so we'd need to expose those settings somehow to let people disconnect content from interface, which is the primary goal of this feature anyway.
#17
As I was writing in #1036212: Use hook_language_types_info() instead of hook_init() in D7, I think the admin language provider is the way to go too: it could set the default admin language using the user setting and falling back to the default admin language.
The provider should be defined to be assignable only to the UI language. To actually take advantage of this we should make content language negotiation enabled by default in D8: node translation, if present, could exploit it through the
tnode/1feature we were speaking about in the last months.#18
tagging
#19
@plach: it does sound like a usability problem if we need to expose both interface and content language config separately in D8, that does not sound like good news. However, I see that trying to not inherit to content language if it was picked by the admin language one would be a bad case of special casing that we should not pursue. Hm.
#20
The issue for me is that I am below survival level for both Spanish and Chinese for a trilingual website (with English as the main language and selected content translated). It is also possible we would be adding additional languages for which I know nothing. I may need to post content simply by somebody providing me a Word doc with the translation, and I just copy and paste. I want all interface content to be in English, but the content page would be marked as Spanish or Chinese and show up in Spanish or Chinese.
An anonymous viewer of the Spanish or Chinese page would see everything on the page entirely in that language except, of course, for the other-languages entries in the language-switcher block.
However a logged-in staff content-administering viewer would want to see Drupal interface links such as "Log out," "Edit," "Add new content" and the administrator menu in the logged-in viewer's preferred administration language, not in the content language.
#21
This should be already possible in D7 core: just enable the User language detection method on top of the URL one.
#22
Tagging for base language system.
#23
Tagging for language negotiation too.
#24
Actually, the other languages have just hit and it's likely to affect many U.S. local government transportation websites due to action by the Federal Transportation Administration. As part of U.S. Title VI of the Civil Rights act, the San Francisco Municipal Transportation Agency website is now going to have at least a few pages each in Arabic, French, Japanese, Korean, Italian, Russian, Thai, Vietnamese and possibly Tagalog. I have to be able to copy and paste content in those languages, as well as verify they can be viewed by an anonymous visitor, but manage that content using an English-language interface.