#1776166: Improve default language negotiation adds the functionality of the feature. This is a follow-up issue to improve the process, ui and help text so that people will know when to change the site default language and when to change the default language in the detection and selection tab.

Possibilities are:

A) to take the change default language off of admin/config/region/language and put it on it's own page. There, help text can exist that explains that changing the site default language is something to be done while site building and not something to be changes on a site that is already in use. Changing the default language in the detection and selection tab is the best practice on a working site. There can also be text there to explain in what rare circumstances the site default language should be changed on a working site.

B) add help text to admin/config/region/language that explains not to change the default on a working site and to use the detection and selection tab instead.

Note: "improving" the default language change process will make it harder to change the site default language. But that is what is needed, since we dont want it to be easy to change the site default language on a working site.

Files: 
CommentFileSizeAuthor
#46 selected-language-row-2013-01-31_1129.png18.68 KBYesCT
#46 configure-2013-01-31_1139.png55.17 KBYesCT
#46 1803638-default-language-ui-change-45.patch20.61 KBYesCT
PASSED: [[SimpleTest]]: [MySQL] 49,274 pass(es). View
#46 interdiff-41-45.txt1.93 KBYesCT
#44 before-enable-language-2013-01-31_1115.png57.15 KBYesCT
#44 language-help-2013-01-31_1122.png80.25 KBYesCT
#41 1803638-default-language-ui-change-41.patch20.47 KBYesCT
FAILED: [[SimpleTest]]: [MySQL] 48,571 pass(es), 2 fail(s), and 3 exception(s). View
#41 interdiff-32-41.txt1.34 KBYesCT
#35 region-settings.png21.53 KBvijaycs85
#35 language-list.png30.88 KBvijaycs85
#32 1803638-default-language-ui-change-32.patch20.38 KBvijaycs85
PASSED: [[SimpleTest]]: [MySQL] 48,677 pass(es). View
#32 1803638-diff-21-32.txt4.02 KBvijaycs85
#21 1803638-default-language-ui-change-21.patch18.46 KBvijaycs85
PASSED: [[SimpleTest]]: [MySQL] 49,294 pass(es). View
#21 1803638-19-21.txt4.75 KBvijaycs85
#19 1803638-default-language-ui-change-19.patch15.67 KBvijaycs85
FAILED: [[SimpleTest]]: [MySQL] 49,235 pass(es), 47 fail(s), and 3 exception(s). View
#19 1803638-diff-16-19.txt10.18 KBvijaycs85
#16 1803638-default-language-ui-change-16.patch6.44 KBvijaycs85
FAILED: [[SimpleTest]]: [MySQL] 49,256 pass(es), 40 fail(s), and 1 exception(s). View
#16 1803638-diff-13-16.txt3.54 KBvijaycs85
#12 1803638-default-language-ui-change-12.patch4.17 KBvijaycs85
FAILED: [[SimpleTest]]: [MySQL] 49,311 pass(es), 45 fail(s), and 1 exception(s). View

Comments

YesCT’s picture

Title: Improve default language change process (ui and help text) » Improve default language change process (ui and help text) [a follow-up]

This issue can wait to get attention until after the feature freeze so we can focus our efforts on getting new features into D8.

YesCT’s picture

Issue tags: +D8MI, +language-base

The following is mostly cut and paste from irc.

I think because people experienced with multi-lingual sites are so familiar with the pit fall of changing the default site language on a working site, it seems obvious to them the need for the site default in the language detection and selection tab.

Someone else coming to that admin page (or to the issue which as the feature) is confused as to why that feature is needed.

Thoughts: After a site is set up, and working, and later the language of the site needs to be changed, the issue says it's bad to change the site default language.

I'm not sure how someone looking at admin/config/region/language will know to click on the detection and selection tab instead of just change the default there at the first screen.

admin/config/region/language seems to do a bunch of stuff. allows adding languages, reorders them (and the order effects the order they are other places in the ui?), it has links to interface translation, etc. It also allows changing of the default.

