Bug 141773 - Autocorrection for all languages doesn't work anymore
Summary: Autocorrection for all languages doesn't work anymore
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.0.5.2 release
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard: target:25.2.0 target:24.2.5 target:24...
Keywords: bibisected, bisected, regression
: 140739 141951 145187 154045 (view as bug list)
Depends on:
Blocks: AutoCorrect-Complete 153979
  Show dependency treegraph
 
Reported: 2021-04-20 09:33 UTC by Eduardo Martínez
Modified: 2024-07-02 11:36 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments
image showing tha autcorrection option for all languages (16.62 KB, image/png)
2021-04-20 09:33 UTC, Eduardo Martínez
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eduardo Martínez 2021-04-20 09:33:18 UTC
Created attachment 171304 [details]
image showing tha autcorrection option for all languages

At Autocorrect options, substitution characters marked to be used at "All" languages are not effective, as at last versions (it works until 7.0 version) it means that autocorrection words must be included at each language used. It's not practical because some expressions as ug (micrograms) or m3 (cubic meters) are useful at all languages.
Comment 1 Julien Nabet 2021-04-20 09:45:26 UTC
On pc Debian x86-64 with master sources updated today, I could reproduce this.

I don't reproduce this with LO Debian package 7.0.4.2
=> regression
Comment 2 Julien Nabet 2021-04-20 10:07:39 UTC
Regression from:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=ae56dc05b27f05ffcee99845d661a237e70a7a51
author	Julien Nabet <serval2412@yahoo.fr>	2021-01-09 20:47:24 +0100
committer	Julien Nabet <serval2412@yahoo.fr>	2021-01-10 09:38:23 +0100
commit ae56dc05b27f05ffcee99845d661a237e70a7a51 (patch)
tree cbc1c36d71ece12c4ea7d8e259bfcbd8d65176dc
parent 94e47e2d90096146f4cd909782d75375d286bed1 (diff)
tdf#96787: AutoCorrect: after deleting a replacement entry, it's still used
If specific acor<language>.dat exists in "user", don't use the initial one in "share"
since the initial one will still contain the deleted entry.

See detailed explanation here:
https://bugs.documentfoundation.org/show_bug.cgi?id=96787#c21
Change-Id: Ic349159c93d9fc327f38a1d4e8187e3bdc16d08a

:-(
Not sure how to fix this without breaking tdf#96787, what a mess!
Comment 3 Julien Nabet 2021-04-20 10:50:28 UTC
Eike: the patch I had done for tdf#96787 seems wrong.
I think adding another block in SvxAutoCorrect::SearchWordsInList (editeng/source/misc/svxacorr.cxx) after first one just to deal with the case "All".
However, it seems to correspond to "LANGUAGE_UNDETERMINED" and wouldn't like to interfere with 2 other existing blocks.
I noticed you had helped for tdf#58060, thought you might have some idea.
Comment 4 Julien Nabet 2021-04-20 12:27:56 UTC
With this patch this one is fixed without breaking the other:
diff --git a/editeng/source/misc/svxacorr.cxx b/editeng/source/misc/svxacorr.cxx
index ce1f788f593c..21c95bc6bc8d 100644
--- a/editeng/source/misc/svxacorr.cxx
+++ b/editeng/source/misc/svxacorr.cxx
@@ -1944,6 +1944,20 @@ const SvxAutocorrWord* SvxAutoCorrect::SearchWordsInList(
             rLang = aLanguageTag;
             return pRet;
         }
+    }
+
+    LanguageTag aLanguageTagUnd(LANGUAGE_UNDETERMINED);
+    if (m_aLangTable.find(aLanguageTagUnd) != m_aLangTable.end())
+    {
+        //the language is available - so bring it on
+        std::unique_ptr<SvxAutoCorrectLanguageLists> const& pList = m_aLangTable.find(aLanguageTagUnd)->second;
+        pRet = lcl_SearchWordsInList( pList.get(), rTxt, rStt, nEndPos );
+        if( pRet )
+        {
+            // TODO useful?
+            // rLang = aLanguageTag;
+            return pRet;
+        }
         else
             return nullptr;
     }

Now, I'm not sure if it's the right way.
Comment 5 Julien Nabet 2021-04-21 08:20:00 UTC
Xisco: I won't be able to fix this one. Should I revert patch from tdf#96787 ?

