Validate language mapping selection

We cannot just say that there is no mapping for key X as in the UI we do not know that. There we just get the remote language mappings that

1) return an array which values and keys (local -> remote) are equal. This is either because it has not been configured or the translator's supported languages has the same language codes.

2) return an array that has different values and keys.

To check if mappings are configured we can use the supported remote languages and check if they apply. But this is not that simple as we have the file translator, which should allow to input anything.

For a remote translator we can check if we have any supported remote languages and if not instead of the mappings form we display a warning. When we get to the phase when there are the supported languages we can check if the remote language is among the supported which should prevent the case when there is nothing selected for a local language. However for the file translator the thing with supported remote languages should be dropped.

When it comes to the duplicate check, there I am confused a bit. You either allow to save duplicate values, which means they get into the form and you can display a warning, or you validate the input which means you will not get duplicates when the form shows up. I implemented the message as there might be a case when two languages (like en_US and en_UK) are on the same site and if translating with i.e. gengo they get only "en".

Also we have an UX issue for remote translators for which we fetch supported languages. The credentials and the mapping form are supposed to be configured at one time initially. But that does not work as there are no remote languages. So for now I disabled the mapping form part unless we successfully get the remote languages list. Of course, this needs to be overridden for the file translator.

Please see the initial patch.

+++ b/plugin/tmgmt.ui.translator.inc
@@ -29,26 +33,65 @@ class TMGMTDefaultTranslatorUIController extends TMGMTPluginBase implements TMGM
+      $options = array('und' => t('Undefined'));

Should use LANGUAGE_NONE instead of 'und'

Testing this out a bit...

- When you create a new translator, you get a red error message in case the default-selected translator needs authentication or something before being able to give you the language mappings. The same when you select one for which this is true. We should probably check that first before displaying an error
- It also results in no mappings showing up at all for them. As mentioned above, there are use cases where we want to do the mapping "manually", like the file translator
- The validation doesn't seem to work for me, edited a gengo translator and chose "en" twice for en and fr and didn't get any validation error.

Please check:
- configuring mappings is possible even though we do not have any supported remote languages
- in case there is a local language without remote (either not configured or local lang code not present among supported remote languages) we display a warning that this language does not have target language
- if there are more than one local langs with same remote we do not allow to save the form with an error
- if the remote lang list has been updated and we fail to find locally saved remote lang code among supported remote languages (in the form) then we reset this to "und" and we display the warning saying that it is not possible to translate into that language. However this will not happen dynamically without loading the form currently.

Will continue with tests if you are fine with the implementation.

Tests provided.

The form part with lang mappings now looks good. But we still have a UX issue when configuring the api connection to remote service. Take gengo for instance - when you first view the form you get an error message from the gengo api that the key provided is wrong. This is due to the call to get supported languages. Along with that error message you get the warning that none of your languages is configured. So you fill in the gengo credentials and save. At this moment all is wrong because the mappings have been saved as "lang code" => "und". But user is not aware of this as gets redirected to the translator list with a green message that settings saved. To fix things up the user needs to reopen the form, select appropriate languages and save.

This problem is caused by the fact that part of the form relies on having the api connection working. We could introduce a condition that the api connection must be configured prior to have all the other settings show up. But this is definitely for a followup and probably cannot be solved only within tmgmt.

Something that I've thought about already for other cases is a "Test connection" button, that you could press to verify your entered configuration, then we could also use that to update and properly initialize the language mapping settings. But that's a separate issue...

11: validate_language_mapping-2256959-3.patch queued for re-testing.

This doesn't really improve the situation.

1. Create a new translator.
2. Select Gengo
3. Warning message, and no suggestions, obviuosly, but textfields default to 'und'.
4. Enter API keys, save.
5. Edit again, now it is a select, but for all languages, Undefined is preselected and saved.

So the automatic detection never jumps in. That can't be the solution...

In D8 the limitation to only support a single target language once for all mappings was removed in
#2257033: Allow multiple local language variations with one single remote language

I think we don't need to check that in Drupal 8, as we use the selector and it already check if the selected option was one of the given options.
This is the error that shows if we try to add an element that is not in the list:

I found a case that it maybe needs validation, and it's in the plugins that use api-key and you can only get the remote languages with this api-key.
It leads to an error, but this needs to be validated in the plugins as we need to check that after checking the api-key, not before.
Here is the error:

So here we need to modify the TranslatorPluginUiInterface to add a method called pluginSettingsFormValidate() that the plugins need to implement to validate the settings form.

ok, I opened the issue #2568887: Allow the Plugins to add validations for the settings form