Improve language onboarding user experience

Ux design states attached

I like the screenshot and flow proposed in #4, nice work

I like #4 too, subscribing.

Subscribe

It looks very nice, but is someone who doesn't speak a word of English going to understand how to use it? (Compared to the long ugly list, where at least you can scan the list until you see the language you recognize.)

## Mockup 1

---

## Mockup 2

With the 'use another language' radion button selected, some more form elements are added to the form below:

label: Is this your language?

- radio button 'Italiano' (I assume this is a language already available to the installer)
- auto-complete textfield 'start typing to choose another language'

Below that 2(!) submit buttons:

- Continue
- Show all languages (I think this should be a regular link positioned close to the auto-complete text field)

---

## Mockup 3

Should you click the 'show all languages' button then all languages are shown (about 80 in this mockup) in 4 columns, each with a radio button. This list is shown below the submit button now labeled 'Hide all languages' but above the 'Continue' submit button. (So the two submit buttons have swapped places, hmm)

## Mockup 2 + 3
Isn't it better to show the full list right way and mark the detected language as default, maybe even write it at the top of the list?

People will immediately see all available languages right away, so they don't have to start guessing

Gábor, can you explain the 'Italiano' radio button in step 2? Does that mean that Italian is already available for this installer?

We should try to find an interaction that postpones having to show the big big list because yes, it is ovewhelming.

#16: i think it's the automatically detected language.

#15: i find the search box confusing, maybe show English and the detected language as step 1, and use a link the show all other languages?

Hello everyone,

Here are my notes on this issue from our discussion at today's code sprint. Please correct them or add to them if you see anything that I've missed.

Montreal Code Sprint Recommendations

• Default language selection should occur prior to profile selection to ensure that users only have have to deal with an interface in a potentially non-familiar language for a single step.
• A single select list should be used containing all available languages and defaulting to English.
• Language options should appear in their own languages/character sets with text in that language indicating that the user is selecting a default language for the install. This list should be ordered alphabetically by language.
• There was some debate as to whether or not English equivalents of each language should appear alongside each option. As I recall we were leaning towards not taking this approach to keep things simple and prevent the UI from being too anglo-centric. It was suggested that users seeking to install Drupal in a given language would be able to recognize that language in its given language/character set.
• JavaScript should be used to display sidebar information about what percentage of core Drupal is translated in a given language once it has been selected.
• On the profile selection page (reordered as the second step in the installation process) JavaScript should be used to indicate what percentage of a particular distribution has been translated to the language chosen in step 1. Some sort of mechanism would need to be created to allow distro owners to report this data.

These are some mock ups of what we discussed at the Montreal Coding Sprint. I've added a help tip (the question mark) by the translation status bar, in case a User is confused by the numbers that appear. Example: "What do you mean lolspeak is only 0.96% translated?!"

English detected (common case):

German detected:

Second screen after German is picked:

Translations from English meticulously done by the Google bot.

Where does the use case fall for admins who want multiple languages? Should there be a note underneath to say e.g. t("This is for the default language of your site, others can be added later.") to not give the impression that you can only install one language set?

Less clicks is better. More clicks takes more time and is unnecessary. I think the concepts in #21 provide a good starting point.

Can I suggest though that we make the UI design a lot better, and not make it look like where using something thats 15 years old, it looks absolutely terrible, I hate the look of the current install and update screens.

Hm. Not sure. i18n module (which I assume almost all multilingual sites have enabled) is in the top 50 of most-used contributed modules, but still only represents about 10% of site installs (~44K / ~483K): http://drupal.org/project/usage

Kevin's screenshots in #4 seem far, far less cluttered for the 90% case, and also matches well the "starkness" of the rest of the installer.

I do love the idea though of something like #21/#22 for the "other" case.

I do like #21 but it could get out of hand with more and more languages being added. The concept of choosing the default language based on the browser as per #4 settings is great where it is possible to do so.

It is really important that if English is to be used on buttons as per #4 that very simple phrases be used. "Start typing to choose another language" could be difficult to understand for someone with very limited English.

I would also agree with screens 1 and 2 from #4 being combined as the one step.

@jamienotweet: Agreed on the UI, but that's a separate issue for now.

Given that there is a distinction between languages that have first-rate support and ones that are lagging, might it make sense to draw a distinction in the UI? A styled opt-group, or an icon (with a translated tooltip explaining what it means) might suffice, just so that admins don't pick their native language only to find out that the only thing that was translated was the installer ;)

Subscribing

I made a mockup based on #4 ideas with a few changes:

I think there's no need to have a "Use another language" first step. Show all options at init would be fine and will not bother so much the English users.

The "Is this your language?" part can be merged into the detected language name, showing a more clear message for the option like "Install in Italian (auto-detected language)" . Also, this string can be displayed in native language instead of English.

The textfield + "all languages" link is fine, but I like the way how Chosen do that, with a select field integrated with search. Don't know about possible technical and legal troubles of including it on Core.

Suscribing.

Lots of great ideas here.

Comment #31 brings much together. I like the select box and search while typing.

I also like it when the language name comes first. e.g.

Rather than "Install in English" something like "English for default language"

And "You can add more languages after." to "You can add more languages later."

Language selection as a second step after profile selection was really there for technical reasons (we looked at local files for the profile after you picked your profile). Since we want to unify the translation file directory to one place (and add remote download possibility there AKA l10_update in core), we basically remove the connection between profiles and translations, so we can move translations up front.

Having the language selection after the profile selection also means that profiles in Drupal 7 can completely modify or replace the language selection UI that ships with core, just by using hook_install_tasks_alter().

I don't think we want to lose that ability. Not sure what to do about it, but perhaps we can come up with some ugly special case that allows profiles in the file system to alter that one install task (if they really really want to), even though they aren't the actual chosen install profile yet?

#21 is the best.

my 2¢: I prefer the idea of a select list rather than radio buttons. Users are familiar with this from choosing their country on shopping card forms.

I am also for the verbose, full sentence option, but I would definitely like to see the ISO codes included as well. In a side column or something, not to intrude onto the focal sentence; but to give the "power" user a clear understanding of the language pack installed (en_uk, en, en_us, en_au, etc.).