I'm asking the question because if I had to choose between having tdf#96787 fixed and this one fixed, I prefer having tdf#96787 fixed.
Of course, just personal opinion.
Comment 6 Xisco Faulí 2021-04-21 08:34:17 UTC
(In reply to Julien Nabet from comment #5)
> Xisco: I won't be able to fix this one. Should I revert patch from tdf#96787
> ?
> 
> I'm asking the question because if I had to choose between having tdf#96787
> fixed and this one fixed, I prefer having tdf#96787 fixed.
> Of course, just personal opinion.

Hi Julien,
Do we really need to choose one or the other? I would rather have both fixed instead.

@László Németh, you have done a lot of fixes to the autocorrect, I thought you might be interested in this issue
Comment 7 Julien Nabet 2021-04-21 08:45:51 UTC
(In reply to Xisco Faulí from comment #6)
> ...
> Do we really need to choose one or the other? I would rather have both fixed
> instead.
Obviously it would be better to have both fixed but I just mean I won't be able to fix this and don't know if someone would like to tackle them in a reasonable delay (not in some months/years :-)).

> ...
Comment 8 Xisco Faulí 2021-04-28 15:57:33 UTC
*** Bug 141951 has been marked as a duplicate of this bug. ***
Comment 9 Xisco Faulí 2021-05-10 16:20:12 UTC
*** Bug 140739 has been marked as a duplicate of this bug. ***
Comment 10 Joel Greenyer 2021-06-14 08:02:13 UTC
I'm experiencing the same problem in version 7.1.3.2 x64, Win 10 : all my custom "replace" AutoCorrect options that I configured [All] languages are not applied.

As a WORKAROUND I noticed that it works when I switch the language for the text in which the AutoCorrect should be applied to [None]. If the language is already [None] and AutoCorrect does not work, then switching to another language and then back to [None] makes it work for me.
Comment 11 Julien Nabet 2021-10-17 16:44:27 UTC
*** Bug 145187 has been marked as a duplicate of this bug. ***
Comment 12 tommy27 2021-10-17 17:12:41 UTC
I stumbled upon this bug today when I upgraded from 7.0.4.2 to 7.1.5.2
I can also tell the issue is still present in 7.2.0.0 too.
Comment 13 tommy27 2021-12-28 09:08:17 UTC
this is a serious bug... nasty regression and loss of a function many users rely on... I'm still stuck to 7.0.x because of this... has anyone tested it with the latest 7.2.x releasese? 7.2.0 was affected.
Comment 14 Eduardo Martínez 2021-12-28 12:59:32 UTC
At least at 7.2.4.1(x64)MS hasn't been corrected, it's necessary copy all the automatic corrections at all the languages used.
Comment 15 KeepTools 2022-01-01 11:22:29 UTC
(In reply to Julien Nabet from comment #7)
> Obviously it would be better to have both fixed but I just mean I won't be
> able to fix this and don't know if someone would like to tackle them in a
> reasonable delay (not in some months/years :-)).
It is a pity it _is_ taking months to fix this; unfortunately I'm not able to tackle the problem either. It was an elegant feature of LO!
Comment 16 Julien Nabet 2022-01-01 11:29:15 UTC
(In reply to KeepTools from comment #15)
> (In reply to Julien Nabet from comment #7)
> > Obviously it would be better to have both fixed but I just mean I won't be
> > able to fix this and don't know if someone would like to tackle them in a
> > reasonable delay (not in some months/years :-)).
> It is a pity it _is_ taking months to fix this; unfortunately I'm not able
> to tackle the problem either. It was an elegant feature of LO!

Again, feel free to revert the patch. Personally, I won't do it since I prefer tdf#96787 to be fixed instead of this one.
=> uncc myself since I don't know how to fix this one (without reverting the patch).
Comment 17 laurent.zmn@gmail.com 2022-01-06 19:41:20 UTC
Same bug for me. Downgraded to 7.0.4.2. Too bad!
Regarding the bug 96787, my workaround was to delete all the acor_xx-YY.dat files in my profile (not acor_und.dat).
Comment 18 tommy27 2022-01-08 08:09:30 UTC
I raised importance from medium to high

this is a nasty regression breaking a longstanding working feature of LibO that leads to an important loss of function.

many users who rely on the "acor_und.dat" file are now stuck with 7.0.x
Comment 19 Xisco Faulí 2022-01-14 16:02:02 UTC
Hi László Németh,
you did some work in the autocorrection area in the past, I thought you might be interested in this issue
Comment 20 tommy27 2022-01-16 14:00:45 UTC
I agree... Laszlo fixed so many annoying bugs about autocorrect...
I think he is the most appropriate developer who can try fixing this nasty one
Comment 21 Vincent Boudry 2023-03-03 16:20:04 UTC
The bug is still present in 7.5.1.1
Comment 22 Stéphane Guillou (stragu) 2023-03-14 13:40:03 UTC
Affects Linux too, not just Windows.

Was "assigned"; back to "new".

Still reproducible with a trunk build from today:

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 97a38dbfa998967c45efaf3303fedfa1a709a2bb
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded
Comment 23 Stéphane Guillou (stragu) 2023-05-22 21:49:16 UTC
*** Bug 154045 has been marked as a duplicate of this bug. ***
Comment 24 Vincent Boudry 2024-01-26 16:31:17 UTC
Still present in 

Version: 24.2.1.0.0+ (X86_64) / LibreOffice Community
Build ID: 753981dd0cbbdedeca4fa95681f6d65d370a758f
CPU threads: 8; OS: macOS 14.3; UI render: Skia/Metal; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Calc: threaded
Comment 25 Jordi 2024-06-22 18:51:57 UTC
Just switched over to Ubuntu and got hit by this nasty bug. 

Version: 7.6.7.2 (X86_64) / LibreOffice Community
Build ID: dd47e4b30cb7dab30588d6c79c651f218165e3c5
CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded


Show stopper for me. Back to Windows. :(
Comment 26 Commit Notification 2024-06-29 07:26:20 UTC
László Németh committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/50be3fa1f0f3b8870af5bda88b65f835ef37d77e

tdf#141773 AutoCorrect: fix broken [All] dictionaries

It will be available in 25.2.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 27 László Németh 2024-06-29 07:49:45 UTC
Fixed in master. Back-porting started in 24.8 and 24.2.

@Eduardo and all: thanks for the bug report and feedback!

Full commit descriptions, including the proposed fix for tdf#96784:

tdf#141773 AutoCorrect: fix broken [All] dictionaries

This reverts commit ae56dc05b27f05ffcee99845d661a237e70a7a51
"tdf#96787: AutoCorrect: after deleting a replacement entry, it's still used".

========================

tdf#96787 AutoCorrect: find item with ".*" and between :colons:

It was very hard to disable autocorrection of (c)->© and other
AutoCorrect items, because the searched Replace string "(c)"
etc. didn't jump the list cursor to the corresponding ".*(c)"
item.

Now skip ".*" pattern matching marks, also colon (emoji
replacement) characters, so the list cursor jumps to the
line ".*(c)"->© typing only "(c" etc., allowing users to press
Delete to disable its autocorrection without knowing about
the special AutoCorrect patterns.

Follow-up to commit 50be3fa1f0f3b8870af5bda88b65f835ef37d77e
"tdf#141773 AutoCorrect: fix broken [All] dictionaries".
Comment 28 Commit Notification 2024-06-30 15:07:04 UTC
László Németh committed a patch related to this issue.
It has been pushed to "libreoffice-24-2":

https://git.libreoffice.org/core/commit/65e755ebeb17d16a84465ba92fe0f8f5ea1aebd9

tdf#141773 AutoCorrect: fix broken [All] dictionaries

It will be available in 24.2.5.

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 29 Stéphane Guillou (stragu) 2024-07-01 05:38:27 UTC
Verified in:

Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 5bf58785ba2831de4efc2afe9df463b4a753ccb1
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL threaded

Thank you so much for looking into it, László! :)
Comment 30 Commit Notification 2024-07-01 10:42:20 UTC
László Németh committed a patch related to this issue.
It has been pushed to "libreoffice-24-8":

https://git.libreoffice.org/core/commit/5c8cda56c138f89396b9fd39cd39cdfc9b92c827

tdf#141773 AutoCorrect: fix broken [All] dictionaries

It will be available in 24.8.0.0.beta2.

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 31 László Németh 2024-07-02 11:36:35 UTC
(In reply to Stéphane Guillou (stragu) from comment #29)

> Thank you so much for looking into it, László! :)

@Stéphane: Many thanks for your quick review! :)