But after a site is set up and has been in use, most of those other things are still fine to do. but changing the default is not (not best practice).

But it might be that the site default does need to be changed there, in special circumstances… I think it would help to say what those situations are.

Maybe it's clear to those who have managed a multilingual site and had changed the site default and suffered the reprocusions.

But I think we can put some words in there so that someone can know without having gone through that pain to realize what the best practice is.

Also, I wonder if maybe setting the default could be moved off of that screen somehow.

YesCT’s picture

Here (reusing from the other issue) is a screen shot showing admin/config/region/language
This is what either needs some caution words to not change the default language, or needs to have the ability to change the site default language moved off of this screen an to another... or some other brilliant solution to the problem of people not knowing that the best practice is to click on the detection and selection tab and change the fallback language there.
config-lang-2012-09-14_2249.png

Gábor Hojtsy’s picture

I agree this would be important to fix in Drupal 8. We should be able to return here after December 1st.

YesCT’s picture

Issue tags: +medium, +needs initial patch

I think this is ready to look at again, available for anyone to jump into, and it's harder than novice.

lets start with an initial patch to do proposal A (put changing the default language somewhere else)

andypost’s picture

I'd suggest to add adaptive classes to columns by their priority
Also there's a generic implementation #1855402: Add generic weighting (tabledrag) support for config entities (DraggableListController) for sort-forms of config entities so this functionality could be extracted to base implementation.
Probably better to fix element #type=table to allow similar build/render structure to have ability remove "draggablility" whan table contains only one row

YesCT’s picture

@andypost Thanks. The suggestions and links to other issues is really helpful.

I think this issue is about just moving the default language setting.
So we should have another (yeah, I know, a lot of separate issues) for refactoring this table with the element #type=table recommendation. Unless I'm missing something ...

andypost’s picture

@YesCT yes, the same patter we have in core for selection of default contact category #599770: Clean up the contact forms listing UI: Allow to set the default category and weights on the listing page

vijaycs85’s picture

Status: Active » Needs review
FileSize
28.76 KB
60.27 KB

Hi @YesCT,

I have tried two things here from my understanding of this defect.

1. Removed default language selection from admin/config/regional/language, as per below screenshot

language list page

2. Adding default language as part of site information with description.

site configuration with language settings.

Is it OK to proceed with patch for this approach?

YesCT’s picture

Issue tags: +Needs usability review

Hmm. I had not considered making it part of another page.

What advantages do you see of putting it with site information?

I can think of one: when would someone be setting the default language? By just the need for this issue, and the very related issue: #1776166: Improve default language negotiation, the default language should be set or changed during site building and initial config. Not later on a running site. So that might support putting it with out things that are typically done during initial configuration.

Can we think of examples in core of any similar situation that establishes a pattern? ... Well I guess many settings are in site information, so that is a pattern. Maybe my question should be: Can we think of examples in core of patterns different than that: of a situation where a single config setting is in a page by itself and not on one of the Configuration pages?

Added "needs usability review" tag to see if we can get some advice on how to "hide" a setting.

Feedback on the actual screenshots and proposal:
Re-reading the issue summary, I see proposal options A (remove default column) and B (add helptext warning) have been implemented. B might not be needed if A is done well. So since you have done A, we might be able to skip B (help text) or be more minimal with the help text.

Lets write the helptext as if someone does not know we moved the setting. So we can mention the warning not to change the default only where it needs to be mentioned: wherever the setting end up (site information) and (maybe with a bit different wording) on the detection and selection page. On the language settings page we can probably just point to the detection and selection tab.

In general this looks on track. And a patch would be ok to start on.

Xano’s picture

I suggest putting the default language setting on the same page as the default country setting. Country and language belong together conceptually, as together they form a locale identifier.

vijaycs85’s picture

FileSize
4.17 KB
FAILED: [[SimpleTest]]: [MySQL] 49,311 pass(es), 45 fail(s), and 1 exception(s). View
29.25 KB
25.23 KB

Thanks Xano. Added changes in this patch. Attached screenshot of changes in language list page and region settings page after this patch.

