Created attachment 201393 [details] Example Dictionary File Description: There is a "Grammar By" column in the user-defined dictionary. The idea, from my simple understanding as a user, is that the user can assign a word already in the dictionary for the user-added new word, so that the new word can have the same inflection forms (such as plurals for nouns) as the "Grammar By" word. For example, if I add "New Yorker" to my dictionary, I can put "worker" in the "Grammar By" field so that the spellchecker knows "New Yorkers" is just the plural form of the word I just added. Since 24.8, when I edit (or just view) my custom dictionary, the "Grammar By" column is not aligned to their corresponding word anymore, and is instead all aggregated to the top of the dictionary. The functionality of spellchecking based on custom dictionary doesn't seem to be affected. I haven't tried adding new words yet. Steps to Reproduce: 1. Download the attached custom "Example.dic" file and place it in the user/wordbook/ dictionary. (Or alternatively, create a user-defined dictionary and add these custom words.) 2. Open the Options dialog with "Tools > Options", then edit/view this dictionary at "Languages and Locales > Writing Aids" page, by choosing "Example [English (USA)]" in the "User-defined Dictionaries" and clicking "Edit..." button. Expected Result: The "Chinese" entry in "Grammar By" column should correspond to "Shanghainese". The other two words have no "Grammar By" companions. Actual Result: "Chinese" goes to the "Huangpu" entry as it is the first word in the dictionary. "Shanghainese" has no "Grammar By" word. Version Information: Bug seen in both 24.8 and 25.2. Just reproduced with: Version: 25.2.4.1 (X86_64) / LibreOffice Community Build ID: 09303ce8b49f86f106fccd32b1324662053027cc CPU threads: 12; OS: Windows 11 X86_64 (10.0 build 26100); UI render: default; VCL: win Locale: zh-CN (zh_CN); UI: en-US Calc: CL threaded Works fine in: Version: 24.2.7.2 (X86_64) / LibreOffice Community Build ID: ee3885777aa7032db5a9b65deec9457448a91162 CPU threads: 12; OS: Windows 10.0 Build 26100; UI render: Skia/Vulkan; VCL: win Locale: zh-CN (zh_CN); UI: zh-CN Calc: CL threaded So likely a regression in 24.8. P.S.: I am not a native speaker, and only an infrequent user of user-defined dictionaries. I may be not using the correct terms. Please ask for clarifications if anything is unclear.
Can you please upload 2 images (before and after) that shows the difference?
Created attachment 201396 [details] Good (expected) screenshot (version 24.2.7)
Created attachment 201397 [details] Bad (malfunctioning) screenshot (version 25.2.4 RC1)
bibisected with linux-64-24.8 Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 00e2762c664614a1b33f54dfc990ba29f0f81a07 CPU threads: 2; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: ja-JP (ja_JP.UTF-8); UI: en-US Calc: threaded ae1fce6565fabcf79e4ff10f62dcbca7849b4caf is the first bad commit source 00e2762c664614a1b33f54dfc990ba29f0f81a07 commit 00e2762c664614a1b33f54dfc990ba29f0f81a07 author Mike Kaganski <mike.kaganski@collabora.com> Mon Apr 29 01:31:19 2024 +0500 Drop uses of css::uno::Sequence::getConstArray in cppuhelper .. cui where it was obsoleted by commits 2484de6728bd11bb7949003d112f1ece2223c7a1 (Remove non-const Sequence::begin()/end() in internal code, 2021-10-15) and fb3c04bd1930eedacd406874e1a285d62bbf27d9 (Drop non-const Sequence::operator[] in internal code 2021-11-05). Change-Id: Ia2b60af973183bbe79656e67b5e37d7efa39a308 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166817 adding CC: Mike Kaganski Please, take a look?
https://gerrit.libreoffice.org/c/core/+/192055
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f5cd16a252a73a3e594fc19eba365c52ec987fbb tdf#167143: set text of the correct row It will be available in 26.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.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/fb8332fd4ac068835ba3a6557e8a67c5a5006559 tdf#167143: set text of the correct row It will be available in 25.8.3. 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.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/890e71b105c8bbcb2512aaef289b1b13b3e115fe tdf#167143: set text of the correct row It will be available in 25.2.8. 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.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-25-2-7": https://git.libreoffice.org/core/commit/7ed9d7a9f8692bd4fc95cf7c77949ec467316a90 tdf#167143: set text of the correct row It will be available in 25.2.7. 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.