wrong return format when loading plugin controller

This is currently by design. It arguably might be bad design but it can't be changed that easily. If you don't pass a plugin name in then you get a list of all controllers.

I don't like it either, but it's neither a bug nor critical. If we want to improve it then probably in the wrapper functions.

This was related to
#1916422: translator name is missing when creating new translator

Note that during the ajax call, in the referred issue, the $controller was array instead of the object itself (although the loading name was empty, i guess).
So the return type was different and that resulted in fatal error (calling function on non-object).

If we stay that way, we'll need to make sure all occurences of loading guarantee to contain a valid string

$controller = tmgmt_translator_plugin_controller($translator->name);

Note that this is - in combination with our translator form settings creation, and the combination with possible ajax actions on that form, really bad design - as most translator implementations risk to create fatal errors... that are currently uncovered by tests (and really hard to cover).

See attached patch.

In case the translator does not exists, we should not provide the mapping feature anyway. Also I updated docs for tmgmt_translator_plugin_controller() as before it clearly stated that it returns only the translator plugin object. Based on this I implemented the faulty logic.

+++ b/includes/tmgmt.ui.incundefined
@@ -212,10 +212,11 @@ class TMGMTDefaultTranslatorUIController extends TMGMTPluginBase implements TMGM
+    $controller = tmgmt_translator_plugin_controller($translator->name);

By specification, the bug is not that tmgmt_translator_plugin_controller returns an array, but much more that it expects a translator name while here $translator->name is empty. So we should avoid this call in this case.

Finally the following is the real problem, as by your patch above, all new translators will end up with disabled language mappings.

class TMGMTDefaultTranslatorUIController extends TMGMTPluginBase implements TMGMTTranslatorUIControllerInterface {
...
  public function pluginSettingsForm($form, &$form_state, TMGMTTranslator $translator, $busy = FALSE) {
...
    // Else make sure the FALSE value will be preserved.
    else {
      $form['map_remote_languages'] = array(
        '#type' => 'value',
        '#value' => FALSE,
      );
    }

Update the function that checks if language mappings should happen to follow the plugin controller info instead of the instance settings.

./tmgmt.module-1026-function tmgmt_provide_remote_languages_mappings(TMGMTTranslator $translator) {
./tmgmt.module:1027:  if (!isset($translator->settings['map_remote_languages'])) {
./tmgmt.module-1028-    return TRUE;
./tmgmt.module-1029-  }
./tmgmt.module-1030-
./tmgmt.module:1031:  return $translator->settings['map_remote_languages'];
./tmgmt.module-1032-}

map_remote_languages should never end in settings of a translator.

Please also make a difference in written text between translator (instances) and the plugins.

Please see the patch

+++ b/includes/tmgmt.entity.incundefined
@@ -212,11 +212,7 @@ class TMGMTTranslator extends Entity {
+    $this->getSetting('map_remote_languages');

In my opinion, map_remote_languages is no setting. It should be read from the plugin_info directly.

Please see the patch

Much better. Please fix the test fails and then let's pass to Berdir to finally commit.

Please see the patch

Committed, attributed to blueminds, pushed.