It is a long time known problem that the search function in common.inc does not provide friendly header strings for translation. Since this issue cannot be solved in that function, I decided to delegate the task of providing a title for the results to the search functions. This changes the search hook return value, and requires an array containing two elements, the first being the requested title, and the second being the result list. Advantages:

  • Cleaner search code in common.inc
  • Po extraction is possible and works fine
  • No hardcoded exceptions for node and comment modules, since any module can return results in order of relevance (or another order)

BTW I have used direct numerical access to get the title and result values in common.inc to not hit the overhead of copying them to other meaningfuly named varibales. Since the result list could consume a lot of memory, and there is no need to keep another copy of it in memory with the list() construct... You will probably want to change this to require an object with two properites as a result from the search function, or an associative array, to better fit with the rest of Drupal... I have not been able to decide on what exactly to do, so just wanted to highlight my improvement idea.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Dries’s picture

Committed to HEAD. Thanks.

PS: I prefer verbose keys keys instead of numeric keys as it makes the code somewhat more readable -- and often easier to maintain. I haven't altered your patch though.

Gábor Hojtsy’s picture

Great. Documented on the site in module changes from 4.3 to CVS, and in contributions/docs

Anonymous’s picture