Add "Administration pages language" setting to "Configure site" page in installer

I think this is a good idea. It's a simpler idea than what I was thinking about that would allow multiple languages be enabled during the installation process.

Adding tags.

Discussed with YesCT in IRC and this probably won't be approved as it might be consider a "special case".

Added a related issue: #2007632: Create multilingual install profile.

This idea sounds like the opposite of what the original idea was, which is if you want to install in a different language you can fully omit English. Pushing English on them sounds like a divergence from that idea.

Here's a related issue from @klonos: #2010008: Multilingual site installation, Step #1: Allow selecting more than one language during installation.

This might be a better approach since it's not English-centric.

Ok... no reason to get nasty :/ I certain don't feel like continuing on this when you say "You are wrong" so blatantly. Perhaps I *am* wrong, but you can put it in a more tactful way ;)

And, just because I only speak English, doesn't mean I don't want this to be figured out in a reasonable way. I help out with multilingual issues even though I only speak English. I build multilingual websites so I have an interest in this. I wrote a whole multilingual Drupal book which took a crazy amount of time and effort.

Perhaps I'm just not understanding your issue entirely. English is my native language and German is yours so maybe there is a disconnect. I do find your explanations to be hard to understand.

I'll re-read your summary and comments to see if I can understand better...

Ok... let me see if I understand completely:

1) In D7, English was language by default. To get German UI but English admin pages you:

* Add German language
* Make German your default language
* Install admin language module
* Set English as admin language

2) In D8 (as of now), you would:

* Choose German in installer (this would be only language and is default)
* Add English language
* Set English as admin language

Yes, it's an extra step (adding English) but it's not much different than what you did in D7.

My argument is that the "add another language" feature ( #2010008: Multilingual site installation, Step #1: Allow selecting more than one language during installation. ) handles your problem as well as handling the case where someone wants to add more languages for other reasons. Don't you think that is the case?

I'm doubtful this checkbox feature would be chosen over the "add another language" feature because it does make English a special case which is what they are trying not to do in D8 (i.e. they are trying to make all languages on equal footing).

So... I'm not trying to shoot down your idea, I'm just saying that it might be better handled in a more generic way.

Instructions on d.o docs or in issues are written in English, so I see why you would want to have the admin interface in English.
The instructions in 2) in #10 seem reasonable to me in order to get what you want.

Similar add-something-to-the-installer issues have concluded not to go in that direction.
Add another language or a multilingual install profile seem more like the way to go.

@wusel sent me the German distribution he uses for D7:

http://www.drupalcenter.de/files/drupal-7.22-DE.zip

The process was:

* Choose German install profile
* Choose German language (options are German and English, defaults to English)
* Install/enable admin_language module

Administration Language module defaults to English for admin language so that's all that was needed (for his use case).

My understanding is that these language-specific install profiles will go away in D8 because the main installer will try to pick the language for you based on browser settings.

This is probably a somewhat common use case: English admin pages and non-English frontend.

Actually... I just thought of a place where this might make sense... add something on the page where you "Configure site". This is where it has the admin information and date settings. So, you would choose your "Administration pages language" there and the options could be 1) the language that you chose in the installer and 2) English (if you chose a non-English language).

This isn't a checkbox but the end result is similar... the process would be:

* Choose language => choose German
* Configure database
* Configure site => set "Administration pages language" to English (options are German and English)
* Finish installation

Thoughts?

Just thought about some more and it would be useful to open it up so it's not just English plus the language you chose... here's an updated process:

* Choose language => choose German
* Configure database
* Configure site => set "Administration pages language" to English (options are all languages, defaults to German)
* Finish installation

If all languages are available at this point, then we can do:

German frontend / English admin pages
English frontend / German admin pages
German frontend / Swedish admin pages
etc.

This would be totally flexible and make good UX (I think ;)

Tagging for usability review again. Hopefully @Bojhan has some input. I'll update the issue summary.

Updating title and tags to reflect new approach.

some typos

Updated issue summary.

Updated issue summary.

I only want a checkbox!

For "my" German websites I want only one language for "normal" users.
Not English and the installed language for all Users.

