Include existing translation content in file translator export file

Sounds like a useful idea, but not trivial to implement. We would need to extend our source interface to allow to extract an existing translation.

Here is a patch implementing this feature.

It modifiesTMGMTSourcePluginControllerInterface::getData() implementations to also load existing translations. And adds TMGMTSourcePluginControllerInterface::getExistingTranslationData() which, in default implementation, just fetches existing translations from the data.

Local translator module is extended to load existing translations on the moment of local task creation. File translator loads existing translations by default, because they are already in the data array.

Some ideas for this implementation:
- add a setting for this feature
- somehow mark the existing translations in the UI (and maybe in file also), so translator will understand from where the text came

Leksat, your patch works perfectly, thank you very much!

In an early version of TMGMT, the target was the source language. This seems not helpful.

The idea to pass existing translations into the target was already provided in other issues. (need to search for it in the queue... references appreciated.)
However, with XLIFF, we figured out that target HTML integrity is very important.
If you add a new paragraph or add new semantic tags, things get odd:
The tags on source and target differ.

The CAT tool Trados, for instance would reject importing such a XLIFF document since source structure does not fit the target structure.
As a solution, this plugin would need to drop the provided existing translation and could not output it.
Hint: Trados has an own translation memory and can/will apply what is already known. However it would not be notified about website review last minute changes and might switch the translation to something that was fixed in Drupal outside of the Trados workflow.
Thus tagging, xliff, due to the relationship.

In any case, i think the problems described is an XLIFF workflow problem and TMGMT core should do what you suggest so other translators can benefit of it.

Did not check the patch yet, but yes, being able to get existing translations from a source is definitely something we want to be able to do.

It's probably not even an XLIFF workflow problem, it is a Trados workflow problem. So we should probably just add an option for this in the translator settings.

Maybe we can add a flag to the #translation in the data array, something like #existing_translation = TRUE or so. not sure if Xliff has a way to support this, but in the local translator, we could highlight those fields and show a notice or so in the UI.

This needed a re-roll.

Also allow a pre-existing translation of the summary to be exported (for text with summary fields).

Patch applies and works as expected.

+++ b/tests/tmgmt_test.plugin.source.inc
@@ -57,6 +57,11 @@ class TMGMTTestSourcePluginController extends TMGMTDefaultSourcePluginController
+    if (variable_get('tmgmt_test_load_existing_translation') && $job_item->getJob()->target_language) {

The variable to add existing translations is only tested in the test source.
But it is not checked in any other location.
If this is optional to export, then it should be an xliff file translator setting... to determine if we add it to the output.

Does this mean that if we create a job, we always add the source original and target language?
(This makes followup jobs double in size.)
If we need a global switch, then TMGMT should optionally fetch the source translation if enabled or skip it.
I think this would require us to extend SourcePluginInterface::getData() with an optional second parameter $with_translation.

The patch in #9 worked great for us! Thanks to everyone for the work!!!!! Really made my day. :)

Changing title slightly for more clarity.

This patch still applies, with some offsets.