Translation job submitted with mixed-language source text

Seems a severe bug to me. Source is source and should never contain any translated item.

There is plan to add a feature to deal with changes but it will never behave that way. It will present the diffs to the editors when creating the job.
This however will not be introduced by TMHMT OHT but TMGMT core instead.

However, can you please provide a clean description on how to reproduce this? (step-by-step conditions, settings chosen)
We need to reproduce this easily to fix it.

I assume you're using entity translation?

Could be that we are somehow fetching the wrong field values from the source. Maybe some sort of language fallback configuration that gets in the way?

Something to help track this down would be to try another translator (e.g. file export or the test translator) if this is something that happens in TMGMT core.

Also, I think you known translatable fields/entity translation quite well, I suspect the error is in text_tmgmt_source_translation_structure() in tmgmt_field.module. We're calling field_language() there, which is probably wrong as something could change it to English.

Thanks!

Wondering if we should already pass the field values in the correct language to the hook, that would simplify that a lot.

Yes, I like this, looks much easier, I know that @swentel is doing some crazy things on saving the values back, see #1428900: Provide a hook for field types when populating translations., maybe check with him to see if this would affect him sowhoe.

+++ b/sources/entity/tmgmt_entity.plugin.incundefined
--- a/sources/field/tmgmt_field.api.php
+++ b/sources/field/tmgmt_field.api.phpundefined
@@ -16,6 +16,6 @@
  *
  * @ingroup tmgmt_source
  */
-function hook_tmgmt_source_translation_structure($field_name, $entity_type, $entity, $field_instance) {
+function hook_tmgmt_source_translation_structure($field_name, $field_values, $field_instance) {

I guess we need to update the api docs here, in case we actually have some :)

+++ b/sources/field/tmgmt_field.moduleundefined
@@ -64,7 +67,8 @@ function tmgmt_field_get_source_data($entity_type, $entity, $field_translation =
-    if ((!$field_translation || $info['translatable']) && $data = module_invoke($info['module'], 'tmgmt_source_translation_structure', $field_name, $entity_type, $entity, $field_instance)) {
+    $field_values = field_get_items($entity_type, $entity, $field_name, $source_langcode);

The fact that this did pass the tests might mean that we don't need that $field_translation flag anymore. Need to look at it again in detail. If that's so, the we can throw it away completely.

And we should also add some test coverage for this.

bforchhammer asked me to quickly chime in. I'm fine with the changes, I can still do what I want with the code I have in a custom project, I just need to track this in case the api changes :) However, you never know someone really really wants to check something on the entity object - although I can't think of a use case at this point, so I guess that's for the tmgmt's maintainers to decide.

Right, so what about this. We use the same arguments as hook_field_formatter_view() except $display, which means "$entity_type, $entity, $field, $instance, $langcode, $items". The advantage of that:

- $items is right there and easy to use
- If needed, you get all the information you need, the entity, language, field and field instance to do all kinds of crazy things
- It is familiar to everyone who is used to write field formatters/types, and that's developers likely do if they have to implement this hook.

I have a strange fail locally, let's see if this works here.

Great, commited and documented in http://drupal.org/node/1873034.