Cyril A. 

Have you tried providing these target files to your client, or did you create the original powerpoint and then translate it?  Sometimes this is a result of different versions of Office and you might see a problem that your customer does not.

Hi Paul 
Same problem here.
We work with and all employees use the same Office version as it is deployed by our IT department.

When this problem occurs, we perform a TM export filtering the TUs according to the project number and create a local project specific TM. Then, we prepare a new project with the affected file(s) and pre-translate them using only the new project TM. Afterwards, we finalize this new project, delete the sdlxliff and the target file in the original project's target folder and replace them with the ones created in the local project.

It's a smooth but time-consuming workaround. If there was any other way to handle this issue, I would highly appreciate your advice.

Thank you

Seraina

Seraina Hartmann 

I'm not aware of another way.  I'm not even sure what causes this in the first place!

Hello Seraina Hartmann ,

With the risk of looking as dumb as our Community AI: why don't you update your Studio 2022 to 17.2.12? You never know!

Hi Gérard LAMBERT 
Thanks for your advice.

We are planning to upgrade to Trados Studio 2024; however, I tested this issue on UAT level and it presists with the newer versions as well.

Best regards

Seraina

Seraina Hartmann 

Gérard's advice is related to the Trados Studio 2022 version, since you are not using the latest available build.

Yours is: Trados Studio 2022 SR2 - 17.2.9.18688

The latest build is: Trados Studio 2022 SR2 - 17.2.12.19268

Thank you Jesús Prieto , I also tested with Trados Studio 2022 SR2 - 17.2.12.19268; to no avail.

Seraina Hartmann 

Can you send me four files:

1. the target file that does not open
2. the corrected target file that does
3. the translated sdlxliff that creates a non-opening pptx
4. the translated sdlxliff that creates an opening pptx

You can send them to pfilkin at sdl dot com if that's appropriate for you?

Hi Paul 
I shared the files through OneDrive this morning, my e-mails to you seem to not get through though.

Here's what I wrote:

Please find attached the files you requested.

This example seems to be linked to the segments containing e-mail addresses. We were able to generate a working pptx when not translating these segments.

However, there are various examples where the pptx cannot be opened where no e-mail addresses stick around in the source text.

I requested an other trial version for Studio 2024 today. I hope they will allow me to install it asap to test again.

Thank you for looking into this.

Best regards

Seraina

Seraina Hartmann 

Thanks Seraina, I downloaded the files and the solution is simple.  Run a tag check!  Go to segment #38 and you'll see that in the "bad" sdlxliff there are tag errors because the translator has the tags the wrong way around.  In your "good" file you actually left that segment blank (it was just an email address anyway).

So if you copy source to target for #38, or correct the tag order, or delete the target translation altogether, then the target file is fine.

Hi Paul 
Thanks for checking.

I see and I will keep my eyes open for another project that won't create a pptx that can be opened. I will share it as soon as I find one.

I reckon changing the tag order in some cases is necessary, though, e.g. to convey correct formatting to the target text?

I thought tags just need to be there in order to create a working target file, maintaining tag order is not crucial though?

Thank you for your thoughts on this

Seraina

Seraina Hartmann said:

I thought tags just need to be there in order to create a working target file, maintaining tag order is not crucial though?

It depends on the tags and what they do.  But generally:

1. Each purple tag in Studio represents a pair of markers in the underlying XML: one that opens the formatting (or hyperlink in this case) and one that closes it.

2. Those pairs must appear in a strict order:

   • Open A

   • Open B

   • text

   • Close B

   • Close A

   That way, the XML forms a tidy, tree‑like structure that PowerPoint can read.

3. In the faulty segment the order was swapped.
   The translator placed a “close formatting” tag before the hyperlink had finished. The sequence became:

   • Open A

   • Open B

   • text

   • Close A ← wrong place

   • Close B

   This creates overlapping tags, something the XML standard forbids.

4. PowerPoint therefore sees the slide as malformed.
   When it tries to open the file it detects the overlap, declares the slide corrupt and either (a) refuses to open the presentation or (b) removes the entire text box during its self‑repair step... and in this case the complete slide

5. Fixing the tag order restores the file.
   Put the tags back in the correct sequence, re‑export the PPTX, and PowerPoint opens it without complaint.

So looking at your specific file, since tag 60 is opened around tag 59 instead of inside it, the two pairs overlap rather than nest.  When Studio generates the underlying xml for the powerpoint file it converts this structure into DrawingML runs that overlap, and PowerPoint rejects the slide.  If you were to unzip the pptx and look at the underlying slide.xml you'll see lots of runs that carry the attribute 'dirty="1"'. These were produced while Studio tried to salvage the overlap but could not produce valid markup, so it flagged the runs as dirty .

So the shorter answer is... tag order does matter and you can easily validate this by running a tag verification, or pressing F8 when the file is open in the editor!

Seraina Hartmann said:

I thought tags just need to be there in order to create a working target file, maintaining tag order is not crucial though?

It depends on the tags and what they do.  But generally:

1. Each purple tag in Studio represents a pair of markers in the underlying XML: one that opens the formatting (or hyperlink in this case) and one that closes it.

2. Those pairs must appear in a strict order:

   • Open A

   • Open B

   • text

   • Close B

   • Close A

   That way, the XML forms a tidy, tree‑like structure that PowerPoint can read.

3. In the faulty segment the order was swapped.
   The translator placed a “close formatting” tag before the hyperlink had finished. The sequence became:

   • Open A

   • Open B

   • text

   • Close A ← wrong place

   • Close B

   This creates overlapping tags, something the XML standard forbids.

4. PowerPoint therefore sees the slide as malformed.
   When it tries to open the file it detects the overlap, declares the slide corrupt and either (a) refuses to open the presentation or (b) removes the entire text box during its self‑repair step... and in this case the complete slide

5. Fixing the tag order restores the file.
   Put the tags back in the correct sequence, re‑export the PPTX, and PowerPoint opens it without complaint.

So looking at your specific file, since tag 60 is opened around tag 59 instead of inside it, the two pairs overlap rather than nest.  When Studio generates the underlying xml for the powerpoint file it converts this structure into DrawingML runs that overlap, and PowerPoint rejects the slide.  If you were to unzip the pptx and look at the underlying slide.xml you'll see lots of runs that carry the attribute 'dirty="1"'. These were produced while Studio tried to salvage the overlap but could not produce valid markup, so it flagged the runs as dirty .

So the shorter answer is... tag order does matter and you can easily validate this by running a tag verification, or pressing F8 when the file is open in the editor!

Paul 
Once more, I learned a lot from your very elaborate answers.

Thank you so much for having taken the time to look into this and explain in detail. Makes perfectly sense and I now know what to look for if it happens again.

Thank you Paul, highly appreciated.