Force site builders to make only valid choices when configuring entity default language with translation enabled

While doing this ensure that it is still possibile to hide the language selector and enable translation if a valid default language is selected.

I have identified the following workflow:

Background:

1. Content translation & Locale are enabled.
2. There is, at least, one content type to work with.

Case 1:

1. Edit your contente type (Article in my case).
2. Under the Language settings vertical tab select:
   • Uncheck checkbox Show language selector on create and edit pages.
   • Check checkbox Enable translation.
   • Select - Not specified - in Default language.
3. Save the content type.

A validation error forbids you to save the content type.

Case 2:

This case is exactly the same one as Case 1 but selecting - Not applicable - as the Default language.

Case 3:

This case is exactly the same one as Case 1 but checking Show language selector on create and edit pages. In this case the validation error does not exist and therefore the user can successfully save the content type.

Case 4:

This case is exactly the same one as Case 1 but selecting English (or any other active language) as the Default language. In this case the validation error does not exist and therefore the user can successfully save the content type.

Assigning to myself in the context of core menthoring (with xjm).

Writing a patch to test.

The cases explained look all good and correct.

Also, same interaction happens on the content language configuration screen (in regional and languages), although for all entities altogether.

I would want to test the same behavior when selecting a locked language, but I do not know what those are or how to get one. Any thoughts?

Not specified and not applicable are the two locked (non-configurable, non-removable) languages in core. Contrib can add more, there is no UI for these which is the nature on the non-configurability. :)

Thanks!

I was thinking on hiding 'und', 'mul' and 'zxx' from the select but if contrib can add locked languages of their own this means the list should be retrieved in an Ajax call where the locked property can be tested.

Another option could be testing the language name against the regexp /^- .* -$/ in the JS side. Can we rely on a regexp like that, won't we be missing locked languages or having false alarms?

Other options include changing the form structure or/and markup to identify these locked languages, I'm not taking those into account for now.

Well, we could generate some more metadata alongside the select box for the JS to use. I personally believe dynamically removing items from the select box when you check another checkbox might be unexpected and especially without explanation pretty surprising.

