Fatal error on Drupal\locale\LocaleConfigManager::compareConfigData() when trying to make content translatable

Two extra bits of information:

• Accessing this functionality through a different admin page produces the same error. The switch can also be found through Home » Administration » Structure » Content types » » Language Settings » Enable Translation. Checking this off ends in the same error as first described.
• Uninstalling the content_translation module allows the Region and Language page first described to be saved successfully (without of course the presence of the Translatable checkbox.

@webchick I agree this is pretty serious. It put a dead end to my playing around with the beta! Pretty much the main reason I started using Drupal over other CMS systems was its multi-lingual prowess.

I have to wonder if maybe this functionality worked in earlier D8 betas or dev builds and continues to work in current builds for sites that had the functionality previously enabled for the various content types. I would be shocked and appalled if developers weren't running multi-lingual test sites out there already. It seems like maybe just the action of enabling it might be broken at this point. But either way, fixing it and making a test is beyond me and I'll wait for this issue to be resolved before taking the beta for another spin.

Uhm, that's a bit too much... emotion

Not really. You would probably have even stronger feelings about it. If Drupal 8 had really gotten to and 8th beta rollup with a non-functional multilingual system an no developer to date had ever played around with it enough to notice a core feature was totally inoperable, you would be shocked and appalled too. Obviously that is not the case...I'm sure it's been played around with and at least various junctures it has been working. Obviously it's working now for you in some other environment so the issue is somehow more nuanced than total breakage. Obviously the next step is to figure out what factors play into that nuance, but the fact remains that _if_ it had never been tested by anybody you would get pretty emotional too. D8 would be a stillborn release _if_ that was the case.

So what makes triggers this issue? I don't know, but my system pretty consistently fails. I've nuked the DB and done the install from scratch a couple times and ended up with the same results every time.

We have lots of tests that cover enabling translation.

What exactly do these tests test? Is there a log of what commit levels / versions passed which tests somewhere?

This is either a) combination of modules/configuration that we are not testing yet or […]

This seems likely to me, but my combination of modules/configuration is not very complicated. In fact the last time I believe it failed on me with nothing but modules from core enabled on an otherwise clean install.

The one thing that stands out to me is that I'm using a non English site default language but enabling English as a secondary available language. My experience in playing around with the beta has turned up a number of cases where this produces strange results (e.g. the maintenance mode message is borked). Other cases I'm still trying to figure out if they are bugs or my failure to grok the UI or what (e.g. block content and menu times sometimes turn up localized while the block/menu heading does not and vise versa).

[…] b) it is something that only happens on a specific system configuration. […] which means that we need more information about your system. OS, PHP version, anything that you think might be useful to know.

* OS: Arch Linux (rolling release, up to date)
* Apache 2.4.12
* PHP 5.6.5
* MariaDB 10.0.16
* All tests done using Drupal code from the 8.0.0-beta6 tarball.

The only possibly unusual bit that comes to mind is that the file system is not owned by the http user, only the sites/default/files directory is owned by http and thus writable; everything else (including modules and themes directories) is owned by a deploy user and new modules can only be installed by adding them to the source repo, not through the admin interface.

Also, are there any other errors, warnings or notices in the log right before this error? This might just be a follow-up problem of an earlier error.

No, there are no other errors showing up. If I clear the log and play around in the site nothing at all shows up until that one error when I try to enable "Translatable".

The only other thing I'm seeing is if I run the Status report self-check page from the Admin panel, I do get two php warnings, both of severity "notice":

Notice: Undefined index: name in system_requirements() (line 41 of /srv/http/drupal.protestan.org/core/modules/system/system.install).

Notice: Undefined index: version in system_requirements() (line 43 of /srv/http/drupal.protestan.org/core/modules/system/system.install).

I'm not sure this will help much, but I've been trying to trace this a little more. I have production and devel environments that are very similar (nearly identical software wise). I've installed twice on each and gotten the same results each time: works on one and not the other. That would lead me to believe something is different in the env, but my gut is telling me something else is up here. Besides the env being nearly identical, D8 is acting differently and I can't explain why.

I started looking at the POST headers that are getting sent across on form submits from the admin panel on each and they are different.

For example, see the two attached POST var dump files. For best results diff them with each-other. The failing one has a bunch more values it is sending across—as if I'd checked off a bunch more things. But I didn't. The form states being submitted here are tit for tat identical. I meticulously went through on each server and setup the settings the same way (they already used the same code base), enabled the same modules, etc etc. Then I came to the content-types form and checked off exactly one option in each (the Basic Page type) as translatable. Every check box on the page is the same between posts, only the server and instance is different. Yet the one that is failing is sending over a bunch of extra values as if I'd checked off "Article" as well as "Basic page" etc.