The idea of including the status of the translation is also very helpful so I am all for that one as well. Maybe expand it with

1. Full translation indicator (96%), and a split between admin interface and user interface translated. Is there such a split between the translatable strings?
2. A Drupal sel-promoting link: YOu can help with translation here link to the localize of your language

I also like it when the language name comes first. e.g.

Rather than "Install in English" something like "English for default language"

Agree. But I don't know if this can be done on every language (maybe some foreign grammar rules don't allow the sentence in this order). That's why a search field on top on the select list is useful, because it can search in the middle of the string too.

Also, for #21, I think we can introduce a search field too for the same reasons. It's also sends a clear message for the user that he/she can start typing for search on the select box.

Another thing about #21 is that I like the button with a arrow as a elegant solution for avoid using a English string there, but I don't know if it's gonna work for RTL language speakers. Well, there's just this button, the user has no way to go wrong, but we may have to pay attention to this.

I do like #21 but it could get out of hand with more and more languages being added. The concept of choosing the default language based on the browser as per #4 settings is great where it is possible to do so.

We thought of having many different languages to choose from, so we built in the ability to scroll. By auto-selecting the language for the user, they're going to see immediately what they need - but if they want to explore more, they have the ability to see their auto-selected language in context of the rest.

On a second note, having the full list of languages immediately available to the user encourages them to explore and engage with it, if they so desire. By showing all that we have to offer, we may get more people contributing to translations. The overall goal is to make it easy for them to do it, so they're delighted by the idea of having Drupal in their own language. Making this process a single, pleasurable step will encourage people to use it again and again, either for functional websites or experimental ones to help translate Drupal.

Given that there is a distinction between languages that have first-rate support and ones that are lagging, might it make sense to draw a distinction in the UI? A styled opt-group, or an icon (with a translated tooltip explaining what it means) might suffice, just so that admins don't pick their native language only to find out that the only thing that was translated was the installer ;)

The issue was that we didn't want to appear to be recommending or devaluing languages by incorporating that into the selection process. We should encourage Users to experiment and explore at this stage - it's about the possibilities that Drupal provides, not requirements. Having a warning sign on the install page of Drupal is not a way to make a good impression.

Additionally, some languages only need 1-2% translated to be considered "complete," such as English British. While it is complete, calculating it's completeness based on percentage would display it as not. There's no context for the icons if we were to incorporate it into the list of icons displayed.

We tried to answer that by displaying the percentage of completeness in the selected language. We can pull it quickly, and easily, as a JSON file from http://localize.drupal.org, which contains all of the information anywho. This information is only displayed after the user selects the language, and saying that "Drupal core is XX% translated into English" with a tool tip to a relevant page on http://localize.drupal.org/ which explains what this means. It removes the taboo of a warning icon, addresses accessibility issues, gives context to the information and lets users make an informed opinion of what language they would like to install.

Interesting to see movement on this issue, I really like all the new ideas that are putting forth.

Let me assure you that most commercial software is unable to gracefully handle this situation. Often the decision is made to go for an inflexible interaction, because the majority installs a pre-configured localized version or the number of people choosing outstide of the top 5 languages captures the 80% usecase.

As a general strategy I would like to avoid complex interactions, such as chosen(#31) or searchable radio options (#13) because aside from their accessibility problems - they put us in the mindset of trying to capture "everything" in one interaction. I already see that from the discussion here, trying to add level of completion, iso codes and promotion links into it.

@Gabor Although I would favor showing many languages for the sake of, showing off that we are a international platform - but we cannot do that with an interaction that you showed. This because it isn't very usable (hidden features), doesn't scale(scrolling becomes hard) and its hard to scan (weight of languages on importance not alphabetic order.). I dont think that webchick's argument applies if we find an interaction that allows for easy find-ability of other languages and not making selection of English more difficult.

What about something more simple like a "Additional languages" link or fieldset(collapsed) that shows 3 rows of language options with a search box on top.

The fact that few systems do this well, should also push us to do some more experiments.

Sorry I cannot join the Code Sprint in my home town. Too busy!

Please note that on all these mockups there are a lot of text in English! This means that a user needs to understand English to know how to use the language selection screen.

That's why #31 is the wrong way to do this and the best I see is #21.

For 90% of the world, English is foreign. So please do #21.

It's great to see how things are progressing in the code sprint!

Please provide descriptions of screen-shots of suggested UIs.

Chosen is likely not going to make it into D8, if it does a * great * deal of accessibility work will be required upstream.

Thanks for the descriptions.

None of those sound like they will cause any problems from an accessibility perspective.

My only contribution is to *please* skip the "language selection and education" screen when the current install only has english. We need to find other places to educate about additional languages. Thats mostly a distro thing IMO (folks who repackage drupal).

Perhaps changing the proximity of the tool tip, so it located at the top. I think the switch would establish a closer/stronger relationship to the language you choose, as well as leave the next arrow as the last action item, moving the administrator through the process.

Sorry, I didn't understand the proposal for D8. If we can fetch the list of languages and download the selected language in real time, then I don't think we need a separate 'proceed using english' page.

It would be good if folks started thinking about drush's site-install and how it should participate in the 'download selected language during installation' feature.

Subscribe

Just as a defensive mechanism, the design in #21 was specifically built to not complicate the whole process. By adding additional elements to the page (radial buttons, second drop downs, etc.) we're going to complicate things for anyone who has accessibility issues, cannot read English, and for beginner users. Keep It Simple, Sweetheart!

I really like the suggestion of moving the "Drupal Core is % Translated Into Language" tooltip up to the top as suggested in #50. The only thing that we have to be careful of is making sure that it's appearance is handled smoothly as it'll push the rest of the content down.

As a proof of concept, here's a patch to transform the radio buttons into a select list, and auto detect the browsers language. There are some issues with the function locale_language_from_browser that are being addressed in #221712: locale_language_from_browser() doesn't parse language tags correctly, has a broken logic. It works generally well in firefox.

Reposted.

I tried to mockup something like #4 (just two choices, English and Other) with #22 (A large select box asking you to use "English as my default language", "Deutsch something german", etc.) showing if you chose "Other", however I didn't actually like how that looked in reality. :P Of the proposed options, #22 limits it to just one choice, which is nice. Although my first inclination there was it seemed a bit visually OMG LOOK AT ME!! for something that most people are just going to click right through. The longer text is more friendly, but it also requires a lot more thought than a simple scan for the word "English" in a list. But I also think that could just something that would take some getting used to, not sure.

Here's what the patch in #58 does; similar to the mockup #22:

The context option used in st() calls in #58 should be a langcode instead, so each option will be translated into their native language.

Also, later we'll need a way to ship with Core the translations of this string for all supported languages.

This is such an interesting discussion :)

