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.
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
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!
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.
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.
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.
(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
(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 :-)). > ...
*** Bug 141951 has been marked as a duplicate of this bug. ***
*** Bug 140739 has been marked as a duplicate of this bug. ***
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.
*** Bug 145187 has been marked as a duplicate of this bug. ***
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.
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.
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.
(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!
(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).
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).
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
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
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
The bug is still present in 7.5.1.1
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
*** Bug 154045 has been marked as a duplicate of this bug. ***
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