Allow plugins to handle job settings

Seems fine. (although i don't really like the settings key - it says what it does.)

Same as with the other pseudo-setting:
This is nothing that is a real setting. So it should not clash with persisted (and user overridable) settings per instance.
It's more of a capability per translator plugin (type) and thus should go a level higher in the plugin_info data.

+++ b/translators/tmgmt_local/skills/tmgmt_skills.moduleundefined
@@ -258,14 +258,17 @@ function tmgmt_skills_field_update($entity_type, $entity, $field, $instance, $la
-    if (!isset($languages[$item['language_to']])) {
+    if (!isset($languages[$item['language_to']]) && !isset($added_languages[$item['language_to']])) {

This is from a different issue: #1915956

+++ b/ui/includes/tmgmt_ui.pages.incundefined
@@ -490,10 +490,20 @@ function tmgmt_job_form($form, &$form_state, TMGMTJob $job, $op = 'edit') {
+  // If requested custom job settings handling, copy values from original job.
+  if (tmgmt_job_settings_custom_handling($job->getTranslator())) {
...
+    $original_job = tmgmt_job_load($form_state['tmgmt_job']->tjid);
+    $job->settings = $original_job->settings;

I would expect we only do this if custom handling is disabled. Why do we need this magic special case here?

+++ b/tmgmt.moduleundefined
@@ -1032,6 +1032,25 @@ function tmgmt_provide_remote_languages_mappings(TMGMTTranslator $translator) {
+/**
+ * Determines if jobs for this translator plugin should have their settings
+ * handled by the plugin.

The first sentence shouldn't be longer than 80 characters.

+++ b/tmgmt.moduleundefined
@@ -1032,6 +1032,25 @@ function tmgmt_provide_remote_languages_mappings(TMGMTTranslator $translator) {
+ * @return bool
+ */
+function tmgmt_job_settings_custom_handling(TMGMTTranslator $translator) {

Missing a description line.

Agree that the way the patch handles that is strange. It is like that because the build submit function copies everything over by default. It is weird because it assumes that $form_state['job'] is *not* the same object as the one returned by the load function which I think is only true because it has been serialized/unserialized.

Instead, we should either get the settings *before* the submit helper function is called and then overwrite it with that or overwrite the method that is called on the UI controller (the function is just a wrapper of that) and handle it there. Actually, we could do both. Copy/overwrite the settings in that method.

See http://drupalcontrib.org/api/drupal/contributions!entity!includes!entity..., that function is just a wrapper for a function on the ui controller. I think it might make sense to move that logic into that method, then it's part of the "build entity from form state" handling.

Also, the patch still contains the unrelated language items change.

Changes look good, but looks like the patch is against your latest patch, not 7.x-1.x

+++ b/tmgmt.moduleundefined
@@ -1034,13 +1034,13 @@ function tmgmt_provide_remote_languages_mappings(TMGMTTranslator $translator) {
+ *   If job settings are to be handled by the plugin.

Wouldn't be worth of a re-roll, but I'd write "TRUE if job settings... ".

Please look into this.

+++ b/tmgmt.moduleundefined
@@ -1024,7 +1024,7 @@ function tmgmt_translator_labels_flagged($job = NULL) {
  */
 function tmgmt_provide_remote_languages_mappings(TMGMTTranslator $translator) {
-  $info = tmgmt_translator_plugin_info($translator->name);
+  $info = tmgmt_translator_plugin_info($translator->plugin);

Hm, is this related?

+++ b/ui/includes/tmgmt_ui.pages.incundefined
@@ -494,6 +494,13 @@ function tmgmt_job_form_submit($form, &$form_state) {
+  // If requested custom job settings handling, copy values from original job.
+  if (tmgmt_job_settings_custom_handling($job->getTranslator())) {
+    $original_job = tmgmt_job_load($job->tjid);
+    $job->settings = $original_job->settings;

If it needs to be like this, fine.

However, we should then use entity_load_unchanged('tmgmt_job', $job->tjid) to make sure that we have an unchanged entity and not the same object as the one we already have in $job. Should not be the case in most scenarios but doesn't hurt to be sure.

Thanks, commited.

This is all Greek to me (haha), but does this plugin allow users to add their own vendors for direct translation requests? Right now we have to export a batch of nodes and then send off.

mfinaly - tmgmt allows developers to do so.
This was a technical issue with a clear scope. If you have support questions, please open separate issues.