Main Translation Process Bottleneck – Reasons
- Increased volumes of parts books to be translated
- 2nd or 3rd translation package needed to completely translate media
- Significant amount of translation requests for just a single language
Additional translation requests - Reasons
- Authoring process „exceptions“ causing need for retranslation
- Production partlists being iterated (e.g. to add / change modifiers)
- Production media being renamed (e.g. OMM name updates)
- Publishing failing if no new Xliff is generated and translated (for partlist or media)
- Media baseline used in publishing doesn‘t reference the modifier objects – so always using latest (with changed name / modifierString)
- Media rename doesn‘t iterate the object, so media baseline still valid, but information that was exported and translated through the Xliff is outdated
- In both cases Translation Dictionary doesn‘t have translation for latest strings, therefore publishing fails
- Current „process“ is to manually force creation of new Xliff (Support staff)
- Support staff must force Xliff regeneration
- Translation staff must request new package for whole media (even if just one partlist Xliff might have been updated)
Improvement Request
- Improve Management by throttling thread pool size for Main Translation Workflow queue
- Avoid MethodContext threshold being exceeded to avoid periodic stack trace
- Won‘t improve performance (stack trace only adds a few 1/10 seconds)
- Improve processes to avoid 2nd/3rd translation request for whole media
- Improve processing performance of Xliff generation (taking up most of the time spent in Main Translation Workflow)
- Refactor publishing customizations to separate code necessary for Xliff generation from code necessary for PDF / SISWeb publishing
- Reduce custom metadata processing for Xliff generation to the absolute minimum required to get all custom attribute values for translation
- OOTB Change to support parallel execution of Xliff generation
nslation Queue issue