FeedsProcessor not respecting bundle i18n language settings

+++ b/plugins/FeedsProcessor.inc
@@ -152,9 +152,19 @@ abstract class FeedsProcessor extends FeedsPlugin {
+      $languages = i18n_node_language_list($entity);

@@ -858,9 +868,20 @@ abstract class FeedsProcessor extends FeedsPlugin {
+        $languages = i18n_node_language_list($node);

It looks like the "alternative" language list is specific to node. Therefore I think we should only show the additional languages for the node processor.

I think we need an additional method on the processor class that returns the available languages. The node processor class can then override that method. There is a method called bundleOptions(), so maybe we should call this method languageOptions()?

Just to let you know: there are more specific i18n settings that Feeds doesn't respect currently (like "Require language" or "Lock language"). We deliberately didn't add support for them because that would have made multilingual support in Feeds even further away (and it took already 4+ years to get the thing done). See #1183440: Multilingual Feeds - Make field import language-aware.

I did read the thread you posted before adding this one and it said in the i18n description that additional features should have new issues created for them which is why I made this.

Creating a new issue is correct. I thought I should just warn you that you could possibly face more road blocks between Feeds and i18n.

If the language list is specific to bundle and a node is needed to get that list, then creating a dummy node looks fine to me.

When adding a method that returns the available languages, the validator should use that information as well to validate the language. Therefore moving the validator to the node processor would not be needed.
The code in FeedsProcessor::entityValidate() would look then something like this:

// Ensure that a valid language is always set.
$key = $info['entity keys']['language'];
$languages = $this->languageOptions();

if (empty($entity->$key) || !isset($languages[$entity->$key])) {
   $entity->$key = $this->entityLanguage();
}

FeedsProcessor::languageOptions() would then return the available languages using language_list() and/or locale_language_list(). FeedsNodeProcessor::languageOptions() would return the i18n node languages (if available) or else leaves it to FeedsProcessor to provide available languages using the following code:

return parent::languageOptions();

I set the issue status to "Needs review", so the testbot will evaluate the patch. I have not examined your patch in detail yet, but at first glance it seems to me that LANGUAGE_NONE should be one of the options returned by languageOptions() (I could be wrong though). Other than that code-wise it looks like it is heading in the right direction. Good work!

Hm, the testbot seems to ignore the patch. Re-uploading so the testbot will pick it up.

The patch applies cleanly against the latest dev, so it seems. Else the testbot would have said "Patch failed to apply". Glancing over the test results, the patch seems to break importing multilingual terms using the Taxonomy term processor. Additionally, there are some failures with importing values using entity translation also involving taxonomy.
I think the bug is something simple: for example a language check that is based on the output of language_list() instead of FeedsProcessor::languageOptions().

Though it seems like a lot is failing, there are only two tests failing here:

1. Feedsi18nTaxonomyTestCase::testAvailableProcessorLanguageSetting()
2. FeedsMapperMultilingualFieldsTestCase::testAutocreatedTermLanguage()

@PaulDinelle
Would you like to improve your patch and investigate the two failing tests? The changes provided in this patch would be useful to have for finalizing #2320781: Validate feed importer configuration: check for invalid bundle and invalid language.

Reroll. Probably still needs work though.

When running the Feedsi18nTaxonomyTestCase::testAvailableProcessorLanguageSetting() locally, it appears that it failed because of the following error:

Fatal error: Call to undefined function i18n_node_language_list() in /Users/youri/Sites/devdesktop/drupal7/sites/all/modules/workinprogress/feeds_dev/feeds/plugins/FeedsNodeProcessor.inc on line 45

The i18n_node_language_list() is in the submodule i18n_node, not i18n!

New patch.

A random test failure. Back to "Needs review".

This adds LANGUAGE_NONE as one of the options returned by languageOptions(). Also some small code cleanups.

I wonder if LANGUAGE_NONE as one of the options has any unknown impact. The tests will tell.

This adds a node_object_prepare() call for the dummy node. This is safer for modules that implement NODE_TYPE_BASE_language_list() (which is indirectly invoked by i18n_node_language_list()).

Committed #22 with a tiny change in FeedsProcessor::languageOptions(): when language_list() would return an empty result, no options would have been returned at all. Now at least LANGUAGE_NONE is still returned.