Localization Framework Hub and Spoke architecture - retranslation

[Hardik10]

I have implemented Hub and Spoke architecture for Localization framework. The key problem I came across is when the value of the field is changed. 

For example: Catalog Item has Name and short description field. When we create a new record and then request for translation, the spoke instance will send to hub and retrieve translation from hub. Then we publish it. In Hub, we have set auto-translate and auto-publish. 

Now, later stage, we need to make a small change to Name or short description and we will request the translation again. This will send the text with its translated value in payload to hub. Hub will see that this record already has the translated value, and it will not re-translate it. Now, even in spoke instance, I remove the lock and retrieve the translation, it will provide me the old translation only from Hub. So, this looks like a limitation that it will not be able to identify or not allowing to re-translate. This would be bigger challenge as the some of data keep changing, of course not frequently.

[Alex Coope - SN]

I'll need to have a think about that, because creating such a BR could prove tricky both from a performance perspective and a app scope perspective.

I don't think any such logic needs to be on every table (there is another way), but I would need to validate the above 2 items first before I make any suggestions,

Many thanks,
Kind regards

[Hardik10]

Sure @Alex Coope - SN , i will wait for your response. Again, thank you for answering our queries on short time. Much appreciated!! 

[Hardik10]

Hi @Alex Coope - SN , do you have any more information - Force retranslation on hub & spoke and current architecture on value change.?

[Alex Coope - SN]

Hi @Hardik10,

This isn't really a "hub & spoke" question, it's more to do with when to generate an LFtask and what to do with previous values in the subsequent task that's generated. 

Could you generate a new LFtask automatically? - yes, it's absolutely possible to generate these via various means but like I've said previously this could prove quite challenging to ensure you get the right time every time. For example, just on a "value change" could prove quite the challenge if a double update to a record is made in quick succession.

The next challenge is what to do with the previous value held in the generated LFtask record and ensuring it still matches the source record for the subsequent translation. This is fine for some translation types (e.g. clearing that translation value for [sys_ui_message] but preserving the matching key, but it would prove problematic for [sys_translated] and maybe even [sys_translated_text] if the source sys_id also changed - which can happen in some areas of the platform),

So, suffice to say, it's incredibly complex currently - but it is still something we're discussing internally,

Many thanks,

kind regards