Cannot install in foreign language (Undefined index: und in ContentEntityBase->language())

Closed #2147069: Error during installation: Invalid translation language () specified as duplicate of this.

This fix did help but still looks like something is not right. The installation completed but this notice was still visible during configuration translations updating.

4: install-foreign-language-fix.patch queued for re-testing.

Same here, I am able to install Drupal now, but I also get two notices:

Notice: Undefined index: und in Drupal\Core\Entity\ContentEntityBase->language() (line 547 of core/lib/Drupal/Core/Entity/ContentEntityBase.php).
Notice: Trying to get property of non-object in Drupal\Core\Entity\FieldableDatabaseStorageController->doLoadFieldItems() (line 842 of core/lib/Drupal/Core/Entity/FieldableDatabaseStorageController.php).

Not being able to install at all sounds critical.

I would *love* to see if there's a possible way we can write tests for this (a multilingual-enabled test profile..?), though I suspect not.

I've found so far that the notices are caused by first user_load(1) in install_configure_form_submit function.
I tried adding 'langcode' => Language::LANGCODE_DEFAULT, in user_install for user 1 but that didn't help.
Finally I hardcoded 'langcode' => 'pl', in user_install and installed in Polish - the notices were gone.

Now I don't know if somehow there should be langcode of selected language passed to user_install or the problem lies in ContentEntityBase->language which tries to load wrong language in this case and should check that better.

This fixed it for me.

#12 works for me as well (french install).

You're right I forgot about anonymous user account and it probably would result in some problems somewhere else :)
Patch #14 works for me so maybe we can mark it as reviewed?

It would highly suck to ship an alpha with multilingual installs broken, so tagging.

I can confirm that this patch works. All notices are now gone.

This issue exists for me as well. The 2.04kb patch from #15 works for me.

Regards,

I'm confused why #15 says both passed but #19 and #21 say it didn't? :)

Maybe it is a problem with the profile itself?

I'll try to take a look tonight.

InstallerTranslationTest pass for me.

Missing Curly Brackets.

Upsss try again, sorry.

#29 review:

+++ b/core/modules/system/lib/Drupal/system/Tests/Installer/InstallerTranslationNonInteractive.php
@@ -43 +43,0 @@
-}

The "interdiff" between marthinal patches and mine is that I dropped accidentally a bracket on my patch, and he restored that.

Locally I get, in both cases, with HEAD and with the patch attached:

3 passes, 0 fails, 2 exceptions, and 1 debug message

Trying to get property of non-object
_install_prepare_import('de')
install_import_translations(Array)
install_run_task(Array, Array)
install_run_tasks(Array)
install_drupal(Array)
Drupal\simpletest\WebTestBase->setUp()
Drupal\simpletest\TestBase->run()
_simpletest_batch_operation(Array, '5', Array)
call_user_func_array('_simpletest_batch_operation', Array)
_batch_process()
_batch_do()
_batch_page(Object)
Drupal\system\Controller\BatchController->batchPage(Object)
call_user_func_array(Array, Array)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1)
Drupal\Core\HttpKernel->handle(Object, 1, 1)
Drupal\Core\DrupalKernel->handle(Object)
drupal_handle_request()
Notice	install.core.inc	2066	_install_prepare_import()	Exception

Undefined offset: 1
_install_prepare_import('de')
install_import_translations(Array)
install_run_task(Array, Array)
install_run_tasks(Array)
install_drupal(Array)
Drupal\simpletest\WebTestBase->setUp()
Drupal\simpletest\TestBase->run()
_simpletest_batch_operation(Array, '5', Array)
call_user_func_array('_simpletest_batch_operation', Array)
_batch_process()
_batch_do()
_batch_page(Object)
Drupal\system\Controller\BatchController->batchPage(Object)
call_user_func_array(Array, Array)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1)
Drupal\Core\HttpKernel->handle(Object, 1, 1)
Drupal\Core\DrupalKernel->handle(Object)
drupal_handle_request()
Notice	install.core.inc	2069	_install_prepare_import()	Exception

and no idea what's going on.

Will continue trying to guess the problem, but anyone can feel free to work on this one.

I want to test it but running

$ ./vendor/bin/phpunit --group Installer

gives me only

PHPUnit 3.7.21 by Sebastian Bergmann.
Configuration read from /var/www/core/phpunit.xml.dist
Time: 2 seconds, Memory: 30.75Mb
No tests executed!

Is this test in other group or do I run it somehow wrong? Sorry for newbie question :)

Hi @philipz, thanks for trying!

This test is not a phpunit test but a simpletest. You can run it by:

php ./core/scripts/run-tests.sh --url http://d8.local --class "Drupal\system\Tests\Installer\InstallerTranslationNonInteractive"

Drupal\system\Tests\Installer\InstallerTranslationTest passes for me locally too.

Now I'm trying to understand the problem in InstallerTranslationNonInteractive. This is what is blocking RTBC?

Yes, that's it. We need to convert that into a test that fails with the current HEAD but passes with the attached fix.

This is my try on this. Worked for me locally so I hope it's ok.

Thanks philipz!

Looks like the desired behavior. If Gábor agrees this is RTBC.

I'm very happy, yesterday I started learning how to write and run tests in Drupal and today success :)
Thanks for quick replies and all the insight in this issue!

Added comment and removed unnecessary second $submit_value xpath fetch.

Still RTBC.

Yay! Great work, filling in this missing test coverage!

Committed and pushed to 8.x. WOOT!

Awesome! Welcome to core development, philipz!

Awesome work, guys!

Just wanted to point out that this new test caught its first critical regression within 24 hours: #2021779-83: Decouple shortcuts from menu links Great job, phillipz! :D

Sweet :D Thank's for the link and for the welcoming!

Unfortunately I think the fix here was just a workaround (with helpful test coverage!), I'm trying to find and fix the underlying problem in #2156945: Clean up installer entity defaults following bugfix. See you there :)

Right sorry, misread that. Although that makes we wonder a bit if users should really be by language by default, on most sites, that is not going to be language-specific data. Because now they're always a specific language.