This is a task broken out of #1260716: Improve language onboarding user experience to solve remaining issues once the initial improvement is in.

Problem/Motivation

This is the first screen people see. Lets improve the ui.
The goals of this issue is to create a better way to select your language in the initial installation screen. The current situation is:

(updated images of current from #22)

orig orig http://drupal.org/files/D8Language.png

Proposed resolution

The proposed solution is to create a textbox above the select box that jumps to the language typed (or filter to the language typed).

(originally proposed: http://drupal.org/files/installer-01-language.png )

agreement in this issue on what to do and not to do:

  • label on form element (see #14)
  • no percentage
  • leave druplicon in (to be handled in another issue, maybe #1337554 or an off shoot of that)
  • don't switch in and out of rtl here, make next screens use rtl if an rtl lang is selected (Example)
  • dont hide the list of steps on the first screen (if desired make a follow-up issue, and link it here)
  • use a select box with a search possibility

Remaining tasks

  1. From #1260716: Improve language onboarding user experience, it seemed like we agree we need to have that textbox for the list of languages but we did not (yet) agree on whether it should filter or jump.
  2. decide on how to implement (overall look at comments from #27 on):

User interface changes

It would add a new interface element to core, that will be used for the installation language selection screen.

API changes

No api changes anticipated.

Files: 
CommentFileSizeAuthor
#70 Drop_Down.png39.63 KBjibran
#70 Choose language Drupal.png61.85 KBjibran
#68 core-js-install-select-1337628-68.patch5.82 KBnod_
PASSED: [[SimpleTest]]: [MySQL] 59,051 pass(es). View
#59 ChooseLanguagePatch.png144.06 KBGábor Hojtsy
#50 langcode-search-and-autoselect-1337628-50.patch4.17 KBsxnc
FAILED: [[SimpleTest]]: [MySQL] 58,600 pass(es), 0 fail(s), and 1 exception(s). View
#22 InstallerSelect.png55.32 KBGábor Hojtsy
#22 InstallerLanguages.png152.19 KBGábor Hojtsy
#6 Choose language-current.png42.01 KByoroy
#6 Choose language-cleaner.png33.42 KByoroy

Comments

Gábor Hojtsy’s picture

Status: Active » Postponed
Bojhan’s picture

Issue summary: View changes

Updated issue summary.

Gábor Hojtsy’s picture

As per discussion with Bojhan, we should discuss whether we need these and *then* implement.

good_man’s picture

1. I didn't find any reason for the percentage except encouraging translation teams to continue working towards 100%. The user won't give a dime for it, and it's a very tricky one for non-technical people where you have to tell them that this percentage is only core, and it doesn't represent frontend/backend (where many translations have done the frontend part very well). So 1 for me is unnecessary detail.

2. Hiding it is a good thing if we translate the description field "The language you choose ...", in this way, we make sure every person who doesn't understand a bit of English can find his way from the first screen.

3. If we switch to RTL. Do we need to stick with this RTL screen for the whole installer? also, we might need to see it in-action, to make sure it won't be very awful effect.

Other points that might need a little discussion:
- The user can write in the textbox the native language name or the English one? (e.g. Arabic, or, العربية).
- Can user select with the mouse from the selectbox?

Gábor Hojtsy’s picture

The textbox should work with the names in the select list. The whole installer will be in that language from then, so it is reasonable to expect people to know the native name of the language they want to use. Regarding RTL, the installer is already RTL from the second screen if you choose an RTL language, isn't it? (It is supposed to be). The question for RTL is whether to switch the direction immediately on the fly when you choose such a language. So if you choose an LTR language, then an RTL one and then again an LTR one, before you submit the form, the page direction would always adjust. And finnaly, yes, the original intention was to change the UI label language to the chosen language as well, like direction, on the fly. These might be more nifty than practical though. If I accidentaly click on a language that I dont understand, it might not be evident how to get out of that :) Oh and yeah, the mouse should work on the list :)

Gábor Hojtsy’s picture

FYI opened #1344540: Extend language list to include direction and percentage of featured project for the localization server to add more needed information to the remotely provided language list (namely percentage is interesting for this issue, which we might either display or use to hide some of the languages or end up not doing anything with it I guess). The language list will be synced to local data store with #568986: Dynamically update standard language list from localization server (but it is somewhat in the future waiting on infrastructure from CMI).

yoroy’s picture

#1260716: Improve language onboarding user experience was committed, hooray.

What it looks like now

current language selection screen

A quick clean-up

remove druplicon, float 'learn how to' link next to the select list

So much too win in clarity and focus if we remove Druplicon here: the task list is much closer to the actual form elements.

I put the 'Learn how to install in other languages' link on the same line with the select list to make it a bit less prominent.

Anyway, mostly out of scope for this specific issue of course, but some initial thoughts about this screen to get discussion started.

yoroy’s picture

Status: Postponed » Active

doh

Bojhan’s picture

Priority: Normal » Major

I think the main discussion is how to implement the idea in the top in accessible way. Removing or replacing the branding element, such as the Druplicon has a other issue (I cant seem to find).

I am going to mark this major, because this screen is seen by everyone and is currently its interaction hard to use. This is the standard we used in D7 too.

good_man’s picture

@yoro: could you take a screenshot with multiple languages and the help text inline? I think it'll be better if multiple languages appear on top of the help text, not inline with it, however it's good for one language as in your screenshot.

Gábor Hojtsy’s picture

@good_man: the help text does not show if there are multiple languages, it assumes you already figured out how to do it (otherwise there would be only one language :).

@yoroy: For the installer branding or unbranding: #1337554: Develop and use separate branding for the installer (that is where the Druplicon question would go, although that opened on a way higher note, it could really go anywhere). Let's keep this issue for the language screen(s) :)

yoroy’s picture

I know iI know. Just pointing out what you're competing with on this page. Carry on :)

good_man’s picture

Now I need a help text for me :S anyhow it's looking better.

webchick’s picture

Category: task » feature

This sounds like a feature request rather than a task. If there's a reason fixing this should hold up other D8 development, please specify.

jenlampton’s picture

Can we please put a label on the form element? See #1356702: Drupal installation needs UX pass for why form elements with no labels are confusing :)

jenlampton’s picture

Category: feature » task
Issue tags: +Usability

Er, I think UX is a pretty good reason it should hold up development. Especially on the *very first* thing people see having to do with using Drupal.
(Please put it back if I'm wrong) :)

Kristen Pol’s picture

I agree with Jen that it is good to have a label above the field for maximum clarity.

As for the #1-3:

1) I personally don't like the percent translated part... I think it's confusing and makes things more cluttered.

2) showing less steps (if accurate) is good so you feel like you are going to be done fast!

3) switching to RTL automatically makes sense to me

Kristen

clemens.tolboom’s picture

XPost from #568986: Dynamically update standard language list from localization server
Just a side note: while working on #1189184: Make gettext .po generation its own abstracted functionality I was tempted to allow _all_ available languages to try download the install-langcode.po when selected as the POFileReader accepts an URI to download.
(POFileWriter could write it to public://translations/ and POMemoryWriter facilitates the installer to read it)

Bojhan’s picture

This is currently held up on is implementing, download languages from locale.drupal.org

sun’s picture

Category: task » feature
Gábor Hojtsy’s picture

I think this is more postponed on #1627006: Collect project information for translation update and the actual download of files. Once we can download translations for a language, we can display all languages in the installer. Then if we cannot download a file in the installer, we can still show the installer in English and fall back to that there. So this can only happen later once it makes sense to display a full language list. Currently, it would just add that language and display the installer in English anyway which is not the experience we are looking at.

Gábor Hojtsy’s picture

Status: Active » Postponed
Gábor Hojtsy’s picture

Category: feature » task
Priority: Major » Normal
Status: Postponed » Active
Issue tags: +language-base
FileSize
152.19 KB
55.32 KB

And now .... #1848490: Import translations automatically during installation landed, so the installer now has a real long language select list. So this should be entirely possible. The current UX following that patch is as follows:

1. When I hit the installer, the browser language detection feature figures out I want Hungarian (displayed in it's native name as Magyar). The description explains what is going to happen and how to opt out (the opt-out information was deemed important due to the kind-of phone-home nature of the feature downloading a file):

InstallerSelect.png

2. If I want a different language, the select box is HUGE, it contains all supported languages that Drupal knows about:

InstallerLanguages.png

It uses the native name of the languages as proposed in the OP.

This is the current behaviour. Now I think we need to consolidate feedback and figure out what kind of design do we want (if the current needs changes made).

Gábor Hojtsy’s picture

Priority: Normal » Major

@Bojhan points out this is the first screen ever people see of Drupal so it should not be down from major.

Bojhan’s picture

I think the design we want is in the OP, its a select box with a search possibility.

webchick’s picture

Wait. Before we make this a threshold-blocking thing, can you explain what's wrong with a select box? I get that there are a lot of options in it, but seems like this is a simple enhancement?

attiks’s picture

Looking at the screenshots, looks like you want to use http://harvesthq.github.com/chosen/ it will transform the selectbox to something fancy

webchick’s picture

Priority: Major » Normal

I'm reducing to normal until/unless the case can be made for why adding UX chrome here is worth blocking other peoples' stuff.

This issue is going to be a nightmare to close, IMO, trying to find one of those libraries that's accessible enough for our needs. Also has to work on mobile, don't forget.

nod_’s picture

Before trying out fancy things let's have a look at #1593964: Allow FAPI usage of the datalist element.

Gábor Hojtsy’s picture

@attiks: there has been lots of discussions about Chosen on #1260716: Improve language onboarding user experience where this issue was originated from. In short, it would need Chosen in core which more importantly necessitates all kinds of accessibility work upstream (as per Everett):

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

Also we want to have a search box with the select list both shown right away, not requiring another click to get into it as is implemented in Chosen.

@nod_: how is that related? Our use case here is we have a fixed set of options. It is not possible to enter an option that is not available in the set. We just want to make it easier to navigate, since we have 100+ options all the time. We already pre-select a language based on your browser-preference (if any), so that might be a good choice and you might not touch this widget at all, but if you need to, we want to make it easier to find the option you are looking for. I'm not sure how datalist would help us (although I just heard first about datalist really).

attiks’s picture

#27
My personal problem with chosen is that it relies on jQuery, I think we can write something similar without having to rely on jQuery.

#28
The problem with datalist is that the user has no clue it is also a select list, in Chrome/FF I have to double click to show me the list of options, and it also allows people to enter something else, which in this case doesn't really makes sense.

PS: Tested on http://adactio.s3.amazonaws.com/misc/datalist.html

sun’s picture

Gábor Hojtsy’s picture

@sun: looking at the select2 demo at http://ivaynberg.github.com/select2/ it does not seem to have an example of a layout we want to achieve here. Am I missing something?

RobW’s picture

Switching between LtR and RtL languages on the fly would betotally disorientating, IMO. If it is being seriously considered it should be prototyped and tested, to make sure that the welcoming experience we're trying to provide doesn't become a seizure inducing one despite good intentions.

I think there's some use to the percentage markers. I wouldn't want to see them all, but maybe showing those under a certain percentage would help manage expectations, which is especially important for first time users.

YesCT’s picture

I think we should do the percentage in a different issue. I have some thoughts, but I don't think that needs to hold this up.
Related: another thing for another issue might be to show with the language name in it's language, is the name of the language in the browser language. That an edge thing and not needed here. No action on that I need to think about it some more.

nod_’s picture

that should work out let's note add yet anthother js lib: http://jqueryui.com/autocomplete/#combobox

Gábor Hojtsy’s picture

I guess we can keep brainstorming JS libs for however long we want. There are probably more released all the time. So not sure why we should postpone this even more?!

Gábor Hojtsy’s picture

Issue summary: View changes

Swap images, expand on percentages text

YesCT’s picture

Issue summary: View changes

updated issue summary with what is agreed to cover or not cover in this issue and remaining tasks: decide to filter or jump, decide what lib to use.

YesCT’s picture

Issue summary: View changes

Updated issue summary lettered the implementations with no agreement

YesCT’s picture

Issue summary: View changes

Updated issue summary, small grammar to improve clarity

YesCT’s picture

I updated the issue summary with the current screen shots. took out the original suggestion since we have changed what this issue proposed solution is, but left a link to it.

remaining tasks are updated, but quickly are: decide if typing to search would filter or just jump to, and decide how to implement. a summary in the issue summary shows previous suggestions that wont work, and one proposal not yet evaluated.

Gábor Hojtsy’s picture

All right, we are definitely past feature freeze. Are new JS libraries still being added to core?

Gábor Hojtsy’s picture

After a month and a half more, still want to add even more JS libs to core? Hm? I'd love to get this done, but we can keep discussing what kind of monster JS lib to put into core just for this only so long...

Sutharsan’s picture

There is work in progress to get jQuery autocomplete in core: #675446: Use jQuery UI Autocomplete. In #1271622: Seek a better autocomplete replacement for core (jQuery TokenInput / Select2 / Typeahead.js by Twitter) Chosen, Select2 and Typeahead are not considered for D8 due to existing accessibility issues. We might have a change if we can use jQuery autocomplete for this language selection.

klonos’s picture

If it weren't for its accessibility issues, having Chosen (or something like it) in place would make it easier later if we decide to implement #2010008: Multilingual site installation, Step #1: Allow selecting more than one language during installation..

alexweber’s picture

Looks like jQuery UI autocomplete is the winner here even if it isn't the best implementation it's still better than nothing and is already in core afaik.

klonos’s picture

Yeah, I realize that there's no time and that it'd be best to go with something already in core. I merely tried to emphasize that along the way we'll likely need a solution that combines autocomplete and multiple selection.

Gábor Hojtsy’s picture

The design in https://drupal.org/files/installer-01-language.png wanted to highlight the diversity of the languages available. I went to jQuery UI's demo page for the autocomplete widget and did not find any combination of settings where this would be possible.

alexweber’s picture

The custom data demo actually comes pretty close I think... we might not be able to make the language name bold but we can definitely add the extra description indicating completeness %... and if we wanted to really get cute we could add flag icons too :)

Gábor Hojtsy’s picture

I don't think the custom data demo demonstrates what we intended with the design. We DID NOT intend to filter the language list down to the thing typed. In that case, when Drupal picks a suggested language for you based on your browser, you'll not see there are any other options whatsoever. Without manually cleaning out a text field (in which case in the custom data demo, you don't see any of the options even). We want to highlight the numerous languages available better. Neither state of the custom data demo does that.

alexweber’s picture

Good call, back to the drawing board...

Paracetamol’s picture

Assigned: sxnc » Unassigned
Status: Needs work » Active
Issue tags: -sprint

Sifting through some admin modules I was recalling this thread looking at the technique of the Better Select module.

That's – albeit not as pretty as Chosen and the likes – a pretty intuitive way to work through long lists – and easy to implement as well. You could even use radio buttons and still have a better user experience then with those mega select dropdowns.

Accessibility should be doable – especially comparing it to the more fancy solutions mentioned above. The only thing that came to my mind is the clumsiness of using this on a touch device, as this is not a standad form function and involves framed scrolling. Some sort of switch (to a standard select/multiselect element?) for touch devices and accessibility could be a solution.

sxnc’s picture

Assigned: Unassigned » sxnc
sxnc’s picture

Status: Active » Needs review
FileSize
4.17 KB
FAILED: [[SimpleTest]]: [MySQL] 58,600 pass(es), 0 fail(s), and 1 exception(s). View

Olright, here is a patch that will add a new textfield and increase the selectlist size to 8 elements as shown here: https://drupal.org/files/installer-01-language.png

When searched, the list will remain full (its not filtered) but the option matching the search string the closest will be selected.

nod_’s picture

Status: Needs review » Needs work

Few things

when declaring and assigning values, one var per line.
$select.find('option') is looked for every keyup. That should be selected and cached out of the event handler.
replacing string.match(regex) with regex.test(string)

Beside that, i'm happy with it.

yoroy’s picture

Status: Needs work » Needs review

I'm sceptical about how useful this is. The additional languages shown are there because they alphabetically follow English, which is not relevant. I'll have to try out the patch first but I suspect this change makes the form look more as if you *have* to choose a language before you can continue. Don't make me think! :-)

In related news, I opened #2099577: Follow-up: First installer page has initially needless description for how translations are handled

nod_’s picture

Status: Needs review » Needs work

try it out, the default language is prefilled and preselected.

Gábor Hojtsy’s picture

@yoroy: I admit we made a mistake to not make it clear for some time the target of this issue is, but it was there for the first year and a half of this issue being open: https://drupal.org/node/1337628/revisions/1744490/view (until it was removed for some reason later on). I certainly would not ask people to implement this if I sense it is not UX-accepted. I sensed that Bojhan asked us to implement this to spec, eg. this year January he wrote (above): "I think the design we want is in the OP, its a select box with a search possibility." (that design was later removed in June for some reason).

So looks like you don't agree with him. Discuss!

sxnc’s picture

@yoroy: what if the actively selected language would look more prominent like in the styleguide: https://groups.drupal.org/node/283223#Dropdowns_and_Popovers

This way i think the user would be better informed that there is a "selection" and that he doesnt necessarily has to change it. Maybe the search box can also be changed so it looks a bit more "connected" to the list itself.

yoroy’s picture

I guess I'm not sure what this design means to portray:

Are those languages auto-complete suggestions or an always-on select box?

Gábor Hojtsy’s picture

It is designed to be an always on select box. Otherwise, it would not show up by default (and no select box would show?) because you have *some* language selected by default, either English or some other language. So if the textfield is there and filled in by default, then no other language would be shown. Which is basically how Chosen, etc. work.

Gábor Hojtsy’s picture

@yoroy: see this design as well for an in-use example: https://drupal.org/files/03_Language_rtl.jpg (ignore the % data, that will not be in Drupal 8 core).

Gábor Hojtsy’s picture

FileSize
144.06 KB

Screenshot of the patch from #50 as it appears *without any user interaction* for me (picks Hungarian based on my browser preferences):

ChooseLanguagePatch.png

Gábor Hojtsy’s picture

Issue tags: +sprint
Bojhan’s picture

Assigned: Unassigned » sxnc
Status: Active » Needs work
Issue tags: +sprint

For the past few years we have been advocating using "standard select" of http://harvesthq.github.io/chosen/ for interactions like this. Although we know this is a little hard to implement, there are fewer tradeoffs. I remember agreeing to that, I probably interpreted Kevin's design wrong.

The design as proposed here and I agree with yoroy, introduces two interactions to get to the same thing (which will probably cause confusion) and exposes a very big box that is not relevant to most users (preselected using browser defaults).

I hope that the great people who have been working on this, could implement that new direction. It looks like this would greatly enhance the first page of Drupal :)

Gábor Hojtsy’s picture

Status: Needs work » Active
Issue tags: -sprint

@Bojhan, @yoroy: I think its pretty unfortunate that based on your above feedback we thought that Kevin's design is "approved to implement". It clearly showed a textarea which was used to jump around in a multiline but single select box. Looks like the multiline but single select box in itself is bad to display on this page and should only be displayed in interactions when the user opens it up.

@sxnc: I'd personally like to say sorry that you worked half a day on this and it possibly needs to be thrown out entirely :/

So basically the single item version of chosen is the desired interaction then.

1. The language selector will be a select box including all available languages.
2. If the server pre-selects a language, that will be preselected and show up as the selected option in the single language select box.
3. If the server did not pre-select a language (== it preselects English), then English will be preselected.
4. ONLY IF the select box is opened, a textfield will show which allows to filter down the list.
5. When the select box is opened up, the previous filtering is NOT present but the previous selection is maintained.

Note that this basically explains the chosen single item widget as far as I understand it, and I'm looking for confirmation of that desired behaviour before someone would continue working on this.

Moving off of the sprint, since the current approach is clearly a dead end. Also, given that the proposed interaction is more or less already what browsers do (you can open the select box and type-ahead which will jump to the right option), I'm not sure this should be a priority for us to resolve then(?). The desired solution is basically a more exposed type-ahead feature for this select box to make the existing browser feature more prominent and accessible to those who don't know that feature exists.

Also since #1271622: Seek a better autocomplete replacement for core (jQuery TokenInput / Select2 / Typeahead.js by Twitter) was postponed to Drupal 9, not sure we could use a 3rd party library for this and custom coding something **just for this installer screen** looks like it would be a problem if we need to replicate what is already available in 3rd party libraries. And since they could not pull off being accessible, I'm not sure how would we have the expertise for it.

In short I'm not sure if there is a strong point in solving this with the new proposed way and even then in-house with our own custom JS.

nod_’s picture

Issue tags: +JavaScript

and missing tag.

Bojhan’s picture

From my point of view is there is a very big gap between the experience offered through Chosen and that of the native browser. It should be a priority for you to resolve, because the initial UX of this screen was not as bad - because we only offered a few choices. So you introduced a UX regression.

Will it be hard to solve? Yes, thats why we wanted it to be part of the initial patch instead of a followup (we knew it would be hard). When its a followup there are always priorities that go over fine-tuning the UX, and that is also why D8 in many area's gotten worse from a UX perspective, most hard UX issues where pushed to followups. Given that this is the first screen people see, I'd advocate for still making it part of your effort - making it really usable will be a pleasant start of the Drupal experience.

Gábor Hojtsy’s picture

From my point of view, we did what we could to implement the spec, so I dont think we are in the wrong here in any way.

Are you suggesting then we custom code a Chosen type solution from scratch given there are no accessible solutions found on the market?

Bojhan’s picture

@Gábor I find this discussion rather silly. You can implement the spec, and make something that is hard to use. Our end-goal is making a highly usable system, its not reaching spec.

I am suggesting we do something that takes work. I am also arguing why it is important, and how it will be a usable solution.

Gábor Hojtsy’s picture

@Bojhan: realistically what I see is our accessibility and JS folks looked at all the libraries that they could find on the whole internet and did not find any that would be accessible and good to include in Drupal 8 core. If the whole internet could not produce one useful library, expecting that we'll write our own very accessible solution may be daydreaming. We have a very small pool of JS experts in Drupal and I did not find any of them interested in this so far, eg. @nod_ said yesterday on IRC he does not see the point of building such a library ourselves.

Moved #1271622-44: Seek a better autocomplete replacement for core (jQuery TokenInput / Select2 / Typeahead.js by Twitter) back to Drupal 8 with a comment referring to your preference to definitely solve this in Drupal 8.

nod_’s picture

Status: Active » Needs review
FileSize
5.82 KB
PASSED: [[SimpleTest]]: [MySQL] 59,051 pass(es). View

as long as contrib doesn't use it too much (who am i kidding, of course they would) here is a first stab. The styling is all broken and the interraction isn't great either but it's a start.

Using http://jqueryui.com/autocomplete/#combobox

jQuery autocomplete is accessible so this ought to work to some extend.

nod_’s picture

I think the only way we can get that done at this point is blocking a day or two of sprint with me/jesse/Bojhan to be able to deal with JS/CSS/a11y/UX issues on the spot and not over 6 months and 300+ comments.

jibran’s picture

FileSize
61.85 KB
39.63 KB

Screen shots.

Choose language   Drupal.png

Drop Down

Gábor Hojtsy’s picture

Thanks for the screenshot! What we need is this to appear as a select box by default and only show the input if the select is opened down (and still show all the options in a scrollable list in that case). At least based on the above description of how Chosen works. I tweeted this call for frontend developers to help: https://twitter.com/gaborhojtsy/status/393052584321486848

I cannot make any promises on behalf of Jesse, she gets time for some critical/major frontend issues to help get Drupal 8 out of the door ATM. This would need to be significantly increased in priority for that to happen as part of her job. Otherwise if she has time, that would be great obviously :)

Gábor Hojtsy’s picture

Status: Needs review » Needs work
andypost’s picture

Suppose better to wait for #675446: Use jQuery UI Autocomplete and make it on top of JQ

jessebeach’s picture

I think a browser-native select box works fine here. The list is long, but it's something that has to be interacted with exactly once in the lifespan of a site. The browser-native select box already has type-ahead behaviors. I'd vote we drop this task.

jibran’s picture

+1 to what @jessebeach said.

Gábor Hojtsy’s picture

Assigned: sxnc » Unassigned

Unassigned from sxnc to reflect reality.

Gábor Hojtsy’s picture

Issue summary: View changes

Updated issue summary, fixed missing closing list html

nod_’s picture

Using select2 for this works pretty well #2346973: Replace jQuery UI autocomplete with Select2

Dom.’s picture

Something like : #2442699: UX improvment on autocompletion would also make the deal, with the multifields possibly displaying the language name in english, the language name in it's own language and a percentage of expected translation for instance.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.