I have an issue for autocomplete to work like google's autocomplete for multiple languages' special characters.

For example, if user fills in the form the letter "á" and finds no match in autocomplete results, I want to system return results of words starting with the letter "a".
The same can be for the specials characters "áü". In this example the suggestions will be words starting or including the letters "au".

I think all we need to do this is a replace() or preg_match() function to transform special characters like "á" to "a".

The point is I cant find the exacly location of code to add this function. Any help?

Comments

skullJ’s picture

Hello, using the hook_finder_find_keywords_alter() the example code can be:

if $keywords is an array like:

<?php
$keywords = array( 'á' , 'a');

The hook_finder_find_keywords_alter() can be:

function hook_finder_find_keywords_alter(&$keywords, $finder, $finder_element_id, $mode='choices', $match, $pager) {

$spchar = array( 'á'    => 'a',
                 'áü'   => 'au'
            );

foreach ($keywords as $key) {

   foreach ($spchar as $k => $result) {
			if ($key == $k) {
                 $keywords = $spchar[$key];
			}
   }
}
 return $keywords;
}


There is a problem with return $keywords cause i dont know what function hook_finder_find_keywords_alter returns and what array can be the $keywords.

so if system get 'á' will return 'a'. What do you thing?

danielb’s picture

Neither of those function are meant to return anything - just modify the first parameter ($keywords, or $options)

I think you should use this function on each string:
http://php.net/manual/en/function.strtr.php

I wouldn't compare the keyword with your spchars, because the keyword could contain extra letters on the end.

Now you just need a list of all the possible character variants mapped to what they need to be.

Then there is the reverse problem, if they type 'a' but the database contains 'á', which this won't solve. This would need to be handled by the database or a database function. I don't know anything about that.

skullJ’s picture

hmm, i see...

The strtr() is the function that i was searching for! thank you.

I didnt understand where should "my code" place...sory, but there is some other problem that we fix.

At first step, system must search the keyword(s) in the database as they are. For example, if user types 'á', system before translation (strtr), should search in database fo this letter or phrase.

At second step, system must translate with strtr the letter or phrase from "my array" with special characters for translation.

I think these two steps should place in seperate hooks, or inside the main functions. What is your opinion?

danielb’s picture

I'm not sure, but one thing you can look into is using hook_finder_options_alter and calling finder_find() an extra time with modified keywords, and appending the results to your $options array.
Another solution would be to alter the query directly - there are hooks for that too.

It isn't a clever or easy solution though - I think this problem should be tackled at the database configuration/design level.

For example I found this tool for Postgres; http://www.public-software-group.org/utf8proc
For mySQL you might learn something here: http://dev.mysql.com/doc/refman/5.0/en/charset.html
specifically under 'collations'

danielb’s picture

Another option is to use the Computed Field module to store simple versions of your node titles (without diacritics), and always convert user's keywords to simple versions too, and compare them... to store your node fields.

danielb’s picture

Component: Finder Autocomplete » Miscellaneous
Status: Active » Postponed

Postponed, though I doubt we'll find a solution, I think this has to be handled on the database level.

danielb’s picture

Status: Postponed » Closed (duplicate)

I am closing this issue and creating a new one for advanced text matching
#998650: Advanced text comparison