I do like #21, but I have a few comments. So, we can detect the locale of the user, and this screen is going to present the languages based on the locale. That's great! But can we have a visual differentiation between the languages that might be relevant to the user from the rest of the languages?

With the preferred languages, the need to select a language from the endless list would be drastically reduced. But if they have to go through the list, we need to have some way to sort these languages.

On a another a-bit-crazy thought, I was toying with the idea of having a clickable world map as the first step. I did a very dirty paper prototype study with five people in the office and told them if "You are installing a software and this is the first screen you see, where would you click?". All the participants told that they would click on their home country/ country of residence/ their time zone. Based on what country they click, an icon of home (with a flag) can appear on the country which will determine the context of what we are asking them to click. Of course, we can skip all this because we know their locale.

But, I thought it was just cool and it also talks about our global presence.

The map idea would not work. Spanish is spoken in a lot of countries as well as French.

We need only look at the “Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3” header request to know the browser languages of the user’s browser.

Having a list of the other languages is fine, but I guess we should offer only the languages already defined in the Accept-Language Header Request.

Furthermore, the sorting is already defined in the header request:

For example, Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3 orders the languages to:

fr
fr-FR
en-US
en

This data is ready to read and parse.

I have not looked at the patch to see if you actually read the Header Request. But I guess you are already doing this already!

The globe idea, though, can be applied in the “localization part” (which is another story) of the timezone selection.

Please remove the white spaces in the patch. :-)

@dcmistry: in addition to the issues the @xmacinfo mentioned, I suspect the map UI would require a significant amount of accessibility work.

subscribing

Subscribe

Perhaps a separate issue, but it would be great to combine screens. We should be able to do better than a 7 page install (thats the last screenshot here).

Agree that the world map has its drawbacks and might seem like re-inventing the wheel. Thank you all for the comments. I wanted to just wanted to try different ideas :)

subscribing

New design comps attached

To provide some background to Kevin’s design:

1. Reduce the clutter by displaying only the native language and not the sentence
2. Produced a “Chosen” (http://davidwalsh.name/query-chosen) type of approach, but opened by default (include a textbox at the top of a select box that would jump to item typed vs. filtering the list to that). This is to reproduce the select box type behavior that people might not know.
3. The first language is auto-selected by the user’s browser language settings
4. The “100% translated” string will be in corresponding language
5. If an RTL language is selected, the design swaps in an RTL sheet immediately to move the controls to the right side of the screen
6. A note (in the language selected) at the bottom of the box informs the user that they can add more languages later

Bojhan, Yoroy and I discussed the design in the UX happy hour. They thought the design was good (we did not talk about branding, because it is a separate and a bigger issue). However, their concerns:

1. How is the list to be sorted?
The way it was designed, it was suppose to have the auto select language followed by languages in the order of their ISO codes. However, Another approach to sort was: what if the list should be sorted in the following way: auto selected and then sort by their occurrence (how many people speak that language in the world) and then sort by ISO codes.
2. There is no help text. It is like a chicken and egg solution. How do you write help text when you don’t know user’s language. Perhaps, have it in the default language?

We also want to make sure it meets the accessibility needs.

Some descriptions for the accesibility maintainers, the approach that tkoleary proposes is :

A vertical list of language options; English 100% translated, Spanish 98% translated. (this can technically be a select list, and/or radio list). This list is currently visually limited to 8 options.
Above this list of options a search box is shown, this search box filters the listed options below (similariy to autocomplete, going per letter).

Although similair to choosen in terms of interaction, it should conceptually be a bit different and allow us to use WAI-ARIA live region or degrade nicely to a full list.

I hope my description was understandable and accurate, I will adress the design problems dcmistry listed later.

"select box that would jump to item typed vs. filtering the list to that" and "sort by their occurrence (how many people speak that language in the world)" together can be a bit tricky if, for example, the list has the order:

- English (US)
- Spanish
- Chinese
- [...] A lot of another languages
- English (UK)

So if the user type "english" on the text box, only the US option will gain focus.

Also, this sort will looks a lot "WTF" for the user who don't want to use the keyboard and prefer to find the language by scrolling on the list.

I suggest to keep alphabetic sort.

I love the design and simplicity of #74. Looks like Drupal 8 will have a very nice installer!

As for sorting, the installer should link in order all the “Accept-Language” defined in the browser request header. All other languages should be invisible, or a “+” button to show the complete language list.

There should not be any English text on that page, so no help text below.

As for the list in itself, we should list them like this, each line in it's own language:

*French-France (installer en) 100 % traduit
*French-Canada (installer en) 98 % traduit
*English (install in) 100 % translated
*English-USA (install in) 99 % translated

Likewise, the xx% translated should be shown in the native language.

danillonunes,
As far I understand it correctly, if the user types "English", all the languages matching to that string will show on top of the list i.e. "English (US)" and "English (UK)". And below that, other languages will be displayed.
Does this take care of your concern?

@dcmistry: “Does this take care of your concern?”

Well… no. There should not be any need to type English or any other language since all that information is already known by reading the Accept-Language request header. So by default, the top of the list should be auto-generated.

For example, if my browser is set to Italian, the list should automatically display Italian at the top. And if my browser accepts other languages (as read in the Accept-Language request header), you display these known languages at the top of the list in the same order defined in the Accept-Language request header.

See Gábor comment in #66 about the Accept-Language request header.

Now, if I really want to install in a language not defined in the Accept-Language header of my browser, I would probably need to read the language name in a language I can read. If the browser is set to French, we should display all languages name in French. But this last paragraph goes against the gist of this issue. :-)

