https://bugs.kde.org/show_bug.cgi?id=406652
Bug ID: 406652
Summary: Spell checker and pop-up menu have different ideas of
what a word is
Product: lokalize
Version: 18.12.3
Platform: Archlinux Packages
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: editor
Assignee: sdepi...@gmail.com
Reporter: ashpil...@gmail.com
CC: sha...@ukr.net
Target Milestone: ---
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.)
--
You are receiving this mail because:
You are watching all bug changes.
