"Probability score": 0.7

"Question improvement suggestion": Please provide more details about the steps you took before encountering the issue, any error messages you received, and any troubleshooting steps you've already taken. Also, please mention if there were any recent changes to your system or software.

In the meantime, based on the information you have provided, here is a suggested answer to your question:

Hello,

It seems like you're experiencing an issue with the legibility of the XLIFF file in Trados Studio 2022 v 17.2.10. This could be due to a variety of reasons, including encoding issues or a problem with the file itself.

Here are some steps you can try:

Step 1: Check the encoding of the XLIFF file. It should be in UTF-8 format. You can check this in Notepad++ by going to the "Encoding" menu.

Step 2: Try opening the XLIFF file in another text editor to see if the issue persists. If it does, the problem might be with the file itself.

Step 3: If the issue is with the file, you might need to regenerate it. Make sure to save your work before doing this.

Step 4: If the problem persists, you might want to consider using a different method to transfer the file to your client. For example, you could try sending it as a TMX file instead.

Please note that there is a known issue (CRQ-27824) related to the corruption of TM when the Project Template and Language Pair during Project creation in Trados Enterprise do not match the language pair defined in the source file. Until this issue is fixed, please ensure that these match to prevent any issues.

I hope this answer addressed your question. If not, please reject the answer, add the question improvement suggestion information, and click the RWS Community AI checkbox on the right to try again.

RWS Community AI

"Probability score": 0.7

"Question improvement suggestion": Please provide more details about the steps you took before encountering the issue, any error messages you received, and any troubleshooting steps you've already taken. Also, please mention if there were any recent changes to your system or software.

In the meantime, based on the information you have provided, here is a suggested answer to your question:

Hello,

It seems like you're experiencing an issue with the legibility of the XLIFF file in Trados Studio 2022 v 17.2.10. This could be due to a variety of reasons, including encoding issues or a problem with the file itself.

Here are some steps you can try:

Step 1: Check the encoding of the XLIFF file. It should be in UTF-8 format. You can check this in Notepad++ by going to the "Encoding" menu.

Step 2: Try opening the XLIFF file in another text editor to see if the issue persists. If it does, the problem might be with the file itself.

Step 3: If the issue is with the file, you might need to regenerate it. Make sure to save your work before doing this.

Step 4: If the problem persists, you might want to consider using a different method to transfer the file to your client. For example, you could try sending it as a TMX file instead.

Please note that there is a known issue (CRQ-27824) related to the corruption of TM when the Project Template and Language Pair during Project creation in Trados Enterprise do not match the language pair defined in the source file. Until this issue is fixed, please ensure that these match to prevent any issues.

I hope this answer addressed your question. If not, please reject the answer, add the question improvement suggestion information, and click the RWS Community AI checkbox on the right to try again.

RWS Community AI

1 tried
2 tried
3 did it on several files
4 (likely) client would not accept. I had to negotiate somewhat to sell the idea of xliff.

JF Delannoy 

memoQ can handle SDLXLIFF.  That's the first thing.

Second thing is that the screenshot shows the base64 internal file that can optionally be included in the XLIFF to be able to recover the target file from just the SDLXLIFF (although the recovery would only work in Trados Studio since it's based on our file filters).  Scroll down and you'll see the bits you're probably expecting to see.

But if your client cannot handle these qhy not create your projects in Studio and then use the XLIFF manager to send them an XLIFF that is so simle any CAT tool can manage to work with it?

https://appstore.rws.com/Plugin/67

But keep in mind that if you are sending this to the client they surely were the starting point?  So they should have really converted the original source into a memoQ XLIFF and sent that to you for translation.  Then you would send them a translated file that made sense for them.

Probably something is amiss with your workflow here...

Note that this client has managed to integrate Xliff before.



Two-part xfliff file? Yes. After the garble part, there is a clear part. What use is the first part? How can I switch off the fabrication of the non-text part?



XlliffManager installed. Looks simple, but how do I apply it? (not documented). The menu does not propose to pick a file; with the File View or the Editor view I can't see any connection to XliffManager.

JF Delannoy 

JF Delannoy said:

Note that this client has managed to integrate Xliff before.

Please be clear... sdlxliff or just xliff.  Either way it should not be a problem, but looking at your screenshot it seems as though you were sent a DOCX, which you then prepared in Trados Studio.  You are then sending your client the sdlxliff.  What exactly are they going to do with that in memoQ?  It seems a very unusual and work creating workflow.

JF Delannoy said:

Two-part xfliff file? Yes. After the garble part, there is a clear part. What use is the first part? How can I switch off the fabrication of the non-text part?

It's actually just one part... it's a fully compliant xliff and the bit you don't like was put there by you when you created your project.  If you don't want to include the embedded source file then reduce this to zero before you create your projects:

JF Delannoy said:

XlliffManager installed. Looks simple, but how do I apply it? (not documented).

Just to help you understand what you're looking at, please refer to this part of the xliff specification:

https://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#internal-file

Then check the file again and note this part at the start of that section of the file:

<internal-file form="base64">

For the same client, I had already sent sdlxliff without problem, that I remember

Here he insisted more about the use of MemoQ. I started and it was so unwieldy...
I got four docx files
Ii did not tamper with tjem.
I processed them in Trados
I sent the sdlxliff output- NOK for the cliehnt.

#

To use XliffManager:
File view
right click
export

#

The xliff files (named ... sdlxlliff.xliff) are in
[project name]\XLIFF.Manager\Export\[Dateandnumber]fr-FR\     

#

I note that it is easier for the client to send me xliff files instead of docs.


Regads

JF Delannoy 

In your scenario, you might even help your client by sending a TMX created from your sdlxliff files.  At least that would easier to use to update their TM and then pre-translate the docx in memoQ.

But the TMX would cover the whole project.?
Here I want to cover only the four files, processed withing a larger project. 
Maybe copying and editing the copy of the TM to keep only the contribution of those files... Not keen...

JF Delannoy 

The TMX can cover whatever you like.  You could even make this easy on yourself with a number of apps:

https://appstore.rws.com/Plugin/56

https://appstore.rws.com/Plugin/113

These two can easily convert an sdlxliff.

But you could also create a new TM, add it to your project, select the four files in question, update them into your new TM, then export it to TMX. 

Plugin 113 to convert to TMX works.

I am proposing the client to send Word+TMX.