A speech-bubble represents a comment to me and as far as I have seen it's also what it's being used for in other applications/sites, a bundle of flags or similar is usually used to indicate the choice of language.

@Gábor, there's another softwares and sites that do it in some way.

Here are samples of Ubuntu and Facebook language selector screens. I guess they both use the ISO code for language sorting.

If you look at sidebar of Wikipedia, you will see that they try to sort first by the native language name, if the first letter is a latin character, and if not then they sorts by the their subdomains (which is basically the ISO code for sorting purposes) - so languages like Magyar (hu) and Suomi (fi) looks "right" on the list - and you probably know if this is better or not.

Also, I don't know how speakers of languages that don't have a latin alphabet feels about it. My guess is that Chinese speakers know that they language can always be found on the end of the list, even if they don't know why. So it's better to be a bit more predictable here.

(By the other hand, I found that Twitter language selector doesn't make any sense. It probably uses Bogosort...)

Yep, I hear you lslinnet
tkoleary and I did contemplate a few options as to what should go there. As much as I like the idea of flags, I see the next obvious question being raised "Which flags should be there and which should not be?". We certainly do not want to alienate any of our users - They all are the awesome Drupal sauce. Thinking (aloud), some options:

• How about having a map there instead? It may reflect the geographical reach? Hmm. Not sure about that one, seems like its got flaws. People might confused that with the country of residency.
• How about having human face figures with voice emitting from their mouths? The icon may be seen as "audio" but in this context they can see it is about the language
• How about having no icons at all? Do we need them? They do add visual value, but without them the job gets done well too

Point taken on the bubble. I will explore other options.
Flags are a non-starter because it will be impossible not to alienate the nationalities who are excluded. Also flag denotes nationality which is not synonymous with language.

Awesome work, really like the direction we are taking with this. Given that this is the first screen almost all Drupal users see, we can set quite some expectations :)

Let me start by describing what is really good, it narrows down the long list to a comprehensible 8 items and uses search as the main interaction. I think both these are major wins to other solutions, with auto detection the likelyhood that you will spend a lot of time finding the appropiate language is minimal.

It is very likely we can optimize this interaction to be accessible, however I would like feedback from our accesibility maintainers before we commit to working on code.

Now, onto my remarks:
1) Why are we removing page titles, they serve a clear purpose of informing the user on which page they are on. Especially if we concider, those with cognitive and/or visual impairments the gains seem confusing? Additionally this theme is used for all updates/module installs, do they also have no titles?

2) The removal of the progress indicator on the first step seems somewhat vague. I understand that it adds clutter, but we introduce it the next step? I feel that the progress indicator is increadibly valuable information to users, knowing that you are at the begin of a process and how long it will approximatly take is key information when installing something. Even visually, without being able to read english - the actual visual signals of the progress indicator should give the user some insight. I am not really too afraid of showing a little bit of English, and its not uncommon for software either to show a progress bar in language selection screens.

3) In terms of ordering, I am still on the fence what the right approach would be. Using the ISO code for language sorting is what Gabor seems to propose, can you ellaborate more what that means? Hopefully the automatic detection is so usefull, we can show the first top 2 (your own language) + English (or other browser supplied default).

4) The RTL switching is very jarring, lets not do this kind of magic on the fly - it will confuse people more than some english :).

5) I think we are trying to be too smart with the icons, if we put the progress indicators back in - we shouldn't have to worry finding a icon that represents "the world" and "languages". I am conflicted about their aesthetic value, because it is not a design element that will return often in the branding of Drupal core.

6) How do we determine the langauges listed here, is there a certain treshold to be included here? For example 80% translated?

3) Ordering, sounds like that approach is fine. I am somewhat sad that we push people to go with the language of their browser. Because of my own bias, knowing that many dutch people never go with the Dutch translation - but I guess that only applies to countries where English is like a second language.

6) This problem is a bit of a bottleneck. I understand the completely valid reasoning to elevate these languages to attract more contributors and the use case of only using it to translate the front-end. However I think the whole concept of showing the percentage of translation is quite a "Drupalism", I have never seen this in other software.

If we decide to show all languages, we need to consider the experience of users that install Drupal with a language only half or even less translated, because this is a really horrible one.

We do it to inform people their language exists, its just not translated to the point its usable. Why do we want to trouble the ordinary user with that information?

