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.
CC: Kohei separated as a clean bug report for issue raised in bug 104197.
Regression introduced in range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=4bc3a58a648f6c0ce95b4eb41f2cbf46175629ed..6c5c0302f3624ec7c3b862c98d5514f29328bbe9
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
still a problem in 7.0 master
Dear Justin L, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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()
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.
(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".
what was lost was the command pDoc->SetEditText(ScAddress(nCol,nRow,mnTab), mpEngine->CreateTextObject());
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.
(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.
cc: Dennis Francis
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.
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
(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.
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.
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.
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.