Gengo plugin does not take into account duplicate text

Martin, can you please tell us how you deal with duplicates here?

Issam, i do doubt that this happens too often... I would guess that in reality parts are somehow quite often similar, while there's not too many cases where payload items are exactly identical.

One thing here: As soon as the i18n strings plugin is here, it will happen quite often with e.g. also Menu items or other things like views translations. These items are quite often repeating.

Issam: Note that "needs work" is for issues with patches that should be improved. We firs start with "active" as long as there's no code.

Hey,

this has never been implemented - the code even contains TODO for this feature. The problem is that it is not clear how to handle this situation due to our design. Will think about it and during today will provide ETA.

Sorry for late reply... been kinda busy at drupalcamp london :)

This can be now implemented as we keep track of the remote jobs, however this http://drupal.org/node/1901890#comment-6997836 has to make it in first. So what it takes is as follows:

- You need to use the latest tmgmt dev version with support of remote mappings
- The linked patch needs to make it in, however there must be an upgrade provided from the gengo specific mapping to tmgmt generic one
- If it all works, then we can implement functionality that in case of duplicate it will search in mapping table, find the job and pull the data of that job into duplicate one.

To sum up, it is not much coding, but still takes some time. My estimate is from 4 to 8 hours, so can be done fairly fast. Will talk to miro_dietiker about possibilities.

Ok, here we go.

Attached patch extends our mock service with this behavior and adds basic tests for this. Also fixes those tests but the fix is a bit... rough, not completely sure about it. But it seems to be working well.

@issam: Please test this, I think with the test coverage for this, we can get an initial fix for it in and later refactor and improve it.

Overlooked the @todo that @blueminds mentioned before. But that seems problematic, if you look at the output of the attached screenshot, you can see that it both has jobs and an offer_id and right now we don't process the order_id if there are any jobs returned it seems. Don't completely understand the logic there.

The advantage of my approach, while a bit more complicated has the advantage that we don't even send it as a job which means a smaller payload and less things to process.

Thanks for testing.

The correct state to set in this case is "reviewed and tested by the community", then I'll commit it and set it to fixed. Have a look at the linked documentation pages (see description help text below the select fields) for more details.

Commited and pushed.