How to adapt xliff 1.1.-1-2 to lock Confluence "code" formatting

Question

Hello, 
 I'm using Studio 2024 and I'm struggling with efficiently translating xliff files exported from Atlassian Confluence xliff version 1.1.-1.2). 
 
 1. Exclude Code format from translation 
 There is a formatting option called "code" in Confluence, which leads to the following tags: 
 
 I want the xliff parser to lock these tags with "code" formatting. I tried with the following setting in the file type settings but there was no effect: 
 <[^>]*x-code[^>]*>

I did not change anything for the tag segmentation: 
 
 Can you help with the regex? I tried to avoid using the whole phrase because I'm alway unsure about escaping the " "... 
 Or is this the wrong place to make these settings?? 
 
 2. Exclude hyperlink texts from translation 
 I want to use the same approach to exclude link texts from translation, as Confluence (AFAIK) willl automatically use the page title as link text once translated. 
 -> So I need to exclude these texts as well: 
 
 -> but not those links where a custom link title is used:

I'm not very good at these regular expression things and I've wasted some time now on that so I hope you can help :-) 
 yve

Paul · Accepted Answer

Yvonne Rezbach You cannot use embedded content for this. In Trados Studio, tags are not treated as embedded content by default when using the standard XLIFF filetype. Unlike with custom XML filetypes where you can define embedded content rules, the XLIFF filetype does not allow you to configure specific inline elements like as lockable or non-translatable. While it is technically possible to process XLIFF files using the Monolingual XML or Multilingual XML filetypes (where embedded content rules could be defined to handle tags accordingly), this may not be desirable if you want to retain the built-in behaviour and features associated with the native XLIFF filetype in Trados Studio. Since you are using the XLIFF filetype where you don't have this flexibility, you could pre/post-process the XLIFF files in some way. A simple way to do this would be by using the mrk element with a protected attribute like this (image shows the original on the left and the changes on the right): So the pre-process would replace g elements that have the ctype="x-code" attribute with an mrk element that contains the mtype="protected" attribute. So instead of this: You would see this: Then reverse the change in the translated files afterwards. A pretty basic change that you could either encourage your client to do and send you files that are prepared this way, or you could do this with a simple search & replace. Easily done both ways, and could be scripted to handle multiple files in one go if needed.

Paul · Answer

Yvonne Rezbach I forgot to clarify the second part... The exclude hyperlinks could also be handled in a similar way. During XLIFF pre-processing you check like this in your search & replace: If a element has the attribute ri:page-content-title, treat it as a system-generated link and mark the entire content as locked. So, some proper examples... before:

I am a sentence formatted in code

I am code within a segment

Translation tests

I am a link to another chapter

After:

I am a sentence formatted in code

I am code within a segment

Translation tests

I am a link to another chapter

Then you get before: After:

Paul · Answer

Yvonne Rezbach 
 In case you can work with Python scripts I thought it would be a useful tool to be able to pre/post process a bunch of files in one go, so I used your example to do this and put the files here: 
 https://github.com/paulfilkin/Python-scripts/tree/main/xliff-lock-restore 
 Note: all created with the help of ChatGPT... so it is something within the reach of us mere mortals :-)

Trados Studio > 1. Trados Studio

How to adapt xliff 1.1.-1-2 to lock Confluence "code" formatting

Top Replies