That does not sound like just needing a checkbox. If you add a language in Drupal, that is made available for everything, including node submission, user preferences, etc. It is not possible to selectively use certain languages only for certain things. We have #1314250: Allow filtering/configuration of which languages apply to what (UI, nodes, files, etc) opening to make that possible, so you can use English as the admin browsing language but not exposed to users. However, that needs a definite amount of work. What you are asking looks like much more than just a checkbox.

Gábor - see #16 that he's okay with just the setting in the installer. He's not turning on content or config translation so I don't think English will show up anywhere for his front-end users... oh... maybe on their profile page in their site language options. Anywhere else?

I still think the new idea of having this setting in the installer is good.

Technically, English indeed is a special case, because it is the language our strings are written in without translation and therefore could always be available without an additional .po import.
What we're currently doing in the D8 installer is explicitly disabling English after importing and enabling another language, which we don't necessarily have to do.
So "just a checkbox" or two radios for site default vs. English as admin language would be way easier to accomplish than importing even a second language in the installer. I think that'd be the scale of a feature we could still get done for D8.

One question is whether this special casing for English would cater most needs. I think it does, because as YesCT noted in #14, English is also special because most documentation is written in English, and it is also expected in forums and our issue tracker. And it is special because the original wording of strings is often more reliable. So there is a number of reasons why admins turn to English as admin language, not to Swedish or French or something else.
Another question is whether this would disrupt our efforts making all languages equally exposed in the installer. I'd argue that if it is really just a little checkbox (or radios) in "Configure site" as you proposed in #15, then it wouldn't give the impression that Drupal is unduly privileging English.

#1314250: Allow filtering/configuration of which languages apply to what (UI, nodes, files, etc) would of course be very nice, but is probably out of scope for D8. #17 would require an additional installer step importing one more language, while being beyond the needs of most everybody. So I think we should go the route you proposed in #15.

Thanks for the great input @Pancho! Yes, English is "special" because that is what is in the code. So, maybe this is an okay use case for just having the two options: chosen language + English? Making the patch with this combo would be way easier than with all languages in it and having to grab more translations.

It would be great to have some more voices on this matter... I'll see if I can drum some up ;)

If English is a language present on the website, things like this will happen:

- Detection and selection might pick English based on user preferences, URL, etc. depending on detection and selection config (on single language websites this may be avoided if only the 'Selected language' option is chosen; ie. you would need to turn off URL detection, which will lead to a confusing experience once you really want to make your site multilingual)
- User preferences will include English as a language option on each user's account settings
- All backend configuration creation screens, like Views, etc. will offer up English as an option to assign to the configuration

Updated issue summary.

Updated issue summary.

Updated issue summary.

Updated issue summary.

Thanks Gábor! I updated the issue summary to explain the 2 options this thread is entertaining.

Question is: is it good UX to add this setting in light of #23? Are these "side effects" unwanted and bad UX/DX?

@Gábor:
I'm absolutely fine with putting all efforts in #1314250: Allow filtering/configuration of which languages apply to what (UI, nodes, files, etc)!
At this point the question is: if we don't get it done by code freeze - and there's a number of even more important D8MI follow-up tasks - what do we prefer as second-best solution: staying with the status quo or allow to have English as secondary language, even if that brings some - IMHO acceptable - side effects.
I'm tending to the latter and think that having a prominent use case even might be an extra motivation to get forward with #1314250: Allow filtering/configuration of which languages apply to what (UI, nodes, files, etc).

@Kristen:
Thanks for updating the issue summary!
I came up with another argument why we wouldn't want to open up secondary language for all available languages (option 2):
If in the first installer step English is chosen as primary language, the whole locale stack isn't installed at all. So if the admin wanted say French as secondary language, we would have to install the whole stack only for the secondary language. At a late point in the installer, this isn't easily possible without even more repercussions.
So either the decision on a secondary language has to be made way earlier before installing the profile, which wouldn't be great for UX. Or we'd have the situation that a non-English language can only be chosen as secondary language, if the first language isn't English either. For UX this would be a WTF.
So while not impossible, implementing option 2 with a reasonably consistent UX would mean having to completely rethink and redesign the installer. Therefore I think that from the two options presented in the issue summary, only option 1 really comes into question.

