Hi dann jung

Thank you for your clear area of concern

In case you did not know this is what the different break symbols mean 

What is the actual source file? Clearly the source content has been processed differently.
Without a bit more context such as file type, segment text and what follows I would be guessing.

Regardless its clear your file type settings are different to the translator and it would require ensuring you are using the correct file type and that your settings match theirs.
Screen print below is just an example but as you can see it can be extensive.



With this in mind, it is possible to share file type settings by selecting the native file type (source file format) and exporting the settings.

This means what you can import them and have all the detail around content processing match.



I hope this helps a bit


Lydia 

dann jung

out of interest, since you have the professional version what happens if you use PerfectMatch instead of the TM?

Too bad the images are gone.

It appears to be a difference between soft and hard line breaks (returns).

My source files were CSV files. The first one had an empty target column. That's the one which I started the project with, with the soft returns.

When I added an updated file with new keys, 50% didn't match because the source segments now contained hard returns. There was nothing different between the line endings as seen in Notepad++ with "Show all symbols" on ([CR][LF] in both files).

I was able to solve (thank the heavens) this annoyance by adding an empty target column to a copy of the new CSV using LibreOffice Calc. Because the new file for some reason didn't have one, so it was one column "short".

SDL has problems handling columns that don't exist during CSV import.

Perhaps disabling/changing the target column to an existing column in the import settings could have fixed that as well.