Fri, 10 Apr 2026 04:38:54 +0000 https://bugs.horde.org/ticket/2901 International searches (multiple results) It would be great to add support for international searches in turba. That is, to search for "Sanchez" and return "Sánchez", "Sanchez", "Sanchéz", etc. In openldap (slapd) this can be achieved using the approximate operator ("~=") instead of the usual "=". Attached is a one-line (very specific) hack to add this functionality with current Horde/Turba version, as a proof of concept. Is not a generic hack, you must change "cn" to the LDAP attribute you use as "name". Anyway, in case no one is already working on this, I may be available to do it. It will involve adding some options to sources.php, I think. -- Pablo Hoffman Wed, 02 Nov 2005 15:01:26 +0000 https://bugs.horde.org/ticket/2901#t13342 This should already work if you specify the LDAP server's charset in the configuration and use search strings that are compatible to the used charset. Wed, 02 Nov 2005 22:59:24 +0000 https://bugs.horde.org/ticket/2901#t13354 > This should already work if you specify the LDAP server's charset in > the configuration and use search strings that are compatible to the > used charset. It's not the same. One thing is the charset you use. I'm using utf-8 and have turba configured that way, and it's working fine. But look at the following scenario: I have an spanish directory with all the following entries: cn: Sánchez cn: Sanchez cn: Sanchéz When I look for (cn=Sanchez) I want all of them to be returned since that is the way addressbook usually work (ie: ignore accents). But it's not working that way. Cause when you seach (cn=Sanchez) it only returns the Sanchez entry (not Sánchez nor Sanchéz). The openldap server (slapd) has an special operator that can match all those three entries when you look for "Sanchez". It's called the approximate operator and it's used like this: instead of searching for: (cn=*sanchez*) ---> returns only Sanchez you search for: (cn~=sanchez) ---> returns Sanchez, Sánchez and Sanchéz Note the ~= operator and the lack of "*" in the approximate search. And that's it. The problem is that, since this is not a special match rule (that would be the ideal solution but there's no standard for it yet) you must implement it in the client side and that's what I said it would be great to have in turba. Look at my quick-dirty patch to see how I fixed the problem. Adding this functionality to turba will involve allowing to configure in some way the "operator" you want to use for searches, and that should be done in the sources.php file, I think. Thu, 03 Nov 2005 14:33:15 +0000 https://bugs.horde.org/ticket/2901#t13378 Implemented with these two commits: http://lists.horde.org/archives/cvs/Week-of-Mon-20070716/069450.html http://lists.horde.org/archives/cvs/Week-of-Mon-20070716/069453.html Thu, 19 Jul 2007 21:02:15 +0000 https://bugs.horde.org/ticket/2901#t35332