@Pancho - Excellent points :) There is another discussion happening at:

#2010008: Multilingual site installation, Step #1: Allow selecting more than one language during installation.

about choosing more than one language at step 1. Maybe you can chime in there too :)

I can see that Option 2 opens up a can of worms :/ Option 1 seems viable as long as we are okay with the side effects.

One possible quick test for anyone who wants to try it would be to comment out:

language_delete('en');

from

core/includes/install.core.inc

and then run through the installer and see what side effects are out-of-the-box.

I could make a patch for setting the administration pages language to the chosen language or English, but really only want to do that if this looks viable from a UX/DX perspective.

Hmm, actually the two issues should be discussed together.
We'd either take the full multilingual approach allowing to choose a secondary language from the very first step and enabling the whole content translation stack (which is #2010008: Multilingual site installation, Step #1: Allow selecting more than one language during installation.).
Or we'd implement the minimal approach allowing English as secondary (admin) language for interface only (which is option 1 here). Anything in between (like option 2 here) wouldn't cut it.

What we can do is postpone this one here on a decision in #2010008: Multilingual site installation, Step #1: Allow selecting more than one language during installation., but with the risk of ending up with nothing, if the other discussion takes ages and is finally bumped to D9.
Or we'd stay on the safe side and push option 1 forward to a working patch, with the risk that our work gets outdated by a positive decision on the other issue.

I personally expect discussion on the other issue to take months if not ages, so I think it would make sense to push forward the rather simple solution we're having here. One or two more opinions would be great though, before starting work.

Rethinking all of this after re-reading #1917212: Add checkbox in installer to enable content translation (if in foreign language):

Option 2, the "checkbox solution", which I was so much in favor, unfortunately introduces an UX inconsistency:
Assume the default / primary language is chosen in step 1 and at a later point there is a checkbox for English as secondary / admin language. This would mean we're starting with the first screen in English, until the admin chooses, say Spanish, as primary language. The rest of the installation would be Spanish until the admin checks English as admin language. Then we'd switch back to English. That's at least weird.

So it would definitely make much more sense if the admin language (= the language used in the installer) is chosen first. This choice should just not necessarily be the default / user-facing language.

a) Now if we want the install profile to be able to react on the languages decision, we have to ask for the primary / user-facing language rightaway or at least before installing the profile modules.
Meaning we're doing the full multilingual install as discussed in #2010008: Multilingual site installation, Step #1: Allow selecting more than one language during installation..

b) If this is deemed to complicated as a first installer step, it's getting more complicated on the technical side. We'd then start with English or the locale stack + another language to be imported rightaway, informing the admin that at a later point another language can be chosen as user-facing / "default" language. Now if the admin later selects another language as user-facing / "default" language, we might need to belatedly install the locale stack and to belatedly import the other language plus invoke a hook allowing all modules to react on the default language being changed.
This would finally be Option 1 of this issue here.

So in order to deliver a consistent, straightforward UI in the installer we IMHO have to go the one hard way or the other. Option 2, the simple "checkbox solution" as my previous favorite unfortunately doesn't work out. Sorry for changing my mind, but this aspect IMHO is a game-changer.
If you agree, we'd in fact have to postpone this one here to a decision in #2010008: Multilingual site installation, Step #1: Allow selecting more than one language during installation.. :(

[edit:]
@wusel:
Technically it would be simple, yet UX-wise it's not:
1. It would push non-English admins into a multilingual install even if they don't want to.
2. This would trespass the line where English is unduly preferred.
3. And even for those that want English as admin language, it wouldn't simplify things much.
Doesn't mean, we won't end up with this solution as a lesser evil, but we really need to check the other options first in order to get to a really clean and consistent user experience.
Thanks for bringing up your idea - it helped us a lot bump this up on our agenda! And rest assured that we'll do whatever is in our powers to deliver the best possible multilingual experience in D8!

[disclaimer:] I build multilingual sites, but so far I always went this way:

- Install Drupal in English
- Add another language (usually Greek) after installation
- Set default language.

[/disclaimer]