Language list

Regional settings

Status: Needs review » Needs work
Issue tags: -Needs usability review, -D8MI, -language-base, -medium, -needs initial patch

The last submitted patch, 1803638-default-language-ui-change-12.patch, failed testing.

YesCT’s picture

Status: Needs work » Needs review
Issue tags: +Needs usability review, +D8MI, +language-base, +medium, +needs initial patch
Xano’s picture

Status: Needs review » Needs work

The language setting is just as much part of the locale as the country selector, so if they're in a fieldset, they should be in the same one.

vijaycs85’s picture

Status: Needs review » Needs work
FileSize
7.25 KB
3.54 KB
6.44 KB
FAILED: [[SimpleTest]]: [MySQL] 49,256 pass(es), 40 fail(s), and 1 exception(s). View

patch in #12 should fail as the test cases not updated to reflect default language location change. Updating related test cases and review comment in #15 and region settings look like this:

Locale settings

vijaycs85’s picture

Status: Needs work » Needs review

The last submitted patch, 1803638-default-language-ui-change-16.patch, failed testing.

vijaycs85’s picture

Status: Needs work » Needs review
FileSize
10.18 KB
15.67 KB
FAILED: [[SimpleTest]]: [MySQL] 49,235 pass(es), 47 fail(s), and 3 exception(s). View

Updating test cases in other groups that are getting affected by this change.

Status: Needs review » Needs work

The last submitted patch, 1803638-default-language-ui-change-19.patch, failed testing.

vijaycs85’s picture

Status: Needs work » Needs review
FileSize
4.75 KB
18.46 KB
PASSED: [[SimpleTest]]: [MySQL] 49,294 pass(es). View

Updating test user access to visit admin/config/regional/settings.

Status: Needs review » Needs work
Issue tags: -Needs usability review, -D8MI, -language-base, -medium, -needs initial patch

The last submitted patch, 1803638-default-language-ui-change-21.patch, failed testing.

vijaycs85’s picture

Status: Needs work » Needs review
Issue tags: +Needs usability review, +D8MI, +language-base, +medium, +needs initial patch
Gábor Hojtsy’s picture

First, looking at the screenshots, the language list header labels are off, the operations header is above the interface translation stats and vice versa. Other than that:

+++ b/core/modules/language/language.moduleundefined
@@ -24,7 +24,7 @@ function language_help($path, $arg) {
+      return '<p>' . t('With multiple languages enabled, registered users may select their preferred language and authors can assign a specific language to content. Default language can be changed at  <a href="@region-settings">Regional settings</a> page.', array('@region-settings' => url('admin/config/regional/settings'))) . '</p>';

"at the Regional settings page" IMHO (add "the") - also avoid double space before tag.

+++ b/core/modules/language/language.moduleundefined
@@ -878,3 +878,34 @@ function language_update_locked_weights() {
+    '#description' => t('It is not recommended to change the default language of a working site, use default language in the <a href="@language-detection">detection and selection</a> page instead.', array('@language-detection' => url('admin/config/regional/language/detection'))),

I'd reword this to something like:

"It is not recommended to change the default language on a working site. Use the 'Selected language' setting on the detection and selection page to change the fallback language for language selection."

Something along these lines. The detection and selection page does not have a *default* language setting really.

Also, I'm tempted to add a "You can add more languages at ..." but this text is already long enough, so we should probably skip that :)

I'm a little bit torn on this one, it looks to be at the right place but none of the other language settings are here.

Also I guess we should cross-link this place to change the site default from at least the detection and selection page.

Gábor Hojtsy’s picture

Status: Needs review » Needs work
Xano’s picture

I'm a little bit torn on this one, it looks to be at the right place but none of the other language settings are here.

YesCT and I had a dicussion about this yesterday. The conclusion was that this issue is about the fallback locale (language and country are the two identifiers for a locale), rather than language and country settings (CRUD-ing them, rearranging them, etc).

For more arguments as to why these two (global locale configuration, and locale components such as language, location, and currencies) should be separated, see my comment #18 in #1345758: META: Provide locale (regional) formats framework for automated translation of non textual data .

Gábor Hojtsy’s picture

@Xano: just putting them on one screen will not make Drupal understand the combination as one :)

Xano’s picture

It won't, but from a locale-perspective, if the default language setting is moved from the languages page anyway, best to put it next to its counterpart on a general locale page than to put it on the rather unspecific "Site information" page.

Gábor Hojtsy’s picture

Right, all I said was "I'm a little bit torn on this one, it looks to be at the right place but none of the other language settings are here.". That is, in other words, disconnected from all the rest of the language settings and not cross-linked. It is probably very discoverable in and of itself (*all* people we observed in the first Drupal 8 user testing of multilingual improvements looked for language settings under "Regional settings").

vijaycs85’s picture

So two things need to be done here:

1. Fix header in language list page.
2. Add help text (or part of field description) to cross link language list page in regional settings page

Is it right Gábor?

Gábor Hojtsy’s picture

@vijaycs85 That does not seem to include all the code comments I provided in #24, does it?

vijaycs85’s picture

Status: Needs work » Needs review
FileSize
4.02 KB
20.38 KB
PASSED: [[SimpleTest]]: [MySQL] 48,677 pass(es). View

yes @Gábor Hojtsy . I have fixed the comments/help text as well. So this patch has below fixes:

1. Help text fixes in #24
2. Interface header and data issue
3. Added cross - reference for default language in detection and selection page.

vijaycs85’s picture

Gábor Hojtsy’s picture

Issue tags: +Needs screenshots

Needs screenshot :)