The following patch detects locked language in the frontend part using a regex (like the one #8).

The patch performs the detection for each select individually, taking into account different default values allowed per entity bundle.

The same behavior is applied in the vocabulary edit form & node type edit form.

Taking #9 into account, we could evolve this patch to provide a hidden list of locked languages within the form to detect locked languages more accurately (instead of the regular expresion).

Entity translation settings

Taxonomy settings 1

Taxonomy settings 2

Changing status.

The disappearing/appearing description looks interesting. Maybe we should reserve space for it in the form, so it does not make the form jump around when clicked. However, before going deeper into this, it would probably be best to get some usability feedback. Tagging for that, so Bojhan et. al. can take a look.

Not sure I interpreted the screenshots correctly but locked languages should be hidden only when the bundle is translatable and the language selector is not shown.

plach is right in #13. This behavior should only be triggered when the bundle is translatable.

Improved title

The new patch takes into account the comments by plach in #13.

Screenshots are from node type edit form:

Enabled + hidden (should hide locked languages)

Enabled + shown (should not hide locked languages)

Disabled + shown (should not hide locked languages)

Disabled + hidden (should not hide locked languages)

I forgot to update the status … again :-P

See contributor task doc on manual testing: http://drupal.org/node/1489010

Rerolled patch

It seems to work as described in #16 in Linux with Google Chrome Version 25.0.1364.97

Not message and not hidden options:
Disabled + Hidden:

Disabled + Shown:

Enabled + Shown:

Hidden options and explanation

Unassign while waiting for RTBC.

+++ b/core/modules/translation_entity/translation_entity.admin.incundefined
@@ -136,9 +136,21 @@ function _translation_entity_preprocess_language_content_settings_table(&$variab
+    $rows[$bundle]['data'][2]['data']['language']['language_show']['#description'] = t('Some default language options are hidden if the language selector is not shown.');

+++ b/core/modules/translation_entity/translation_entity.moduleundefined
@@ -922,6 +922,20 @@ function translation_entity_language_configuration_element_process(array $elemen
+    $element['language_show']['#description'] = t('Some default language options are hidden if the language selector is not shown and translation is enabled.');

It looks a bit odd to have this description on the checkbox for showing the language selector. It talks about options in the language dropdown and therefore describes what happened to another field, not this one.

+++ b/core/modules/translation_entity/translation_entity.admin.jsundefined
@@ -103,4 +103,67 @@ Drupal.behaviors.translationEntity = {
+/**
+ * Removes unusable locked languages when not showing language selector.
+ * This behavior gets attached on the relevant entity edition form and
+ * the translation entity summary form.
+ */

As per Drupal code style there needs to be an empty line after the first line.

+++ b/core/modules/translation_entity/translation_entity.admin.jsundefined
@@ -103,4 +103,67 @@ Drupal.behaviors.translationEntity = {
+         var $unlockedOptions = $originalOptions.filter(function (index) { return !/^- .* -$/.test(this.text); });

Was this cross-checked to be always used as is - -?

+++ b/core/modules/translation_entity/translation_entity.admin.jsundefined
@@ -103,4 +103,67 @@ Drupal.behaviors.translationEntity = {
+             $checkbox.siblings('.description').css('opacity', 0);
+           }
+           else {
+             $languageSelector.html($unlockedOptions);
+             $checkbox.siblings('.description').css('opacity', 1);
+           }
+         }
+         else {
+           $languageSelector.html($originalOptions);
+           $checkbox.siblings('.description').css('opacity', 0);

Why are you using opacity to hide the element? Looks strange to me.

Also seems like if I had an option selected and that option vanished, I'm not alerted at all visually that my settings will largely change. At least if the process removed the option I had selected before, it should let me know with a yellow box appearing there or something IMHO. Now that given this adjustment the server side will not complain anymore.

Was this cross-checked to be always used as is - -?

Re-checked. It appears on:

core/modules//language/language.module:256
core/modules//language/language.module:285
core/modules//node/node.admin.inc:116

Why are you using opacity to hide the element? Looks strange to me.

This was done because of your suggestion in #12, but I agree that is better hiding and showing it.

The disappearing/appearing description looks interesting. Maybe we should reserve space for it in the form, so it does not make the form jump around when clicked.

I added a standard warning message if the selected language is changed and moved the description to the language dropdown.

Edit (posted twice by mistake)

@YesCT according to plach on #13

[...] locked languages should be hidden only when the bundle is translatable and the language selector is not shown.

As I see it, if the language selector is shown then the user will be forced to make a valid choice on content creation, and locked languages may be the default initial choice.

Is this assumption correct?

Wondering, could these messages be a little bit more friendlier. Less focused on the user, and more on the system needing something.

- "You default language has been changed. You need to show the language selector to use a locked language."
+ You default language has been changed. To use a locked language, the language selector needs to be shown"

Also not sure about having "Some" in a message, that is quite ambiguous.

Chaged wording according to #28.

I re-rolled the patch and improved the warning message.

@YesCT, please make sure you have one locked language selected when hiding language selector (or enabling translation) to make the warning message to appear.

Re-rolled the patch and fixed a php error.

Adding also the interdiff

Sorry, I answered without noticing that e0ipso had already answered changing the status... so I changed the status by mistake. I change it again now.

Re-rolled the patch #37 and run tests

There was a problem with the previous re-roll.

120c120
< +    $element['#attached']['library'][] = array('translation_entity', 'drupal.translation_entity.admin');
---
> +    $element['#attached']['library'][] = array('content_translation', 'drupal.content_translation.admin');

Should pass tests.

Removing tags

Working on during a drupal mentoring session.

Re-rolled patch to current Drupal 8 version.

Re-rolled.

I did tests on firefox:
When enabling translation with a locked language it works correctly and the message

"To use a locked language, with translation enabled, the language selector needs to be shown."

is shown above correctly.
But the the message didn't disappear when enabling the language selector or when doing any changes. It would be nice if the message disappears again.

Further, I noticed, when setting e.g. Default language to 'Current Interface language' and uncheck the 'Show language selector', the Default language setting changes in my case to 'German'. Re-checking 'Show language selector' the Default language setting jumping to '- not applicable -'.

Just did a test on IE:
the second note, 'Default Language' setting stays correctly when un-checking and re-checking the 'Show language selector' box. So okay with IE.

The patch in #54 doesn't apply.
I got an error notice when trying to save the content type 'article' with these settings:
- Default language: not specified
- Show language selector on create and edit pages: off
- Enable translation: on.
The error notice:
Notice: Undefined index: und in content_translation_language_configuration_element_validate() (line 847 of core/modules/content_translation/content_translation.module).

Uploading a new patch that applies to the current state of core.

Fix to pass tests by doing the correct attach

add interdiff for my last patch

62: drupal-allow-only-valid-choices-1834266.62.patch queued for re-testing.

Patch rerolled and some linting.