In both D7/D8 cases, people like me that install in English and then add extra languages would not notice the difference between D7 and D8. This is true! I have only recently noticed that selecting a language other than English during D8 installation installs Drupal in that language and removes English (why that extra step?). Users like wusel that are used to installing Drupal in a language other than English had D7 also leave English in place while D8 removes it. That is wusel's frustration.

Well, with D8 there'll be:

1. people that only build single-language English sites. They'll see no change whatsoever.
2. people that build single-language non-English sites and never liked the idea of ending up with a Drupal site that has the language they chose + English. They will love D8!
3. people like wusel that actually liked the D7 behavior of keeping the English language after installation no matter what they chose. In D8 we simply ask them to add English back (as they would do with any other additional language I guess - I completely dig this: we don't want to special-case English). These people will hate D8 though for making them take an extra step compared to D7.

The way I see it, if we change D8 so as to leave English in place after installation (D7 behavior), we'll please group #3 above, but make group #2 hate us for making them have to take an extra step to remove English.

Honestly now, the only way I see pleasing all is by making less assumptions during installation and actually asking them people how many languages and which ones they'd like to have available once the installer finishes (again, shamelessly "promoting" #2010008: Multilingual site installation, Step #1: Allow selecting more than one language during installation.).

Also allowing them to select which of the selected language would be the default, front-end would be a bonus. This should be a different issue though.

Selecting a language for "admin" pages is covered IMO by #1314250: Allow filtering/configuration of which languages apply to what (UI, nodes, files, etc). I put the word "admin" in quotes because for content authors the node edit form is an "admin" page while for site admins "admin" pages might be a whole different set of additional pages. Also, each user can choose the default language in their profile, so basically (personally) I see no use for this. I guess that if enough people request this, we can simply have it work the same way that setting an admin theme does. Anyways, this matter is totally OT here IMO and should also be a different issue.

Giving people the option to select the language in which the installer will proceed should be a completely separate issue too.

Hope I didn't miss anything ;)

Wow! A lot to chew in here :) Thanks for the feedback everyone. Let me see if I can summarize the issues that have come up:

1. Question: Why does D8 delete English? This is different than D7 and some site builders might get annoyed for good reason.
    
   
   • Simple Answer: Treat all languages the same so if we are only installing in one language, then English should go away.
      
     
   • Complex Answer: See #23 above :) You get side effects with having English enabled that might not be desirable for your site.
      
     
   • Possible Solution #1: Leave as is. Site builders just need to enable English.
      
     
   • Possible Solution #2: Don't delete English. Live with any side effects.
      
     
   • Possible Solution #3: Allow multiple language selection in first step and have site builder choose English.
      
     
   • Possible Solution #4: Add a checkbox (or similar) in the installer to optionally keep/delete English. Builder can later choose English for admin pages language in profile form.
      
     
   • Possible Solution #5: Surface English in an "administration pages languages" setting in the installer. (option 1 in issue summary)
      
     
   • Possible Solution #6: Surface all languages in an "administration pages languages" setting in the installer. (option 2 in issue summary)
      
     
2. Question: Can we let them choose a non-English language on step 1 and then choose English as admin language later in installer?
    
   
   • Short Answer: No. The UX won't work because the installer UI language would suddenly change from step 1 language to English. Bad UX :(
      
     
   • Long Answer: See #29 above.
      
     
   • Possible Solutions: See previous question #2, #3, and #4. Site builder would need to manually choose admin pages language in profile but English would be available without having to go and enable English after installation.
      
     
3. Question: How do we satisfy builders who don't want English enabled and builders who do want English enabled but don't want the extra steps of enabling English after installation?
    
   
   • Short Answer: Allow some way to keep/delete English via installer, assuming that the UX is sane.
      
     
   • Long Answer: See #31 above :)
      
     
   • Possible Solutions: See previous question.
      
     

So, basically, I think this issue has come to these conclusions so far:

1. We can't allow changing the admin pages language in the installer because the UI language would change during installation which would be confusing. That makes this issue (as written) a "won't fix".
    
   
2. We have a "new" issue we could open on whether or not English should be deleted during installation and if an option should be provided to keep it. This does not make English the admin pages language... it just would keep it around in case it will be used.
    
   
3. We have an existing issue to discuss about choosing multiple languages in step 1 of the installer. My feeling (like others) is that issue will have a lot of back and forth and probably won't make it for D8 code freeze.
    
   

