[EXCONTRANS-377] Tasks per language * per workspace for batches with multiple resource nodes Created: 07/Jun/22  Updated: 04/Oct/22  Resolved: 04/Oct/22

Status: Closed
Project: Content Translation Extended (CTX)
Component/s: Core
Affects Version/s: 3.4.5
Fix Version/s: 3.4.6

Type: Improvement Priority: Medium
Reporter: Florian Kugler Assignee: Teresa Miyar
Resolution: Workaround exists Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

Current:

When creating translationBatches with many resource nodes (mgnl:translationResource) from different workspaces and multiple target languages the module currently creates a task for each resource node per language. While EXCONTRANS-370 already reduced the amount of tasks created it still can produce a huge amount of tasks. 

Steps to reproduce: 

  • Use i18n-lm.zip attached to EXCONTRANS-370
  • Create N folders under root
  • Create items for each folder
  • Add folders to translation batch and submit

Having a batch with N different resource nodes and 5 target languages we still get N x 5 tasks. 

Expected result:

  • 5 tasks, 1 for each language
  • (with 2 workspaces involved e.G. dam): 10 tasks, 1 per workspace per language 


 Comments   
Comment by Riste Drangovski [ 07/Jun/22 ]

Current logic is that for each resource node in the batch and for each target language we create a new submission item.
If we want to change this logic we'll need to rework maybe 80% of the module. So we can say that changing this logic is too much work.

As a workaround (based on the scenario/steps to reproduce the issue):
All folders can have one parent folder. Add main parent folder to translation batch.

Comment by Florian Kugler [ 08/Jun/22 ]

Hi Riste, 

thanks for the update!
That means that no module rework is planned at all or have you added this topic to your backlog for later implementation? 

Best regards, 
Florian

Comment by Riste Drangovski [ 08/Jun/22 ]

Hi Florian,

Because this involves a lot of effort on our side (it's not a small change) and I don't see this as bug (it's how it is by design), we need to discuss this internally. I guess, me or Teresa will give you update (in the next couple of days), if this is something that we are going to work on or leave it as it is.

Regards,
Riste

 

Comment by Florian Kugler [ 08/Jun/22 ]

Hi Riste, 

thank you for the info, I will wait for your decision then

Best regards, 
Florian 

Comment by Teresa Miyar [ 10/Jun/22 ]

Hi Florian,

We have investigated your request. In Magnolia, we work with hierarchical data. This means that whenever you would export anything from anywhere (be it a workspace, directly from the content app, etc.), it will need a hierarchy to be able to create a document (YAML or XML) out of it.
This is the reason why the core Content Translation module only allows selecting one item to export at a time.. This is also why in Content Translation Extended each item is treated as a single submission whenever you add items to the batch.
As a workaround, we recommend that you put the items in a folder.
If you find this functionality crucial for your project and want us to develop this specific feature for your company, we can discuss a Custom Feature Implementation. You may contact our Professional Services Manager, @cass, or your local Customer Success Manager, Jemima, to discuss the possibilities.

Regards,

Teresa.

Comment by Florian Kugler [ 07/Jul/22 ]

Hi Teresa, 

thank you for your detailed answer! We will think of developing a custom implementation with those specific needs on our side then, since the workaround provided does not work in our project setup.

Thanks for investigating!

Regards,
Florian

Generated at Mon Feb 12 00:30:38 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.