vijaycs85’s picture

Issue tags: -Needs screenshots
FileSize
30.88 KB
21.53 KB

Updating screenshots
Language list:
language list page

Detection and selection:
Only local images are allowed.

Regional settings:
regional settings

Gábor Hojtsy’s picture

Title: Improve default language change process (ui and help text) [a follow-up] » Improve default language change process (ui and help text)

It does not matter really that this is a followup. Also asked Bojhan to review if available :)

Status: Needs review » Needs work
Issue tags: -Needs usability review, -D8MI, -language-base, -medium, -needs initial patch

The last submitted patch, 1803638-default-language-ui-change-32.patch, failed testing.

vijaycs85’s picture

Status: Needs work » Needs review
Issue tags: +Needs usability review, +D8MI, +language-base, +medium, +needs initial patch
Bojhan’s picture

This is an idea, however why can't you juist set the default at the language? So you click edit on a language, and there you can set whether its the default? That to me sounds like a logical place.

Gábor Hojtsy’s picture

@Bojhan: I don't have strong feelings either way. :)

YesCT’s picture

Issue tags: -needs initial patch
FileSize
1.34 KB
20.47 KB
FAILED: [[SimpleTest]]: [MySQL] 48,571 pass(es), 2 fail(s), and 3 exception(s). View

Removing the default language setting from the language table is in part supposed to direct working sites to go to detection and selection. I think we should use the help text on languages to do that. The detection and selection then points people to the default setting.

This just changes that last sentence in the language help text. Otherwise, I suspect people will not know why they should go to the detection and selection tab.

Gábor Hojtsy’s picture

Issue tags: +needs initial patch

Yeah, so what we want is that people don't change their site default language and instead change the configured language fallback in detection and selection essentially. That is why we want to make changing default language less of a convenient setting up front, but make it more like a "once set and never changed" setting.

Gábor Hojtsy’s picture

Issue tags: -needs initial patch

Crosspost.

YesCT’s picture

I checked to make sure the regional settings were ok, without language enabled. It looks fine.

before-enable-language-2013-01-31_1115.png

And here is the change in the language page help text.

language-help-2013-01-31_1122.png

Status: Needs review » Needs work

The last submitted patch, 1803638-default-language-ui-change-41.patch, failed testing.

YesCT’s picture

