Hello,

The issue you're experiencing with unexpected spacing in target files when using a custom XML filetype in Trados Studio is likely due to the technology used for parsing and writing the file. Trados Studio uses Microsoft .NET XML libraries, which can sometimes add additional whitespace to self-closing tags, change empty tag pairs into self-closing tags, or alter the order of attributes.

While this behavior is inherent to the Microsoft .NET XML libraries and not directly controllable through Trados Studio, there are a few potential workarounds you might consider:

Step 1: You could try using a different XML parsing and writing library that doesn't add the additional whitespace. This would likely involve some custom development work.

Step 2: You could continue to use your current method of batch finding and replacing the additional spaces using a tool. While this is not ideal, it is a reliable way to ensure the spaces are removed.

Step 3: You could consider using a post-processing script to remove the additional spaces after the target file has been generated by Trados Studio.

I understand that this issue can be frustrating, and I hope one of these suggestions can help you find a suitable solution.

Best regards,

RWS Community AI

 Luca Pesenti 

Indeed I also cannot prevent these spaces being added.  Even adding xml:space="preserve" to the xml seems to be ignored.  I created a support ticket so support can take a look and if verified they will log a bug for resolution.

Case Details - 00830442 for reference.

Thanks Paul!

I also noticed that also quotation marks are affected. Single quotation marks (') are replaced with double (").

Hi Luca,

I have encountered the same behavior recently on XML2 file type. 

Not sure if the custom XML file type you created were based on XML2 as well?

Below is a KB I found with similar issue.

https://gateway.sdl.com/apex/communityknowledge?articleName=000019936

Regards,

William

Hi Paul Filkin

Do you have any update for us? This is quite problematic as we need to fix a lot of exported files in order to be able to re-import them
into the customer's system.

Looking forward to your feedback!

KR,
Julian

Julian Hamm 

Yes... apologies for not coming back.  I had an answer and forgot to tell you!  This is the outcome:

We fully embrace semantic functionality of the XML - this means for example, that these sort of things will not be considered bugs:

• reordering attribute values,
• automatic normalization of the whitespaces between element attributes (does not apply to attribute values),
• whitespace changes outside of the content,
• changing empty tags to selfclosed (<a></a> to <a/>)

This problem you have described fits into the "whitespace changes outside of the content” category, so our development team will not do anything about this.

In general I am of the opinion that there is "being technically correct", and "being customer correct", and sometimes I think we can be a little too rigid when it comes to handling customer specific data where the solution a particular customer may use is not capable of properly handling valid XML.  However, in this specific scenario I do think that the problem here is one that your customer should address.  The XML specifications, and plenty of discussion topics on technical forums discussing this sort of issue, conclude that whitespace is irrelevant and all apps should parse the file irrespective of whether there is an extra whitespace there or not.

I think, if this is problem that your customer won't address then I would run a script and just add the whitespace back into the files.  Probably trivial enough and given they seem to be able to handle the whitespace you could add this as a matter of course into every self-closing tag without having to do this manually for each file.

Hi Paul Filkin

Thanks a lot for your detailed reply, much appreciated! Ok, I'll let the client know so we can tweak things elsewhere.

KR,
Julian