Translating entire Storyline files with an alternative method

Dear Storyline 360 powerusers / Articulate support team,

[forgive my clumsy English]
My name is Manuel, and I work for a cat-tool editor/language service provider.
I am currently exploring new ways of having storyline files translated.

Quick reminder
To get a .story project file translated, there is only one 'official' way wich consists in exporting the content to be translated as an XLIFF file or a DOCX file, translating the latter, and reimporting it into Storyline 360.

Unfortunately, with this method, some contents are not exported into the translation file -- namely, the Text-To-Speech elements(TTS). And anyone who ever had to do it knows it is a tedious and time-consuming job to copy-paste each TTS into a text file, have it translated, then reinsert it and update the audio and subtitles.

As a LSP, we are always trying to optimize our translation processes and propose enhanced services to our customers. So, to get rid of that time-consuming TTS handling step, we decided to translate the translatable content directly from the slide[...].xml files compressed within a .storyline project file. To make sure we do not corrupt anything else in the slide[...].xml files, we have our CAT-tool (Computer-Aided Translation tool) protect all the non-translatable data. (There is more to it, but let me just skip the technical details, here.)

And... success! With this method, we were able to translate all the translatable content, including the TTS. We do not even need to set a new language + voice for each TTS, because during a 'post-translation' step, we automatically convert the 'original' TTS properties (language + gender + voice name/id) into 'target' TTS properties.

This is great, but there is still room for optimization. One thing that annoys us is that we have to "force" the recreation of the audio file + subtitle(.mp3 + .vtt within the .story file). To do so, after the translation and post-translation step are complete, we currently open the TTS for edition, insert an extra space in order to have Storyline believe the content is changed (otherwise, the content will not be updated) and click on the "Update" button. Not an optimal handling, but a lot of DTP editing work needs to be performed on a translated .storyline project file, anyway.

Yet, up to several hours of work per translated file could be saved if it was possible to regenerate all the audio + subtitiles at once, which, as far as I know, is not possible in Storyline 360. That is why we are now trying to improve our very special processing of .storyline project files -- an evolution of our process that will include target language MP3 + VTT automatic regeneration.

And again, we did it!
- a colleague of mine developped an app that rebuilds an audio stream using the target language + voice name + TTS content through AWS "Polly" API (this very API is used by Storyline 360 to generate the audio), then saves it under the right name as a mp3 file.
- the translatable content from the .vtt files is made available for translation in our CAT-tool.

Hurray!... Still, there is an annoying glitch (and that is the reason for this long message): although the content of the "unconventionally" translated .storyline file no longer contains source language TTS, the source audio content of the same TTS can be heard upon publication and -- sometimes -- when performing a preview.

- To work around the issue, I tried to clear the Storyline cache files :
+ c:\Users\<username>\AppData\Roaming\Articulate\Storyline
+ c:\Users\<username>\AppData\Local\Temp\Articulate\Storyline\
+ c:\Users\mbe\AppData\Local\Articulate\360\ApiCache\
It did not suffice: the "phantom" source audio kept reappearing upon publication
I thought an old version of the source audio might remain in the .story project file, so I searched high and low but could not find anything suspicious.
I just do not understand how: it either means the old source audio is somehow hiding in the .story file (but I thoroughly searched for any trace of the original audio or the original text -- not the slightest hint of anything), or it means there is another cache, somewhere, somehow (I searched hard but could not find it).

- For those who might wonder: I looked into the temp folder used for building the publication (eg: c:\Users\<username>\AppData\Local\Temp\Articulate\Storyline\5oPaU2GP1u5\story_content\5qkiLe6ifXF.mp3 and 5qkiLe6ifXF.wav and temp1.wav \Preview\story_content\5qkiLe6ifXF_44100_112_0.mp3). There, the audio file contained the target language audio. But under the publication folder (eg: d:\...\test Storyline output\story_content\5qkiLe6ifXF_44100_112_1.mp3) , the audio file contains the source language audio!
- The only way I could work around this "phantom cache issue" was to publish the translated .story project file from a PC with a fresh Storyline 360 installation and on which the source language .storyline project was never opened. But this is not an acceptable workaround, because when we deliver the translated .story file to the customer, we can be certain they will have an issue upon publishing.
- This issue disappears if we open each TTS for edition, add an extra space in order to have Storyline believe the content is changed (otherwise, the content will not be updated) and click on the "Update" button. But that is not a solution: this is just what we currently do.

So please let me know if you have any idea at all about how I can get rid of that "phantom" source audio from reappearing. Or if you know about a mysterious cache I missed.

By the way, I am using Storyline 360 V3.66.28270.0

Thanks if you went that far and read my message!
PS: I attached two files -- a proof-of-concept -- to illustrate what I described:
- test_diapo_simple_1tts_01.story >> original storyline file. Open that file and publish it.
- test_diapo_simple_1tts_01trad.story >> translated storyline file. Open that file and publish it : the audio will remain in English though it's been translated into French and though the MP3 is up to date.