Language detection is broken in 7.x-1.x-dev

Also running into this issue.

I've got a non-translated fieldcollection field with translated fields, and they're showing in the wrong language when rendered.

For me the original change passes in UND as the language, which sort of makes sense because the fieldcollectionitem is in language UND (it's untranslated), but obviously at the end I want my fields to render in EN/DE/FR/IT. When the langcode isn't passed in the entitycontroller (entity.controller.inc:view()) will get the language from $_GLOBALS['language_content'], which seems to be what I want.

Not really sure how to go about determining whether to pass it through / what to pass through instead...
A starting point might be to undo the change that passes $langcode through.

IIRC, at some point, the entity reference module's formatter had a little setting for choosing whether to use the 'inherited' language that is passed through, or to avoid using the passed one. Something like a checkbox saying 'Use parent content language'. As I believe there is a use case for either approach.

Seems like adding some tests would help ensure the functionality works as intended.

Lets run the tests that already exist.

The patch in #2 is a year old, but still applied cleanly to the latest 7.x-1.x dev snapshot.

Please be careful with the tags, it can be easy to accidentally remove them. Happy holidays!

I can confirm that the patch fixes a client's site with translated fields and 7.x-1.0-beta13.

I'm no expert on writing tests, but I think checkFieldCollectionContent() must be flawed in that it should fail when comparing translations. Perhaps it just needs to be tweaked to better match actual scenarios.

Here's a reroll for the latest dev.

Thanks for committing the fix. Though I don't see how I had a syntax error in the reroll...

The syntax error comes from this line:

  $mappings = $source->importer()->getConfig()['processor']['config']['mappings'];

It was added in #1063434: Add Feeds integration to FieldCollection.