SUMMARY In an en-US text, the spell checker correctly treats an em dash (U+2014) without any spaces around it as a word boundary, but the selection region that appears when right-clicking on a misspelled word does not. STEPS TO REPRODUCE 1. Open an XLIFF file with a target language of en-US. 2. Input "Karamzin—are" (or any other sequence of <non-dictionary word>, U+2014, <dictionary word>, without any spaces in between) into the translation box. 3. Observe the red underline under the first part and right-click on it. OBSERVED RESULT A menu with possible corrections pops up. Both words and the em dash between them is selected. EXPECTED RESULT A menu with possible corrections pops up. Only the first word, up to the em dash, is selected. SOFTWARE/OS VERSIONS Linux kernel: 5.0.5-arch1-1-ARCH KDE Frameworks Version: 5.57.0-1 Qt Version: 5.12.2-1 ADDITIONAL INFORMATION An obvious approach here would be to select whatever is has a red underline, but it seems to me that instead a generic word boundary routine of some sort is invoked, so there's no guarantee that it actually has the same idea of what a word is. (Fixing that routine to recognize em end en dashes as word boundaries would be nice, but the proper solution _here_ would seem to be to use the region provided by the spell checker.)