When importing QT .ts files the translation UI displays raw serialized values just like they are in .ts file with all the XML escape sequences like “'” and “<”.
That’s a *.ts file techinical implementation detail which should not be exposed to translators. Translators should see the decoded string and translated messages should be automatically xml encoded when exporting to *.ts files. Just like it happens when editing translations in “Qt linguist” software.
That’s not the only rule for properly serializing/deserializing strings in Qt .ts files. Qt has a couple of additional tags for serializing characters which XML strings can’t encoded natively. For example when pasting in ESC character into Qt lingust, it will get serialized in .ts file as <byte value=“x1b”>
<message>
<location filename="../dialogs/AboutDialog.ui" line="14"/>
<source>source text</source>
<translation>text<byte value="x1b"/><byte value="x1b"/>more regular text</translation>
</message>
Seems like Crowdin currently doesn’t support that at all and strips them out during import.
Note that this is different from situations where xml/html escaped strings are stored within translation file format which may or may not need xml escaping. With the later case resulting in double xml escaping. For example when using .CSV as translation file format, due to implementation details of the app translated strings might still contain HTML encoded characters. In such cases crowdin shouldn’t do the automatic encoding/decoding of HTML stuff since it isn’t part of format.
And it’s not like crowdin doesn’t encode special symbols during export, it does but in a weird way. Normally encoding on export without decoding on import would result escape sequences stacking during each import/export loop resulting in completely broken output. In case of Crowdin seems like it has some kind of heuristics of only encoding special characters if they are not already a part of something which looks like escape sequence. That just makes things more confusing.