Provide language awareness to entity forms (introduce the form language concept)

there's a mention about forms in #1448330-25: [META] Discuss internationalization of configuration
Symfony has a great formAPI

Also I think the langcode properties/fields affects mostly on render layer of core

@plach: can you provide an updated version of your thinking on this. I got @vasi1186 to work on #1280996: New language_select element type for form API for language selection generalization. Would be good to find common grounds sooner than later.

Here is a first attempt. The patch introduces a new entity form language type and uses it as a default value for the form language if no one is explictly provided to entity_get_form().

Fixed negotiation callback for new language type and some tests.

+++ b/core/modules/entity/entity.module
@@ -12,6 +12,11 @@ use Drupal\entity\EntityStorageException;
+const ENTITY_LANGUAGE_TYPE_FORM = 'entity_language_form';

As discussed with plach we think it makes more sense to have general language type instead of this one. E.g. language_content_edit or something like that, and then use this as default. Let's do so then.

renamed

@plach: that sounds good, makes sense.

I'll work as per #13 on an alternative version without a new language type.

Removed the new language_form language type and set language_content as form default language.

Going without a separate language for now is fine to move on I think. As discussed let's keep the default in $form_state['langcode'] initially so the form controller can deal with it properly.

Oh, that looks very clean now :)

+++ b/core/modules/entity/lib/Drupal/entity/EntityFormController.php
@@ -208,11 +208,23 @@ class EntityFormController implements EntityFormControllerInterface {
+      // If the site is not multilingual or no translation for the given form
+      // language is available, fall back to the entity language.
+      $langcode = language(LANGUAGE_TYPE_CONTENT)->langcode;
+      $fallback = language_multilingual() ? language_fallback_get_candidates() : array();
+      while (!empty($langcode) && !isset($translations[$langcode])) {

Comment and code doesn't do the same? It uses content language and applies language fallbacks. We should do a final fallback to default entity language though if none of the fallback-languages is in the entity, or?

Comments fixed as per fago's suggestion. Actually we already fall back to the entity language.

getFormLangcode() should return a langcode not a language object. Fixed.

@peximo: are you continuing work on this issue? It is a very important part of making Drupal 8 multilingual! Thanks for working on it so far!

@gabor: I'll work on this issue tomorrow morning.

Fixed Entity::language() method and added some tests.
@gabor: plach thinks is better to do the test with the entity_test form controller (see #1757232: Improve test coverage for the entity form controller). So we might need to merge the two issues.

I'm not sure I fully understand why this is necessary (issue summary is a bit sparse), but all of you seem to agree that it is a good idea. I hope you guys asked each other some criticizing questions in the discussions ;)

The code in EntityFormController::getFormLangcode() could be improved for monolingual sites and clarified in terms of code logic, but that is pretty minor and can be done in a later follow-up.

This deals with the rapidly changing entity landscape and is at a definite risk of commit conflicts.

#34: et-form_language-1498874-34.patch queued for re-testing.

This looks great. just one question:

+++ b/core/modules/entity/lib/Drupal/entity/Tests/EntityTranslationTest.phpundefined
@@ -22,7 +22,7 @@ class EntityTranslationTest extends WebTestBase {
-  public static $modules = array('entity_test', 'locale');
+  public static $modules = array('entity_test', 'locale', 'node');

Why not adding multilingual forms to the entity_test module?

@catch: the entity_test module is a pure API test module, it does not have page callbacks or forms at all. I think it would be important at this point to get this moving instead of pushing it back to implement a UI for testing in entity_test module while we already have the necessary stuff to test elsewhere, such as in node module.

OK that's fine, but in that case let's add a new test class for the forms, so we don't need to install node module for the other test methods.

Moved it to a separate file with only the setup routines required for this one.

Should be back to RTBC then.

+++ b/core/modules/entity/lib/Drupal/entity/Tests/EntityTranslationTest.phpundefined
+++ b/core/modules/entity/lib/Drupal/entity/Tests/EntityTranslationTest.phpundefined
@@ -22,7 +22,7 @@ class EntityTranslationTest extends WebTestBase {

@@ -22,7 +22,7 @@ class EntityTranslationTest extends WebTestBase {
    *
    * @var array
    */
-  public static $modules = array('entity_test', 'locale');
+  public static $modules = array('entity_test', 'locale', 'node');

This change shouldn't be needed then?

Indeed, we should not have any business touching that file anymore.

Thanks! Committed/pushed to 8.x.

I don't think this really needs change notice so moving straight to fixed, but please re-open/write one if you disagree.

This should be done for our sprint then :) Thanks all!

Updated issue summary.