https://bugs.documentfoundation.org/show_bug.cgi?id=96787
Julien Nabet <serval2...@yahoo.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
CC| |dirk....@t-online.de,
| |serval2...@yahoo.fr
Assignee|libreoffice-b...@lists.free |serval2...@yahoo.fr
|desktop.org |
--- Comment #21 from Julien Nabet <serval2...@yahoo.fr> ---
On pc Debian x86-64 with master sources updated today, I could reproduce this.
I tried with the example of tdf#139377 where Dirk (I put in cc) would like to
avoid LO from replacing "daß" by "dass".
After deleting the entry, LO still does the replacement even after having
restarted LO.
If we take the example of German language from Germany, the initial replacement
file (ie with a brand new LO profile) is "acor_de.dat" present in "share"
directory.
Just for information, these dat files are in fact zip files with a specific
structure, see:
julien@debianamd:/tmp/test$ ls
acor_de.dat
julien@debianamd:/tmp/test$ mv acor_de.dat acor_de.zip
julien@debianamd:/tmp/test$ unzip acor_de.zip
Archive: acor_de.zip
extracting: mimetype
inflating: DocumentList.xml
inflating: META-INF/manifest.xml
inflating: SentenceExceptList.xml
inflating: WordExceptList.xml
When deleting an entry in the autocorrect dialog and click Ok, LO generates
a "acor_de-DE.dat" in "user" directory this time.
This "acor_de-DE.dat" contains all the replacements from "acor_de.dat" except
the deleted entry.
Important thing to note: "acor_de.dat" in "share" doesn't change and still
contains all replacements (included "daß"=>"dass")
Remark: the extra "-DE" in the file name is because I used Germany locale. If I
switch to Austria locale for example, it will use initial "acor_de.dat" from
"share" so it won't use "acor_de-DE.dat" from "user" directory)
After some debugging, I noticed that the type of replacement "daß"->"dass" was
done in SvxAutoCorrect::SearchWordsInList
(see
https://opengrok.libreoffice.org/xref/core/editeng/source/misc/svxacorr.cxx?r=40e98c87#1920).
1) it begins in the block:
1932 // First search for eLang, then US-English -> English
1933 // and last in LANGUAGE_UNDETERMINED
1934 if (m_aLangTable.find(aLanguageTag) != m_aLangTable.end() ||
CreateLanguageFile(aLanguageTag, false))
1935 {
1936 //the language is available - so bring it on
1937 std::unique_ptr<SvxAutoCorrectLanguageLists> const& pList =
m_aLangTable.find(aLanguageTag)->second;
1938 pRet = lcl_SearchWordsInList( pList.get(), rTxt, rStt, nEndPos
);
1939 if( pRet )
1940 {
1941 rLang = aLanguageTag;
1942 return pRet;
1943 }
1944 }
gdb showed that pList.get() used "acor_de-DE.dat" (from "user") and when
searching "daß", it doesn't enter if block at line 1939 as expected.
2) But then LO keeps in the next block:
1946 // If it still could not be found here, then keep on searching
1947 LanguageType eLang = aLanguageTag.getLanguageType();
1948 // the primary language for example EN
1949 aLanguageTag.reset(aLanguageTag.getLanguage());
1950 LanguageType nTmpKey = aLanguageTag.getLanguageType(false);
1951 if (nTmpKey != eLang && nTmpKey != LANGUAGE_UNDETERMINED &&
1952 (m_aLangTable.find(aLanguageTag) != m_aLangTable.end()
||
1953 CreateLanguageFile(aLanguageTag, false)))
1954 {
1955 //the language is available - so bring it on
1956 std::unique_ptr<SvxAutoCorrectLanguageLists> const& pList =
m_aLangTable.find(aLanguageTag)->second;
1957 pRet = lcl_SearchWordsInList( pList.get(), rTxt, rStt, nEndPos
);
1958 if( pRet )
1959 {
1960 rLang = aLanguageTag;
1961 return pRet;
1962 }
1963 }
and here pList.get() shows "acor_de.dat" from "share".
So when searching "daß", it finds the replace (since "acor_de.dat" isn't
changed when deleting an entry)
I'm gonna propose this straightforward patch:
diff --git a/editeng/source/misc/svxacorr.cxx
b/editeng/source/misc/svxacorr.cxx
index ae6dceb33adf..0f048114462b 100644
--- a/editeng/source/misc/svxacorr.cxx
+++ b/editeng/source/misc/svxacorr.cxx
@@ -1941,6 +1941,8 @@ const SvxAutocorrWord* SvxAutoCorrect::SearchWordsInList(
rLang = aLanguageTag;
return pRet;
}
+ else
+ return nullptr;
}
// If it still could not be found here, then keep on searching
If a correspond acor file is found in user, it goes into 1) like previously but
instead of keeping on with 2), if there's no replacement found, it returns
nullptr.
I tested this patch with a brand new LO profile (so without "acor_de-DE.dat"),
the replacement works since we don't enter the first if of 1) and so we go into
2).
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
