Bug 107765 - CALC: Switching language during spell-check doesn't change the text's language property
Summary: CALC: Switching language during spell-check doesn't change the text's languag...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.2.0.4 release
Hardware: All All
: medium minor
Assignee: Kohei Yoshida
URL:
Whiteboard: target:7.4.0
Keywords: bibisected, regression
Depends on:
Blocks: Spell-Checking
  Show dependency treegraph
 
Reported: 2017-05-11 09:15 UTC by Justin L
Modified: 2022-05-07 14:57 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
CalcSpellCheckLanguage.ods: two pairs of US/UK spelling differences (7.13 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-05-11 09:15 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Justin L 2017-05-11 09:15:30 UTC
Created attachment 133231 [details]
CalcSpellCheckLanguage.ods:  two pairs of US/UK spelling differences

During spell checking, you have the option to change the language dictionary for a specific word. The character language properties are changed once you run through the spell checker.  So running the spell check a second time finds no errors. That broke in LO4.2 for Calc.

It was broken by Kohei Yoshida.  Bibisect42max has a range of commits that fail to start at this time, so I couldn't fully bisect.  The first proven bad is https://cgit.freedesktop.org/libreoffice/core/log/?id=2528e5d9058dc7b88a55fcc69226161bccec2691&qt=range&q=6c5c0302f3624ec7c3b862c98d5514f29328bbe9

The last proven good commit is 4bc3a58a648f6c0ce95b4eb41f2cbf46175629ed, just before Kohei's spell-checker related Calc changes.

Testing procedure:
-open CalcSpellCheckLanguage.ods.  [Default Language is English US. Labour and neighbour are marked as misspellings.]
-run the spell checker.  On the misspelled words, change the Language to English UK within the spell-checker dialog.
-run the spell checker a second time.  There should be no errors, and the character font properties of those words should be marked as English UK.
Comment 1 Justin L 2017-05-11 09:19:50 UTC
CC: Kohei

separated as a clean bug report for issue raised in bug 104197.
Comment 3 QA Administrators 2018-12-07 03:47:21 UTC Comment hidden (obsolete, spam)
Comment 4 Justin L 2020-04-03 08:51:37 UTC
still a problem in 7.0 master
Comment 5 QA Administrators 2022-04-04 03:31:04 UTC Comment hidden (obsolete, spam)
Comment 6 Justin L 2022-04-25 18:30:09 UTC
My guess is that it is from 5f62f8e19d07c795b98ca85350b00b5d1edef3e2
    Auto spell-check is no longer done in ScDocument.

where we now call pViewSh->ContinueOnlineSpelling() instead of doing something at the document level - which did have some language code in it.

Another good place to check is sc/source/ui/view/spelldialog.cxx's ApplyChangedSentence()
Comment 7 Kohei Yoshida 2022-04-28 01:24:30 UTC
If you scroll out the A1:A4 cells out of the visible range then scroll back so that the range becomes visible again, spell check gets re-applied for the visible range with the new language.

To fix this, simply detect the language change when the Options dialog gets closed, and re-run the spell check for the current visible range.
Comment 8 Justin L 2022-04-28 04:25:05 UTC
(In reply to Kohei Yoshida from comment #7)
> If you scroll out the A1:A4 cells out of the visible range then scroll back
> so that the range becomes visible again, spell check gets re-applied for the
> visible range with the new language.
That does not work for me. Plus, if I check format / Character on the word, the language for the char run is still USA, not the UK that I changed it to via the spell checker.  Running the spell-check again finds the same "problems".
Comment 9 Justin L 2022-05-03 18:13:19 UTC
what was lost was the command
pDoc->SetEditText(ScAddress(nCol,nRow,mnTab), mpEngine->CreateTextObject());
Comment 10 Justin L 2022-05-04 07:44:36 UTC
Well, if http://gerrit.libreoffice.org/c/core/+/133804 passed all tests, then I might have been comfortable enough to submit it, but obviously there are caches that need flushing or whatever.

Kohei, can you take it from here? I'm already way over my head and can't accept responsibility for anything in this code.
Comment 11 Kohei Yoshida 2022-05-05 02:05:23 UTC
(In reply to Justin L from comment #10)
> Well, if http://gerrit.libreoffice.org/c/core/+/133804 passed all tests,
> then I might have been comfortable enough to submit it, but obviously there
> are caches that need flushing or whatever.
> 
> Kohei, can you take it from here? I'm already way over my head and can't
> accept responsibility for anything in this code.

I can't make promises, but I'll add it to my list.
Comment 12 Kohei Yoshida 2022-05-05 02:49:58 UTC
cc: Dennis Francis
Comment 13 Kohei Yoshida 2022-05-05 22:09:20 UTC
Is there a way for me to get the build for 4bc3a58a648f6c0ce95b4eb41f2cbf46175629ed?  I need to play around with it a bit to see what the expected behaviors are.
Comment 14 Aron Budea 2022-05-06 00:09:12 UTC
Kohei, yes, that commit is in the 42max Linux bibisect build (need to download ~8 GB):
https://wiki.documentfoundation.org/QA/Bibisect/Linux#42max
Commit hash is: 8a4b1155a3be0401fc82b6713a56efe48cb42717

You may need to start LO with gen VCL plugin: SAL_USE_VCLPLUGIN=gen ./soffice
Comment 15 Kohei Yoshida 2022-05-06 02:38:42 UTC
(In reply to Aron Budea from comment #14)
> Kohei, yes, that commit is in the 42max Linux bibisect build (need to
> download ~8 GB):
> https://wiki.documentfoundation.org/QA/Bibisect/Linux#42max
> Commit hash is: 8a4b1155a3be0401fc82b6713a56efe48cb42717
> 
> You may need to start LO with gen VCL plugin: SAL_USE_VCLPLUGIN=gen ./soffice

Thanks. That worked.
Comment 16 Commit Notification 2022-05-07 02:53:54 UTC
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/f15e6293cf78d67963a6e512f60a11ae58da72c5

tdf#107765: Check the updated language and apply it to the cell.

It will be available in 7.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 17 Commit Notification 2022-05-07 14:49:07 UTC
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/ce911276b87b86b58c45ac4b7e9f5226a7ef95c5

tdf#107765: Use the correct sheet index.

It will be available in 7.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 18 Kohei Yoshida 2022-05-07 14:57:28 UTC
These above two commits combined should fix this issue.

ScConversionEngineBase::FindNextConversionCell() is the method that gets called whenever the user fixes the spelling error (either by changing the spelling or changing the language), and applies the change to the cell.  I simply added an additional check for the language change in order to apply it as needed.

The spell check code will either make use of the language attribute directly stored in the edit-engine string (in case the language is applied to a segment of the string), or cell attribute's western font language in case of a normal string, where the entire string has the same language applied.