[Tickets #2901] International searches (multiple results)

[bugs@bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/?id=2901
-----------------------------------------------------------------------
 Ticket             | 2901
 Updated By         | pablo at pablohoffman.com
 Summary            | International searches (multiple results)
 Queue              | Turba
 Version            | HEAD
 State              | Feedback
 Priority           | 2. Medium
 Type               | Enhancement
 Owners             | 
-----------------------------------------------------------------------


pablo at pablohoffman.com (2005-11-03 06:33) wrote:

> 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.