It sounds like I should open an issue for conclusion #2, yes? [UPDATE] Or, maybe this issue should be repurposed for the "allow them to keep English" issue?

@klonos:
Thanks for your clarifying case studies, and yes, I agree that we should try hard not to degrade usability for either of these three groups. And yes, allowing for two languages might be better than what we have now.

But I'm not immediately convinced of your conclusion that all we can do is completely open up for an arbitrary number of languages. I'm not convinced for a number of reasons:

• While it's nice if the installer UI is flexible, it seems more important that it is easy to grasp and straightforward and this might be more distracting than helpful.
• Asking for an arbitrary number of languages gives the impression that it's a "now or never" decision, so first time users might end up with an unnecessarily complex, hard-to-manage installation.
• Importing an arbitrary number of locales will take a long time on many shared hosts, so this would give a bad first impression.
• Why would this be "the only solution" to cater all of the three groups you portraited? Why would there in either of the cases be a need for choosing more than two languages in the installer?
• The question which language becomes the (user-facing) site default is not at all a bonus aspect. If more than one language is selected we need to know by the last step of the installer.
• Obviously even less a bonus aspect is the question which language the installer should use. This should also be the admin language, and by "admin language" I don't mean the language for specific admin pages but the admin's user language.

Every single of these aspects is relevant for the installer workflow and the technical implementation which isn't a no-brainer. We can't open up a can of worms and expect the rest to be settled by a number of followup issues.
I hoped option 1 on this issue summary was the small and contained first step we could just go forward with, but unfortunately it turned out to be inconsistent UI-wise. Now all other solutions (here and on your issue) are of a larger scope and bring repercussions that have to be carefully weighed and solved.
So what we currently need isn't just a "pushing forward" but a thorough discussion of the pros and cons of all possible solutions that takes into account all, both UI and technical, aspects. I discussed some valid points in #21, #25 and #29. Add to it Gábors points in #23 and the discussion in #1917212: Add checkbox in installer to enable content translation (if in foreign language). Currently I don't know which is the best solution, but it seems nobody else knows, either. We need to figure out!

Updated issue summary.

Updated issue summary.

Updated issue summary.

I hope this doesn't muddy the waters, but I'll submit a high-level perspective from someone using multiple languages with some academic linguistics background.

1. A common view is that multilingual speakers are not equally fluent in all subject matter in each language, but rather are better in some areas in one language and different areas in another. An example of this is that many drupal developers likely can converse about drupal better in English (or code-switching—switching between English and their language) better than in their native language alone.
2. As mentioned above, most documentation, issues, discussion, IRC, videos, conferences, etc. are in English. Most drupal site managers need to have a good command of English to do their job.
3. For me personally, and I imagine many others, I often go back and forth between 2 language versions trying to understand something. For ex., someone reading docs/issues/etc. in English would like to sometimes see their admin interface in English to ensure matching between them; however, that same person might want to switch the admin interface to his/her own language for terms/phrases they don't understand (or are poorly written in English, which we suffer from as well.)

So, disregarding lower-level difficulties in implementation, it would ideally be nice to have:

1. Drupal admin interfaces in English always installed and available
2. The ability to easily switch back and forth between English and another language in the Admin interfaces. It would be nice if this was possible for installation as well.

Thanks @Mark123! Great perspective and I think fairly common.

Your 1. would be addressed with the issue raised in conclusion 2 in #32 (allow site builder to keep English during installation).

Your 2. is already addressed because you can set your admin pages language on your own profile. So, they could switch pretty easily (an interesting add-on would be creating a switcher block for *admin pages* language but I think that would fall under contrib and wouldn't be hard to do... I'd probably be willing to do that ;)

So... I think all of this feedback is pointing to the fact that we need the easy option to not disable English in the installer. Yes? So... either I update the issue summary and we continue on this path here or we open a new issue. Not sure which is best. There is a lot of good discussion here that shouldn't be lost though the "topic" has *shifted* from "adding English to the admin pages language options" to "allow site builder an option to keep English in installer".

