Adding dfaure since he has more experience here.

But I've dug into it and I've confirmed that there are mimetypes for both linguist .ts and mp2t .ts files in shared-mime-info (1.4), and that both types also have proper 'magic' in /usr/share/mime/magic.

I'm not sure how ties are broken in the event two possible mimetypes match a filename pattern, but at least on my system Dolphin properly treats a sample .ts file I downloaded as a movie, not as a Linguist XML file.

If you have updated shared-mime-info packages then the only way I can see a KDE bug here is if we're calculating the 'tiebreaker' wrong (whether that's by using file magic or something else).

My shared-mime-info is 1.2-3.3 and that is highest official version in newest openSUSE 42.1 Leap :(

I updated shared-mime-info to version 1.5 but unfortunately this problem STILL EXISTS !!!

It's still a problem with shared-mime-info 1.6 too (Leap 42.2).  I suspect very strongly that the shared MIME info is not the problem, but - assuming the magic numbers are correct - the problem is that the checking fails.

What is worse: there is no way to change the default (Plasma5 5.8).  If I remove "*.ts" from the linguist definition using System Settings, it is still there the next time I go in.  The method used to override system MIME settings is not working.

The default itself is also unreasonable: the number of users who want to watch videos/TV they've recorded will far outweigh the number who use Qt Linguist.  That said, this point is irrelevant if magic number checking is working.

Is this still a problem?

This is not quite fixed properly (Plasma 5.19.5 on openSUSE 15.2).

Dolphin will now correctly differentiate for local files, but _not_ for 'sftp://' - it wants to open MPEG files with Linguist.  The same is true for 'webdavs://'.  I haven't tested other IO slaves.

For 'file://', I notice that Typescript files are also correctly identified as plain text, despite sharing the same '*.ts' naming.

I can reproduce by simply navigating to a dir with typescript files, they all are message catalogs and open with linguist.
Moving the bug to KIO.

I am not quite sure what can be done about this though. Determining the mimetype when multiple types have the same file suffix involves downloading a portion of the file and looking for a magic sequence of bytes. For obvious reasons we do not do that on non-local slave types as we'd flood the network and server with a gazillion requests when entering a directory with a gazillion files. Because of that the only information we have to go on is the suffix, meaning only one type can win even when there would be multiple candidates.

Would it be possible to respect the user preference for application order?

Do you mean application order associated with a mimetype? That is already honored, the trouble is we get the wrong mimetype.
That being said as a workaround a user could mangle that mimetype by either unassigning the suffixes or simply adding the desired applications.

> Determining the mimetype when multiple types have the same file suffix involves downloading a portion of the file and looking for a magic sequence of bytes. For obvious reasons we do not do that on non-local slave types as we'd flood the network and server with a gazillion requests when entering a directory with a gazillion files.

While this is true, it may or may not be a problem, and may even be preferred behaviour.  If I'm going across the Internet, it causes problems.  However, when I access files on a local server across a gigabit LAN, I'd like the option to have the gazillion requests made.

Dolphin already does this, based on file size. Preferences->General->Previews: "Skip previews for remote files above" (size).

Would it not be possible to use the same setting to determine whether to perform magic number checking?  At least, can data obtained for previews not also be used for magic numbers?

Perhaps, in lieu of a better solution.