Status: Needs work » Needs review
Issue tags: -needs initial patch
FileSize
1.93 KB
20.61 KB
PASSED: [[SimpleTest]]: [MySQL] 49,274 pass(es). View
55.17 KB
18.68 KB

If we did allow the setting of the default by editing the language... we would want to show the current default probably. That gets a bit tricky, so I prefer this approach with the setting under regional settings.

Right now, there are a few ways to know what the default is. Go to the regional settings and check there. And from the detection and selection tab, in the for for "selected language", when the selected language is "site default" as it is by default. It also says what the site default is.
Language based on a selected language. (Site's default language (English))

selected-language-row-2013-01-31_1129.png

And actually, any language select drop down, probably shows "Site's default language (Whatever)" as one of the options.

-----
This is a very small change from "Use the selected language" to "Configure the selected language" as it provides more of a hint that the site builder should click the configure drop button to choose a fallback language.

It is not recommended to change the default language on a working site. Configure the Selected language setting on the detection and selection page to change the fallback language for language selection.

configure-2013-01-31_1139.png

-----

I had some ideas for improving the help text on the detection and selection tab (to use the word *select* and *selection* in some places instead of decide, etc). But that should be part of another issue dealing with that tab, not this issue.

----

I did a good look at coding standards and found
http://drupal.org/node/1354#hookimpl
form id comment should be a bit different.

I'm not sure about the naming of the submit handler...

The example from the comment standards shows something like:

/**
 * Form submission handler for user_login_form().
 *
 * @see user_login_form_validate()
 */
function user_login_form_submit($form, &$form_state) {

So it seems like instead of

/**
 * Form submission handler for system_regional_settings form alter.
 */
function language_system_regional_settings_form_submit($form, &$form_state) {

we might want:

/**
 * Form submission handler for language_system_regional_settings_form().
 */
function language_system_regional_settings_form_submit($form, &$form_state) {

but there is no such function as language_system_regional_settings_form().

So... I think I'd suggest. Adding @see's and referring to system_regional_settings(). So I did that in the patch.

YesCT’s picture

failure of #41 was "Drupal\system\Tests\Upgrade\BareMinimalUpgradePathTest"
lets see how #46 goes.

tstoeckler’s picture

Coming a little late to the party, but I just had a completely different idea to address this issue: Why not have a confirm form that is (conditionally) displayed in-case you are trying to change the default language. Something like "Hey, unless you *just* installed the site and have zero content, you probably don't want to do this, because innocent cats will die. Go to 'Selection / detection', please."
I think people generally read confirm forms.

Just wanted to throw that out there. It's totally fine with me if we go with the currently proposed approach.

YesCT’s picture

@tstoeckler I'm ok with adding that, if people think it's good. either here or in a separate issue. should be fine either way.

YesCT’s picture

this could go rtbc if someone wants to give it the once over. I'm happy with it, but I made the most recent code changes, so I should not rtbc it.

Gábor Hojtsy’s picture

Status: Needs review » Reviewed & tested by the community

So once again all we know is we want to make changing the site default language harder (because it is dangerous) and want to drive people towards the detection and selection config to change the fallback language. This might not be the eventual experience towards that in Drupal 8 but it is clearly one of the options that most people supported above.

I'm personally not sure that the current placement is best, BUT it reaches the goals we set out to achieve. I believe we can user test this pretty easily and still have months to move this around if needed. So I support this to get in. Also reviewed the code again, it still looks good.

Gábor Hojtsy’s picture

Dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to 8.x. Thanks.

Gábor Hojtsy’s picture

BTW listening to @webchick's demo of the D8MI changes in Sydney, it occurred to me that while you look at the language list, you might get puzzled now that one of them is not possible to delete while others are. The reason is the default one cannot be removed, but this is not really exposed or explained now. I'm not sure this will be an actual problem. With the language switcher changes hopefully figured out sooner than later, we should return to test the basics again and figure this out based on data.

Automatically closed -- issue fixed for 2 weeks with no activity.

Gábor Hojtsy’s picture

#2153937: Default language setting is hard to find proposes to roll this change back, see there.