neila carneiro

neila carneiro said:

I have read about this issue is known to SDL at least since 2005. 

That would put it before the development of Trados Studio, so a long standing problem indeed.  I think the most common solution to these problems is to add a BOM to the files before preparing them for translation.  This is fairly trivial to do and normally avoids the issue of there being an incorrect encoding in the target file.  XLIFF files are normally assumed to be UTF-8 if the encoding is missing, but I guess you don't really mean XLIFF files as the file in question in your screenshot was an XLSX.  So you are probably referring to changing the encoding in an SDLXLIFF which I have never had to do... as far as I can recall.

I can't recall having this problem myself with Excel files either, and your language pair doesn't look problematic. Importing into Excel can be tricky as Excel isn't that great at handling some languages, but perhaps you can share a source file, or at least a sample of one, so we can test?

Dear Paul,

Many thanks for your prompt reply!

Maybe in the post from 2005 on Proz.com, they meant Trados only, before it was Trados Studio. Back then, it was Trados Benchmark, I think. And SDLX. I worked with both. 

So sorry if I didn't elaborate it better, I read so many things today about this, I can't really pinpoint the thread. I am sure it was a thread from 2005 on Proz about encoding and Trados. 

That being said, the problem is:

I will deal with over 125 xliff files, UTF-8 (without BOM) and Studio adds the BOM.

Here is an example of the source xliff file: 

And a screenshot with  xliff files in package... 

Target: 

I had to manually change 28 files, since I could not find a way to do it in batches. 

Dear Paul,

Many thanks for your prompt reply!

Maybe in the post from 2005 on Proz.com, they meant Trados only, before it was Trados Studio. Back then, it was Trados Benchmark, I think. And SDLX. I worked with both. 

So sorry if I didn't elaborate it better, I read so many things today about this, I can't really pinpoint the thread. I am sure it was a thread from 2005 on Proz about encoding and Trados. 

That being said, the problem is:

I will deal with over 125 xliff files, UTF-8 (without BOM) and Studio adds the BOM.

Here is an example of the source xliff file: 

And a screenshot with  xliff files in package... 

Target: 

I had to manually change 28 files, since I could not find a way to do it in batches. 

neila carneiro

ok - so it is XLIFF files.  I guess part of your problem is there is no declaration in the XIFF ad the correct behaviour according to the XLIFF specification is this:

http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#Specs_XMLDecl

So without a declaration it's assumed UTF-8 and this probably means adding a BOM since this is the only way to tell a parser to treat the file as UTF-8.  Why is the BOM a problem?

neila carneiro said:

I had to manually change 28 files, since I could not find a way to do it in batches. 

Many tools can do this for you, but a very easy way would be to use the File Encoding Converter which we have on the AppStore.  Unfortunately there is no access to the appstore at the moment due to a problem but we hope to have a solution in place by the end of the week and will make sure this app is available.

Many thanks again for your explanation, article, and app suggestion.

All I know is that these xliff files were exported from Pendo. 

I have asked the team to check if the BOM will create problems or not for this project.  

You gave me a better answer than Google today, and that is rare. :-)

Dear Paul, 

Many thanks in advance again. 

Pardon my ignorance, ¯\_(ツ)_/¯ but... 

1 - The source file shows UTF-8 without BOM in Notepad, but there is no option to generate a UTF-8 without BOM in Sdl Studio?

2 - If the file type is text, I can choose to keep BOM or not... 

I read the declaration part, and I understood that this should be the file declaration or not:  

<xliff version="1.2" xmlns="urn:oasis:names:tc:xliff:document:1.2"><file original="0K8TlYX0gAfQRYULHMY6Qly2Yas" datatype="pendoguide" source-language="en-US" target-language=""><body><group id="Vu_KttQblCOOPe6qbyG6_IKUwjI"><note></note><trans-unit id="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx|ariaLabel">

So, if Pendo export the file and does not add something (pendoquide is not valid, I imagine) or something else, Studio will add BOM to the UFT file. 

I really appreciate any tip you can give me. 

Warm regards, Neila  :-) 

neila carneiro

I think I already answered these questions in my original comment.  But feel free to ask which parts you don't understand specifically?

On the File Encoding Converter.  This is now available on the Private AppStore we published this afternoon.  

You can find a wiki here that explains how to get set up to use the Private AppStore:

community.rws.com/.../private-appstore

The FEC application is free, and it's a very comprehensive application as you'll see.

Paul said:

This is now available on the Private AppStore we published this afternoon.  

Good News
-your time.. 

Congrats.. Lots of people wated Long time..

hmm, I have tried RWS App downloading several minutes ago.

Nothing is easy.

Out of curiosity.. what is the " server outage " means ? a little bit more specifically ?

Kelly Edward said:

hmm, I have tried RWS App downloading several minutes ago.

Nothing is easy.

Presumably you didn't read the wiki on what a "Private AppStore" is?

Presumably you didn't consider the version2017 customers.

Kelly Edward 

Not presumably... we did consider them but don't have an alternative solution at the moment.  Some apps are downloadable through the traditional appstore, some are not and you'll get this message.  This is still  work in progress.

But I was very clear about what we provided so you are just trying something that we know doesn't work.  Good luck to you.

Paul said:

This is still  work in progress.

again.. "Get Well Soon"