Closed (duplicate)
Project:
Finder
Version:
6.x-1.8
Component:
Miscellaneous
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
10 Dec 2010 at 09:20 UTC
Updated:
15 Dec 2010 at 05:16 UTC
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
Comment #1
danielb commentedYou would need to use a hook to change the values.
One of these perhaps
http://braksator.com/api/function/hook_finder_find_keywords_alter/6--1
http://braksator.com/api/function/hook_finder_find_options_alter/6--1
Possibly related #850896: Diacritics not ingoren in Finder Views + Autocomplete
Comment #2
skullJ commentedHello, using the hook_finder_find_keywords_alter() the example code can be:
if $keywords is an array like:
The hook_finder_find_keywords_alter() can be:
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?
Comment #3
danielb commentedNeither 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.
Comment #4
skullJ commentedhmm, 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?
Comment #5
danielb commentedI'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'
Comment #6
danielb commentedAnother 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.
Comment #7
danielb commentedPostponed, though I doubt we'll find a solution, I think this has to be handled on the database level.
Comment #8
danielb commentedI am closing this issue and creating a new one for advanced text matching
#998650: Advanced text comparison