What if this threshold is lower, say 60%? You could say, we hide these languages (thus don't encourage collaboration) but you could also say, this is a challenge for them to get to that 60%.

This looks like it could add a lot of usability to new users.

As long as the autocomplete is using tools that have been tested for accessibility many issues there will be dealt with. Hopefully jQuery improves their code before we are fixed on a version for the release:
#675446: Use jQuery UI Autocomplete

The list of languages should all be tagged as per:
#1164926: Nodes need to have languages specified separately for accessibility

Edit, on that point, a related discussion from GDO http://groups.drupal.org/node/145894

@Gabor, they are better than nothing, but I'm with ivanjaros, front-end is way more important then backend, we build a lot of multi language sites (EN, NL, FR, JA, CN), but we always start in English and add translation in a second phase, most of our clients don't care if there's an English word in the backend, but they do mind if it's in the front end.

Is there any way for languages to indicate some "meta" information like whether the front-end is mostly translated or not? As others have noted, a random 30% of strings translated is a lot different from 95% of front-end strings translated.

If not, I'd say just include them all. There's no way it could be that much of an annoyance. Worst-case scenario, you see that your language isn't very well covered, and you either try it (and have some of the UI in English, and potentially help translate the rest) or you just decide to go with English instead. In fact, it might make sense to always show English as an option even when the list of languages starts filtering as you type in the search box -- that way people can always choose it as a fallback language if their language doesn't exist or isn't fully covered.

I think partly translated languages should be kept. If nothing else, it will keep a level playing field and allow those languages to evolve. If these languages need to be installed in a different way, many people won't bother to keep improving it.

Re: marking front-end strings, I think that would be very useful. Often front-end strings make up just 10% of the strings to translate, and I need to hunt them down, and I often miss some. And the reality is that many admins are comfortable with English. We couldn't make this mandatory, but some way of marking strings as front-end would be nice.

The designs look very promising. As a developer who worked on many multilingual sites, hiding the percentage of the language is better, and it's (most of the time) not needed info on install.

@Gabor: When are you going to implement it? is it dependant on other issue(s)? I'm willing to help/do this.

@IceCreamYou2: its not really possible to tell which string is on the frontend of backend.

I was thinking more along the lines of a single property for the entire translation, like "readiness = FRONT/BACK/ALL" or similar, set by the translators based on how far along they are.

Gabor,
If you are referring to talk we all had a few weeks back, then I think remember things from that convo

5. Build a textbox above the select box to jump to the language typed (or filter to the language typed), both were mentioned above.

Yes!

6. Hide the list of steps on the side.

Yes, because the steps start only once you select the language. It also helps to take the problem in what language do we use the steps when the language selection is the first step.

7. Switch to RTL on the fly when an RTL language is selected.

Yes, Kevin suggested this.

8. Display percentages of languages.

I think what we talked about was to show the percentage when the language is selected

9. Display a limited list of languages.

I think it was to show the full set of languages to show that Drupal is really global. But I may be wrong.

Hey there, just giving my opinion on this: I agree on the fact that 3 columns of radios are ugly and not user friendly. But I do think that radios are the best way to display the "main" options:

1. First option : "[User's detected language]"
2. Second option : "English"
3. Third option : "Other language" with ajax-enabled textfield+list

Why this ?

• English-speaking people like moshe weitzman (#49) will only see "English" as it is the same as user detected.
• The UI is kept simple, only 3 options at first sight, most important are already here, additional ones will appear via Ajax
• This is still a standard form, hitting tab and enter will submit it

I love this anyway!

@SebCorbin, I think the screen as proposed in #81 is a good way to move. English, although is the default language to code, has nothing special from a product point of view, so there's no reason to keep a permanent "English" option.

A select list of all languages, quoting Gábor, "shows that this product is truly worldwide and supported for those markets on the same level". Also, the language auto-detect-thing ensure that English speakers who wants to install Drupal in English will not be bothered with the big language list (and it's also valid for French speakers who wants to install Drupal in French, Spanish speakers who wants to install in Spanish, etc).

Gabor: That's fine by me :)

I've begun writing the patch. Installer stuff are not easy since many things are not loaded. I reached a point where I have to put the autocomplete textbox, resulting in lock.inc & semaphore table errors, since this table is not there yet (it's called from menu.inc, because autocomplete path trigers this), any idea if anyone has done something similar here? or we should write our own autocomplete script for an installer? The other points (1,3,4) are done now.

#675446: Use jQuery UI Autocomplete might be dep.?

I've done 1,3,4 from the list of comment #104 by Gabor. I have 4 questions now to ask/agree on.

1- Should we put our language highlight and selecting stuff in new js file (e.g. /core/misc/selecthighlight.js)?
Some cool selector stuff:
http://jquery.bassistance.de/autocomplete/demo/
http://andrew.hedges.name/experiments/narrowing/

2- Putting language selector in first step cause me to remove this:

$function = $profilename . '_profile_details';
if (function_exists($function)) {
  $details = $function();
  if (isset($details['language'])) {
    foreach ($locales as $locale) {
      if ($details['language'] == $locale->name) {
        $install_state['parameters']['locale'] = $locale->name;
        return;
      }
    }
  }
}

do we need this one? i.e. selecting default language from profiles? if so I think we should put somekind of hook for it?

3- I'll replace this silly multiselect box when we agree on how to do it, do we want to put it in table and then use the script in point #1 to select/autocomplete/hightlight?

4- We need a form validator handler (to make sure the user didn't type any invalid language), and a form submit handler (to replace the langname in textbox with langcode, the former radio box didn't need this since it holds the langcode in it's structure).

1. I think we should skip this for now as said above.

I was talking about the functionality in #81, when user types a highlight should indicate the language in the below box, right? just like the normal autocomplete but with the box/list below it, not a popup.

2. Yes, we discussed this above and concluded that we can put in a $conf setting for distros that want to ship with a specific language. By moving the language selector first, we cannot rely on calling a hook from the profile, since we don't know which profile to call. Also given no database system, etc. are field is very limited, so we can only rely on very core functionality, like the config file. I believe that is loaded/loadable at that stage, no? We need to introduce a new $conf setting for this something like 'profile_default_language' or 'profile_preselected_language' or something like that.

Yeah it can be loaded from settings file. We should document this.

3. I believe we need a single select box but with a higher display of multiple languages, right? It should not be a multiselect box.

We need something like, readonly-textarea. Is this the best option for this list? or we put it simply in table? (table theming causes problem at installation stage).

$default_language now is $browser_langname, not $browser_langcode, because locale_language_from_browser() returns the langname not the langcode. I removed $form['locale'][$locale->langcode] field too. Removed the title for the second field (the multiple select box for now), I put previously just to show what this box holds.

2. Yes, we discussed this above and concluded that we can put in a $conf setting for distros that want to ship with a specific language. By moving the language selector first, we cannot rely on calling a hook from the profile, since we don't know which profile to call. Also given no database system, etc. are field is very limited, so we can only rely on very core functionality, like the config file. I believe that is loaded/loadable at that stage, no? We need to introduce a new $conf setting for this something like 'profile_default_language' or 'profile_preselected_language' or something like that.

I don't understand how this would work? You can only set $conf in settings.php, but it's not a good idea for a distribution to ship with an actual settings.php file (for the same reason core doesn't). Also, I think that distributions on drupal.org (not to mention plain old install profiles that aren't packaged as a distribution) don't have any way to do this even if they wanted to.

Also, we're not just talking about the ability of profiles to pre-select a language; they also currently have the ability to completely swap out the language selection UI and it seems like that would go away too.

In #54 you suggested .info files as a way to deal this, which makes more sense to me. For example, a profile could have an info file setting that says "I need to modify the language selection", and maybe if any profile on the system has that, we switch the order and put the profile selection screen first. Then the profile author could proceed as normal and modify the language stuff however they see fit. Even with the profile selection screen first, things would go pretty smoothly for a profile that pre-selects a language, because (presumably) the hypothetical "German install profile" would write its name and description in German; therefore a German speaker who downloaded this and started to install Drupal with it would still see something in their language on the profile selection screen and know right away to pick that instead of Standard or Minimal.

Of course, what would be a real killer (additional) feature is for distributions to be able to skip the profile selection screen altogether (i.e., indicate somehow that all the core profiles should be hidden). Then you'd download the (fully packaged) German distribution from drupal.org and it would skip the first two screens of the installer automatically and you'd start off with the database configuration screen already translated to German. I think that's what you were getting at with #54 also. That part is a separate issue though.

What's wrong with changing the order of the install steps if the profile wants to modify languages?

I don't see how it can really work without that, and it should be very easy to do. I think that's better than removing this feature and hoping we'll find a way to add it back again as part of another larger issue.

The only argument I can think of against it is that this would lead to an inconsistent installer UI based on which profiles you have in the system. However:

1. This is an edge case anyway; not too many profiles will do this.
2. When you download a random contrib profile to your system it's usually because you intend to use it... and since any profile that is modifying the language selection is already changing the standard installer UI (by definition), it's not like someone following along with generic "how to install Drupal" documentation would be able to do it for that profile either way.

note we have plans above to do language dependent things on the profile selection page for example above. If we need to build for install profile tasks in different orders, we'll spam the code with conditions for this case and that case

I don't see what the spam would be. Any code you write for this in the future would always have to check what the language is before using it anyway, right? In this case it would just be NULL sometimes...

people who want to override the language form will likely want to override the profile form as well, and can therefore be solved the same way.

That would be OK if we had a plan to solve things that way, but I don't understand how a profile that hasn't been selected yet can override the language form... How would that ever work? :) It sounds like we'd have to build a whole new system which definitely isn't necessary just to keep the language form modifiable.

So whatever we work out here would be pulled out altogether and I'm not keen on working on stuff we plan to remove soon.

The code I'm thinking of is extremely simple and will hopefully take me only 20-30 minutes to write. I'll happily write it later today and add it to the patch, and if it needs to be removed later, I'll survive :) Per above, I don't see why it would need to be removed, though.

$name should be $langcode.

That's right.

'language' property on a language object contains a langcode, so this should do => $langcode, based on the above rename. Not $langname! locale_language_from_browser() also works with langcodes, not language names.

Not sure about the langcode, since for example langcode is 'en' and langname is 'English'. The only incorrect var name was the above one ($name) which is $langcode now.

Also, I've looked into the API for locale_language_from_browser(), it says that it should return a langcode (en, ar), but in reality I'm getting a langname (English, العربية). Can you double check it too, so we can open another issue if it's a bug either in documentation or in implementation?

@good_man: that would mean that point 2 from #116 is considered skipped for this issue.

Yes but let's not forget to open this issue, since we removed it here.

I don't see what the spam would be. Any code you write for this in the future would always have to check what the language is before using it anyway, right? In this case it would just be NULL sometimes...

I guess we should make sure it's 'en' by default (if skipped) not NULL. right?

The code I'm thinking of is extremely simple and will hopefully take me only 20-30 minutes to write. I'll happily write it later today and add it to the patch, and if it needs to be removed later, I'll survive :) Per above, I don't see why it would need to be removed, though.

Your point is very true, also wants to see how would you solve it.

ohh that's right! I don't know how I missed that -_-

The code is much cleaner now, thanks for mentioning this point Gabor.

The code is much cleaner now, thanks for mentioning this point Gabor.

EDIT: sorry duplicated, don't know how it happens, I think it's my connection.

OK, I've rerolled this patch per my comment above, so that the patch no longer removes the core feature which allows profiles to alter or skip the language selection step. Overall, the code for this did wind up to be pretty simple, I think.

By default, the patch should work the same as the one above.

To test that the alteration works correctly, you can add something like this to standard.profile:

/**
 * Implements hook_install_tasks_alter().
 */
function standard_install_tasks_alter(&$tasks) {
  $tasks['install_select_locale']['display_name'] = 'This is a test';
}

And at the same time add this to standard.info:

custom_locale_selection = true

This should cause the profile selection screen to be first. If you select the standard profile, the language selection step will be next and the above "This is a test" modification should appear immediately.

You could also try to test the automatic language selection feature (formerly in the pseudo-hook hook_profile_details but I decided it made a lot more sense to put it in the .info file now), by adding this code to standard.info:

locale = XX

where XX is a langcode. But note you have to have at least one language besides English available on your system for this to work, due to a preexisting bug/feature (I'm pretty sure it's a bug).

Oh, also, for both #127 and #129 I get a fatal error when I actually try to click the "Save and continue" button on the language selection form:

Call to undefined function db_delete() in /home/droth/web/drupal/core/includes/cache.inc on line 511

Anyone else experience that too!?

Assuming it's not pilot error, I'm marking the patch "needs work" for that.

That is SO freaking hot.

+++ b/core/includes/install.core.inc
@@ -523,20 +531,40 @@ function install_tasks_to_perform($install_state) {
+  $custom_language_selection = FALSE;
+  foreach ($install_state['profiles'] as $profile) {
+    $info = install_profile_info($profile->name);
+    if (!empty($info['custom_language_selection'])) {
+      $custom_language_selection = TRUE;
+      break;
+    }
+  }
+  if ($custom_language_selection) {
+    $tasks = array_reverse($tasks, TRUE);
+  }

We can simply get rid of $custom_language_selection local variable like this:

foreach ($install_state['profiles'] as $profile) {
  $info = install_profile_info($profile->name);
  if (!empty($info['custom_language_selection'])) {
    $tasks = array_reverse($tasks, TRUE);
    break;
  }
}

Also do we need to swap profile functions order (place in file) with translation functions first? as the default order of the installer wizard?

Regarding the languages textbox, we have three options IMO:
1- Multiple select box (and remove the multiple with jquery), so we get the look of expanded box with only one language to choose.
2- Readonly textarea.
3- Themed div.

20 days to next Drupal core point release.

Interm approach seems fine, I would like to see a clear plan which parts of the design we want to tackle (perhaps already with issues).

I really dislike the help text, why are we adding this again? The usual Drupalism, of informing users of potential things that you might want to do but probally wont?

The “locale”, “locales” are not a very good idea to name languages. Locale represents a lot more than languages and a lot of times, locales are location-based.

To localize a software for, let’s say French Canada (fr-CA), we would need to:

1- Set the language to French (or French-Canadian if available).
2- Set the date format to French Canada (date format and order in addition to the French naming).
3- Set the number format to French Canadian format. For example space for thousand separators.
4- Set the decimal separator to a comma for the French Canadian locale.
and the list may go on…

If the installer plan to also set all the localization attributes, and not set only the language, we may still use “locale”. But if this patch and the functions are only setting a language no matter the localization of the user, we should then stick to “language”.

Rerolled to address @good_man's feedback from #138. (I guess I introduced that variable thinking I would use it more than once, but apparently in the end I didn't!)

I also added some extra help text about this feature to hook_install_tasks_alter() and also some warnings about why it should rarely be used, plus updated that hook's example code for the locale->language change.

I'm not sure we needed to change that terminology in this issue (since it was already pretty inconsistent before!) but the changes do look very good and the new terminology makes sense.

Also, while working on the above patches I discovered some nasty caching bugs in the install_profile_info() function. These are preexisting bugs, but given that this patch shuffles around the order of when that function gets called, it seems likely that it has an effect on that bug (whether it makes it better or worse I'm not sure).... So in case anyone notices any strange behavior with the wrong profile modules getting installed while testing this patch, that's probably why.

Since it's an unrelated bug (and in Drupal 7 also) I created a separate issue with a fix for it here: #1338384: install_profile_info() returns inconsisent data

Hi,

I executed the install in several browsers (IE7, IE8, IE9, Chrome and FF8) in a Windows 7 x64 With Zend server 5.5 (Apache 2.2.16 and PHP 5.3.8). My default language is Spanish international.

I download the drupal.8.x-dev and applied the #142 patch. I created 6 install.xx.po files. Three of them was valid (es, de, ar) and three wasn't (22, cr, es-ES)

In all browsers, the first time I run drupal, selects by default spanish language and shows 4 languages, english, العربية, deutsch, español. Without that patch (#142), shows me 7 language (three languages not valid like 22, es-ES and cr) with radio buttons.

If I change my default language to english or german, Drupal changes the default language too. (even in IE7 :) )

In my computer, this functionality works great.

I thought that standard.inc indeed has all the languages out there so we shouldn't need any other language, anyhow as you said we don't want to let's-fix-everything-while-here. So, I've left the standard languages check and added an else statement, this way we can easily in future get rid of this else.

#150: 1260716-150.patch queued for re-testing.

This is a good candidate for a short screencast to see it in action. An issue summary would be good to have though, there's been a solid design discussion going here and it has value to write up how this solution was reached. #142 has the latest screenshots and follow-ups are in @141 and 143. (But I'm keeping this rtbc regardless :-)

Yes very helpful, thank you.

I did *not* apply the patch and ran through all these scenarios myself, but still:

- There's some solid ground work being done here and it's clear how this is a good first chunk of work to commit.
- Nice how the different scenarios are handled, I see serious effort to make this as painless as possible for the user.
- It's clear what the follow-ups are and the important ones are opened.

Good work.

OK so the UX changes here look great, but right at the end of the patch there is this:

+ * You can also use this hook to modify the language selection task (which by
+ * default comes before the profile selection) but only if you also set the
+ * special 'custom_language_selection' property in your profile's .info file,
+ * as described in install_profile_info(). This will cause the installer to run
+ * the profile selection task before the language selection task, so that if
+ * the user does wind up choosing your profile, your modifications to the task
+ * will be able to take effect. Because this change of order results in a more
+ * difficult profile selection experience for non-English speakers, you should
+ * only do it if absolutely necessary.
+ *

There's several issues with this:

1. A hook that only gets implemented by one thing ever (and only executed once too) is not a hook. Especially when it's not implemented by a module. That's not the fault of this patch though.

2. This makes the already weird non-hook thing significantly weirder.

3. It is a cool idea to allow a profile to override the behaviour before the profile is selected (since you should not have more than one profile in your Drupal install that is trying to do this - although, what happens if you do?), but that is a new feature for install profiles, and doesn't belong in an issue called "Improve language onboarding user experience".

I realise this means we will lose one feature here, but that seems worth it to get the UX improvements in cleanly, and to have a separate (probably major?) follow-up issue to sort out the distro settings stuff, which is entangled with some other issues as well (Gabor directed me to one about customizing the theme).

Generally the screenshots here look /amazing/ and I did not see much to complain about with the patch.

Ultra-nitpick: "Profiles which" should be "Profiles that".

3. It is a cool idea to allow a profile to override the behaviour before the profile is selected (since you should not have more than one profile in your Drupal install that is trying to do this - although, what happens if you do?)

The patch works fine in that case, because it only does alterations after the profile is selected, not before. (Actually having the alterations take place before could only happen at the distro level, but that would be a new feature and is not part of this patch.)

but that is a new feature for install profiles, and doesn't belong in an issue called "Improve language onboarding user experience".

See above - I don't think this patch really adds a new feature. It does rework an existing feature (ability to alter or skip the language screen), but only because the patch makes the previous way of doing that impossible. The only alternative is, as you say, to remove the feature for now and hope it gets added back later.

I realise this means we will lose one feature here, but that seems worth it to get the UX improvements in cleanly, and to have a separate (probably major?) follow-up issue to sort out the distro settings stuff, which is entangled with some other issues as well (Gabor directed me to one about customizing the theme).

I don't think we should push it off without a clear plan for adding the missing feature back. The "distro settings" idea is interesting, but potentially requires infrastructure changes on drupal.org to be able to have distributions downloaded from there actually ship with these settings, etc. No one has figured out how that will work yet, so there's a good chance of it not happening. And it would be preferable not to lose this feature in Drupal 8 (ability to distribute a version of Drupal that is in a particular language from the very first screen, without having to write your own custom install script).

It's also not a one-to-one replacement (profile settings and distro settings aren't really the same thing), although given that you can choose to have your install profile on drupal.org downloaded as a distribution I guess that's not too bad.

Ultra-nitpick: "Profiles which" should be "Profiles that".

Ultra-ultra-nitpick: The dictionary actually says both are equally acceptable, although it's a very common misconception that they're not :)

