Mohamed Zeid said:

Also, is there any logical explanation of such issue in the first place?

+1
I would like to know the root cause of this as well. I've seen this problem many many times, but was never able to get to the root cause of it (mainly due to lack of knowledge on the translator's side - they were never able to precisely describe what exactly they did on their side... usually they "did nothing", of course...).
And all the posts here in forum were always focused on getting the result, never on understanding (and preventing) the cause :(

To resolve your issue, you can e.g. create a TM from the translated file, the creating new project using the untranslated source file and pre-translate it from the TM you created. Eventually, if you have Professional license, you can use PerfectMatch instead of Pre-translation.

Evzen Polenka said:

I would like to know the root cause of this as well. I've seen this problem many many times, but was never able to get to the root cause of it (mainly due to lack of knowledge on the translator's side - they were never able to precisely describe what exactly they did on their side... usually they "did nothing", of course...).

I wonder if it's related to the original source being embedded in the sdlxliff or not?  Obviously you can't save the target if it's not embedded but perhaps the problem itself of the path relates to thi somehow.  It would be good to have the exact steps that the file went through since it's initial production so we could replicate it.

Paul said:

I wonder if it's related to the original source being embedded in the sdlxliff or not?

In my case the source was ALWAYS embedded into the SDLXLIFF. Though, sometimes I got back file(s) with this temporary file path inside the SDLXLIFF instead of the embedded source.
And even, for example, one or two out of ten files were "corrupted" this way and the rest was okay... all files returned from a single translator.

Paul said:

Obviously you can't save the target if it's not embedded but perhaps the problem itself of the path relates to thi somehow.  It would be good to have the exact steps that the file went through since it's initial production so we could replicate it.

Yeah, but since the only information I could ever get from translators was that they "did nothing special" (of course, user never does anything... everything always happens just by itself... :-\ ), this is a no-go.
I would rather expect some clear explanation from the SDL side, since only SDL knows exactly what is Studio doing internally (I mean, when exactly can the embedded information get lost and be replaced with a path to temporary file, for example).

Mohamed Zeid said:

2) It was translated by a translator using SDl Trados Studio 2015

The point is to know every little details of this step - every little click and operation the translator did here.

Mohamed Zeid said:

6) I created the same path on my machine trying to trick SDL Trados Studio

When you say "path", do you mean only the path (i.e. folder), or did you also put any file in there (with exactly the same filename which Studio complains that it's missing)?
It's necessary to put the original untranslated source file there, but with exactly the same filename which Studio wants to be there.

Mohamed Zeid said:

I also found out that the segmentation was different this time. Some of the bigger paragraphs were segmented in sub-segments, so Perfect Match or CM match was not auto-populated from the TM. Not sure if the translator used a different segmentation, but I really doubt it.

And I truly believe the opposite - that the translator DID use god-knows-which weird process (i.e. also segmentation)...
That would not be suprising when the resulting SDLXLIFF file was so "corrupted"...

Mohamed Zeid said:

Here is also the stack trace, it could help.

The error message is weird. It would suggest that you have put some incorrect file in the created path.

Hi Mohamed Zeid,

I have run some tests in trying to reproduce the issue that you have mentioned here.  To avoid any misinterpretation, can you please confirm the steps that I have mentioned underneath.

Steps
1. Create a new project in 2019 SR1
2. Add a single xlsx file.
Q 1: Is the *.xlsx file embedded in the SDLXLIFF file?
3. Complete the project creation.
4. Created a Studio Package and provided it to the linguist.
Q 2: Did you provide the linguist with SDL Studio Package, target SDLXLIFF file and or the original source file (*.xlsx), or simply the entire project?
5. Your understanding is that the Translator opened the studio package, translated the file and provided you with the translated file.
Q 3: Is there a reason why the linguist did not provide a return package?
Q 4: Any additional pre-processing done by the linguist?

Tip: you can configure whether the native file is embedded in the SDLXLIFF file by updating the setting mentioned here

Given the information you provided, I have deducted that your case is best aligned with the following scenario; if different, please advise.

Scenario

PM:
•    Created a project in Studio 2019 SR1 with a single *.xlsx file
•    *.xlsx embedded in the SDLXLIFF file
•    Created a SDL Studio Package
Linguist:
•    Opened the package and translated the file
•    The linguist did not create a return package; instead sent the translated SDLXLIFF file
PM:
•    Copied the translated SDLXLIFF file back into target folder of your project, overwriting the existing file.

Observations
In this scenario, the only case where I can see it being reproducible is when the translated SDLXLIFF file that you receive from the translator is recreated from the native file.  The original path of the reference file is defined when the file is created and relevant when not working with an embedded native file. 

From the tests that I carried out, the original path was not updated when simply providing translations in the SDLXLIFF file. However, I was successful in updating this original path information, when creating a new project from the native file, as follows:
•    Open the studio package
•    Open the file in the editor and select the option File>Save Target As
•    Create a new project from the native file.

Note: In this user-case, it can also be seen that additional complications may occur; including variant segmentation & whether or not the native file is embedded with the creation of the new project, which might lend itself to the issues noted by Evzen Polenka.

Tip: You can verify if the base64 encoded string of the embedded file is validate from here: https://www.base64decode.org/. Simply create a separate file with only the base64 encoded string and upload it, under the section: ‘Decode file from Base64 format’.