[Webkit-unassigned] [Bug 149056] [GTK] Spellchecker rejects word when adding a period character if there is no trailing space before the next word

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Feb 17 11:19:09 PST 2016


https://bugs.webkit.org/show_bug.cgi?id=149056

Michael Catanzaro <mcatanzaro at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://userguide.icu-projec
                   |                            |t.org/boundaryanalysis

--- Comment #11 from Michael Catanzaro <mcatanzaro at igalia.com> ---
(In reply to comment #10)
> wordBreakIterator seems to be pretty smart actually: not breaking on every
> punctuation mark seems to make sense in some languages as the punctuation
> marks can be considered part of the word itself (kind of as a word
> construction mechanism).

It doesn't seem smart to me, if it's not actually able to detect word breaks properly. A punctuation mark might occur inside a word in some languages, but if it's followed by a space, then surely it is always a word break character? I haven't looked at this closely, but I suspect we are somehow misusing the ICU API, as I'd like to think it's smart enough to handle this. At least, detecting word breaks properly is a standard feature of GtkTextIter, so I would expect ICU to be able to do it as well. If we can't figure it out, might need to look at what GtkTextIter is doing.

> That being said, this creates bugs when checking the spelling of sentences
> with a poor syntax (like ones with no space after a period or a colon), but
> this is a spell checking bug, not a word breaking one.

In that case, I would expect the spellchecker to flag the word foo.bar as misspelled.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160217/0dec58a4/attachment.html>


More information about the webkit-unassigned mailing list