http://oxforddictionaries.com/page/grammartipthatorwhich
http://dictionary.reference.com/browse/which (see "usage note" at the bottom)

I don't think we should push it off without a clear plan for adding the missing feature back.

I don't want to add the API oddity (alter hooks dependent on .info key) without at very least a plan to clean it up. Install profiles are already weird and fragile enough as it is.

I've also not seen any reviews of the API change here from people other than Gabor or David, so putting this back for more discussion, and tagging.

Fixing typo.

I found comments 118, 157 and 158 helpful to understanding the main issues under review here.

I find David's explanations in 158 convincing, and absent a better solution, I don't object to allowing profiles to use .info files as a way of changing the order of installer tasks. While this feels a bit unconventional, it seems reasonable to me that profiles and the installer define some conventions that differ from how we might deal with Drupal once it's actually installed.

I re-rolled 150, tweaking only the documentation change to hook_install_tasks_alter(), using language that feels slightly clearer to me. It can be difficult to describe/undertand sequence and modification of a sequence through language :).

absent a better solution

I'm not going to commit this without a commitment to finding a better solution somewhere. There are enough areas of confusion around install profiles at the moment, including unresolved major bugs in Drupal 7, that adding any more feels like just piling on.

I don't particularly object to dropping the feature if the usability improvement here is considered more important, but this doesn't feel like the issue to be adding new API patterns - so for me that needs to be split out either way (whether it blocks this issue or it's a follow-up to add back the feature that is being removed here).

The patch in #164 looks good for me, reviewed and tested it. Will move to #1351352: Distribution installation profiles are no longer able to override the early installer screens after committing this, to continue improving the distro settings.

OK thanks for the re-roll.

I don't see a follow-up issue for the test bot fixing linked from here? Could we open that before committing this so it doesn't get lost?

Thanks, #1352220: Drupal 8 changes installer language to take from GET langcode is what I was after.

Committed and pushed to 8.x. See you in #1351352: Distribution installation profiles are no longer able to override the early installer screens.

This will also need a change notification for the UI change and the fact the alter no longer works on the languages form.

No tests added with this?

Works for me. Still baffled why simpletest needs to change if this can't be tested, and if the current patch tests out ok. Continued conversation on that over in #1352220: Drupal 8 changes installer language to take from GET langcode

All right, as I've said, let's not derail this issue with this, I think we are way-way past David's 30min estimate for this problem.

Fair enough :) .... I still don't think we should be worrying too much about DX concerns for a hook that literally almost no one implements, especially when the existing DX is confusing anyway (it's a hook where everything passed to it can be altered but only some of those alterations have any effect). That said, if the feedback is that we need to work on the DX to get it committed, we can work on that in a followup issue.

