SUMMARY Search is case-insensitive for non-accented characters, but it is case-sensitive for accented characters. STEPS TO REPRODUCE 1. Have an item with accented characters in its name, for example: česko, ČR, etc. 2. Search for the item once with the correct capitalization of the accented character, and once with the opposite capitalization. OBSERVED RESULT The item is not found when the capitalization of the accented character is opposite to the item name. EXPECTED RESULT If search is case-insensitive for ASCII characters, it should also be case-insensitive for accented characters. SOFTWARE/OS VERSIONS Windows: macOS: (available in the Info Center app, or by running `kinfo` in a terminal window) Linux/KDE Plasma: Zorin OS 17.3 Education KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Are you using Mysql or MariaDB database ?
Which search tool did you use in digiKam exactly ?
(In reply to caulier.gilles from comment #1) > Are you using Mysql or MariaDB database ? SQLite is set for the DB. MariaDB is not available among the choices in the settings. I'm willing to try out the Mysql internal DB, but only if following a migration manual.
If MySQL is unavailable, you're probably using a digiKam in the Flatpak package. However, using MySQL or MariaDB won't improve things for you, as MySQL generally ignores accented characters. Maik
(In reply to caulier.gilles from comment #2) > Which search tool did you use in digiKam exactly ? I identified two search modules and new issues: - the Search tab in the sidebar between Timeline and Similarity - the Advanced Search This issue concerns the Search. A search term with accents that returns some results in Search does not return any results in Advanced Search. I'll follow up with more info on this behavior later.
(In reply to zroutik from comment #5) > (In reply to caulier.gilles from comment #2) > > Which search tool did you use in digiKam exactly ? > > I identified two search modules and new issues: > - the Search tab in the sidebar between Timeline and Similarity > - the Advanced Search > > This issue concerns the Search. > > A search term with accents that returns some results in Search does not > return any results in Advanced Search. I'll follow up with more info on this > behavior later. Sorry, this ^^^ behaviour is not true. I identified two search modules and the issues is valid for both: - the Search tab in the sidebar between Timeline and Similarity - the Advanced Search
The problem is clear: ASCII characters are case-insensitive in a LIKE search in the SQLite database, but accented characters are not. Our only option would be to ignore accented characters, as MySQL generally does, with a LIKE search with the option "COLLATE NOACCENT". Maik
*** This bug has been marked as a duplicate of bug 413842 ***
Git commit 8395165b49097d8b8e8ec9b9ecf5163e20772d24 by Maik Qualmann. Committed on 26/12/2025 at 10:33. Pushed by mqualmann into branch 'master'. use a lower case string to fix accent searches in SQLite FIXED-IN: 9.0.0 M +1 -1 NEWS M +1 -1 core/utilities/searchwindow/searchtabheader.cpp https://invent.kde.org/graphics/digikam/-/commit/8395165b49097d8b8e8ec9b9ecf5163e20772d24
Git commit a6a12c52d934f3bb8fce362a6cc7f11e10c54469 by Maik Qualmann. Committed on 26/12/2025 at 10:43. Pushed by mqualmann into branch 'master'. Revert "use a lower case string to fix accent searches in SQLite" M +1 -1 NEWS M +1 -1 core/utilities/searchwindow/searchtabheader.cpp https://invent.kde.org/graphics/digikam/-/commit/a6a12c52d934f3bb8fce362a6cc7f11e10c54469
I do not agree that this report is a duplicate to #413842. Bug #513820 reports that the search is case-insensitive for ASCII characters but case-sensitive for accented characters. This means accented characters are treated differently from non-accented ones. Bug #413842 is a wishlist to make search **accent-insensitive**, so that typing “Alex” would match “Alex”, “Àlex” and “Álex”. These are different behaviors. For users, search behavior must be clear and predictable. If a user types accented characters deliberately, the search should preserve that intent and not always ignore accents. For example, searching “Àlex” should not return plain “Alex” results next to "Àlex". If possible, support both behaviors with switches: - **Accent-aware & exact match:** search for the exact pattern with case and accents (exact ON) - **Accent-insensitive & fuzzy:** ignore accents when matching (exact OFF) - **Case-sensitive ON / OFF:** respect or ignore case
In MySQL, Álex and Alex are the same, as MySQL ignores accented characters. Everything would have to be stored in binary format in the database, which would mean that searches would then be case-sensitive. In SQLite, there is only one switch to ignore accented characters. Maik