Add options for site/user/interface language as default value

This sounds like a good idea. But the patch adds a new hook, making the system heavier.
How about this:
- in the widget settings, add a new language code 'zus => "users current language" ' in the list of languages;
- in the widget, when setting the '#default_value', determine the correct value for language code 'zus'.

Perhaps we should request a new language code in Drupal Core - language system. In D8 already 'und' and 'zxx' exist.

Please review my attached version.
Indeed, the extra hook is needed, because languagefield does not use its own widget.
- Your 'preselect' option might be better for the sitebuilder, since it is more explicit. My extra 'zuser' option is a bit underwater.
- My version uses $user instead of $language. I think it is clearer, because with $language, it is not clear (to me) if you only have 1 site language or N user languages.)

In your use case, is the user language only a proposal, or is it forbidden to choose another value?

I've created issue #2364503: Add a "User's default language" value.

Indeed, my patch uses an extra language in the language list, instead of an extra checkbox, but it is too obfuscated (?). Itis a proof of concept.

About the language choice:
- in my test I change the language of the authenticated user, so the language is in the $user object.
- in your situation your anonymous user has choosen a site-wide language. I did not test that.
My point was: to me, in your first patch, it was not clear if the language could change depending on the users settings.

(I'm not sure if this post has made anything clearer :-)

@kitikonti, I'm investigating this in the D8-version, and have patches coming up.
In D8, 3 new options exist:
- default language (the language upon installation)
- interface language (via language switcher or else)
- users preferred language (via user settings)
These cover both the use cases in your an mine patch.

Also, in latest dev-release, the language select in the field settings is multi-value now since #2116687: Using new (custom) languages AND predefined languages got in. So a new checkbox 'preselect' is not necessary, as I'll extend the current list of (3) options.

Patches coming up soon.

This is now added to the D7-version and the D8-version.

If you test and accept the current version, I will release an official release. or you can open #12. For some reason the version is not shown in the automatic comment.

Ja, the code is wrong. See below how I meant it (the first part). (I have no access to Drupal ATM)

function _languagefield_widget_value($element, $input = FALSE, $form_state) {
  if (!$input && isset($element['#default_value'])) {
    // The widget is shown, and a default/actual value is given.
    $input = $element['#default_value'];
  }
  elseif (!$input) {
    // The widget is shown, and no default/actual value is given.
    // Do nothing.
  }
  else {
    // The form is submitted.
    if (!is_array($input)) {
      $input = _languagefield_getLanguageConfigurationValues($input);
    }
    else {
      // Checkboxes lose their value when empty.
      // If the display field is present make sure its unchecked value is saved.
      // Convert the values to real languagecodes,
      // but ONLY on Entity form, NOT in the 'field settings - default value'.
      foreach ($input as &$value) {
//        $value['value'] = _languagefield_getLanguageConfigurationValues($value['value']); // D8??
        $value = _languagefield_getLanguageConfigurationValues($value); // D7
      }
    }
  }
  return $input;
}

Indeed, the [#value_callback] executed both on showing and on committing the widget. (In D8, the massageFormValues() method is used.)
The current dev-version should work. I only doubt if we should expose the user with the technical names in the options list and the default value.
But that is UX.

Changing the value upon showing the widget seems fine. However, I tested the multiple value use case (which was wrong in first instance) but i thought it was corrected in #20. Can you provide a pstch for that?

Changing the value upon showing the widget seems fine. However, I tested the multiple value use case (which was wrong in first instance) but i thought it was corrected in #20. Can you provide a pstch for that?

Yes. Before #20 it was wrong, as you described earlier. #20 contains a fix for multivalue.

Perhaps your problem is that in the fist part of the function, we do not difference between single and multivalue, as we do in the second half.

Hmm, you're making it difficult in #23.
Adjacent patch makes some things better, but still will not work for your situation, where the widget apparently is not submitted.
That cannot be handled in the widget, but in some hook_field*() hook.

@kitikonti , let's close this issue. We can re-open a new issue regarding #23 when needed.