I think the tricky thing is to make it obvious for the site creator that adding English will equally make it available for all site users to choose / use, not just the administrator. There is no such feature as to "make this language available only for admin things" until #1314250: Allow filtering/configuration of which languages apply to what (UI, nodes, files, etc) is throughly resolved.

As far as I see, for the target audience where they want to use English as the primary administration language, they will install in English out of the gate and add one or more foreign languages later. It is pretty easy to add foreign languages later on and all the automation that works in the installer will work just fine there.

Also once everything is converted to the config system in Drupal 8, there will theoretically be no difference between a site which was installed in Spanish and then added English or installed in English and then added Spanish - if there were no other actions taken between installation and addition of the other language. The main outlier currently is node types, which are not yet in configuration (#111715: Convert node/content types into configuration). The reason this is significant is that once things are in the Drupal 8 configuration system, all shipped configuration will be in English out of the box, not installed in the foreign language used in the installer (as in Drupal 7). The foreign language translations are "just" overrides above the English shipped config in Drupal 8. So adding the foreign language later will just add the override later, but the config keeps being English. This is a major difference in Drupal 8 core from Drupal 7.

@wusel: that sounds like a misunderstanding. What I was trying to explain is that in Drupal 7, code was shipped in English (including install routines), however the install routines used t() to create configuration pieces (views, content types, etc) so the installed site had default configuration in a certain language. In Drupal 8, this is not the approach anymore. Instead we ship with configuration files that are not going through translations on installation and keep being in English (regardless of the language used to install). There are override files added to your site's runtime configuration system though, which server to merge with the default configuration and provide configuration translation. So if you installed the site in Arabic or a variant of Chinese or English, your default configuration (views, content types, etc) will equally be in English. The only difference is additional override files present with translations. So if you add the language later, the override files are created later, but the result is the same.

This is true for *shipped* configuration. Then if you don't have an English website, you are not expected to create all your custom content types, views, etc. in English obviously. So the system assumes you create these in your site's default language (and in many cases you can specify a concrete language if you have multiple languages, eg. in Views, content types, etc.). So once you built out your site to some degree, if your site default language is not English, you will have foreign language base configuration. Translating those to other languages is your job. Given that those are not configuration shipped with Drupal core, it is not a problem, if the source language for translating them is not English. The source language will be your site's default language.

This issue has been quiet... not sure if people want a checkbox to keep English during installation or not.

Feedback?

There are no disabled languages in Drupal 8 (http://hojtsy.hu/blog/2013-jun-17/drupal-8-multilingual-tidbits-3-simple...), so if you have English, it will possibly show up at all kinds of places. You can still add English after installation and it would have the same effect as if the installer added it, it will not behave differently.

@wusel: that may be the most visible difference yes. There are other differences:

- adding English is not required for any interface translation or other feature to work (unlike Drupal 7 where it was required to be there at least disabled)
- given no disabled languages, adding English will make it appear at more places than it used to be, which may be distracting/confusing (which #1314250: Allow filtering/configuration of which languages apply to what (UI, nodes, files, etc) would solve, but nobody is working on that either)

So eg. if you want to have a German/French multilingual site and have English for administration, English will equally show up when creating nodes or menus, while you only wanted to have a site in German and French. The consequences of some things are different in Drupal 8 therefore the base setup is different. Making people add English themselves will make them more aware of the consequences (instead of considering them bugs based on prior Drupal 7 experience where the behaviour was different). If #1314250: Allow filtering/configuration of which languages apply to what (UI, nodes, files, etc) is solved, which people here don't seem to prefer or want to work on, then we could add English in a similar way that it was in Drupal 7, that is currently not possible.

Updated issue summary.

I think we can safely won't fix this. This is not serving an 80% use case that one wants to do two different languages on the back/front-end. If this needs to be re-opened we can discuss the premise but it feels like there is very little value in this functionality

Since this is the issue that comes up in Google, is there another issue or documentation in how to get admin pages to keep the editors language rather than switching languages? Like this module for D7 https://www.drupal.org/project/admin_language

Since this is the issue that comes up in Google, is there another issue or documentation in how to get admin pages to keep the editors language rather than switching languages?

Couldn't find one, but added one: https://www.drupal.org/node/3192982