I have created #1386394: Add back the ability for install profiles (or at least distros) to pre-select a language or modify the language-selection screen as the followup issue for that, since #1351352: Distribution installation profiles are no longer able to override the early installer screens (which was previously linked to above) is way too broad; it's an entirely new feature request with a lot more components to it than just adding back the single feature that was removed. However, for the time being, I've marked the first issue postponed on the second, since if the second issue does wind up getting some activity (it has none so far), it may turn out to be a better way to solve the problem.

Anyway, I'm looking at the patch that was committed here and we definitely have to reopen this. The consensus above was not to add any of the new .info file properties but rather to defer that discussion to the followup issue and remove the feature for now, right? However, it looks like the patch here actually did add them, just didn't add the code that actually made them do anything. So as far as I can see, the result is that install profiles in D8 have two new info file properties ('langcode' and 'custom_language_selection') that do absolutely nothing when you try to use them...

Here's a followup patch to remove the .info file properties that were introduced but that don't do anything, as well as some other minor cleanup.

Hopefully this is a really quick RTBC + commit, so no need to make a separate issue. We'll see :)

EDIT: Whoops, reported an issue that was already mentioned above. (Forgive me for not skimming the entire thread before posting.)

Okay, and functionality-wise, this doesn't seem to even work. Is there still more to be done? I select Japanese and click "Save and continue," and the next screen is still in English. The st() function still has:

    if (isset($install_state['parameters']['profile']) && isset($install_state['parameters']['langcode'])) {

…so it looks like it's still not going to do anything until a profile has been selected. Yet even if I select a profile, everything is still in English on the requirements screen. That's a step back from D7!

Am I missing something? Should I try to fix this? Anyone familiar with this problem, feel free to ping me (as Albright) on IRC.

Gábor, my original problem in #179 is that the form control starts out as a drop-down menu and then turns into a select box for no reason that I can discern, but it turns out you mention it in #155. I still think that's incredibly strange, but I guess it's not the most important issue here.

As for filing a bug with st(), before I do that, I want to double-check and make sure that I've installed the language file correctly and stuff. As I'm new to multi-lingual sites and definitely new to D8 (and D7, for that matter), I'm not sure of that yet. I again invite anyone who may be interested in helping me out with this to ping me on IRC.

Okay, I've patched two issues I've found: #1392174: install_find_translation_files() breaks if $langcode is passed and #1392192: st() still requires profile to be selected before translating. With these two apply, the names and descriptions of installation profiles are untranslated, but everything else is translated. That's correct behavior, yes?

OK, committed/pushed the follow-up.

Sorry, but I'm going to have to switch gears and look back at my current work for the moment. The whole reason I got on this tangent was to see if there was something here that could be backported to D7, even as a kitten-killing hack, but that's not looking like a promising route to take, so back to D7 land I go. But hopefully others will be able to continue where I left off.