By default filter by the user's language and provide setting on settings page.

I'm also interested! :-)

The easy way to handle this (I think) is to make sure to always index some value (not NULL) for language - i.e. something that's never a language code like the string 'neutral' or 'empty'.

Dear JakobSingh

Thanks for your effort on this issue. Did you make any progress on this issue?

Thanks for a short feedback. Maybe I can help you with this, because I need to implement this feature too.

Greets

The current code supports facets on nulls via, e.g. -language:[* TO *]

Subscribing

This would be really useful to a couple of our clients.

Their ideal scenario is that results are returned from the user's current language but if a piece of content hasn't been translated then it returns results from the site's default language.

Their scenario is that only 20% of the site content is translated, so ideally search looks for content in the user's own language but falls back where that's not available. Not sure if that is an additional complication on the current issue.

Thanks

That shoudl be the same as search current language + language neutral?

This is still an issue.

Best solution might be:

current selected language + language neutral

Agree that it should be current select language + language neutral. This should reflect in the languages facet block. We need a facet for language neutral, I think.

Pasqualle made a Apache Solr language filter module which you can find at http://windmill.sk/project/module/apachesolr_language_filter

the code from Pasqualle is straightforward:

/**
 * Implementation of apachesolr_modify_query().
 * Display only language neutral or active language. The negative filter is used
 * because there in no way to filter language neutral content.
 */
function apachesolr_language_filter_apachesolr_modify_query(&$query, &$params) {
  global $language;
  $languages = language_list('language');
  unset($languages[$language->language]);

  foreach ($languages as $langcode => $lang) {
    $query->add_filter('language', $langcode, TRUE);
  }
}

That's the entire module.

Also noted is that the breadcrumbs are incorrect:

function _preprecess_page(&$vars) {

  if (arg(0) == 'search') {
    // Remove language filters from breadcrumb. This could be removed when
    // apachesolr-6.x-2.x will be used on the site.
    $breadcrumb = drupal_get_breadcrumb();
    $langcodes = array_keys(language_list());
    foreach ($breadcrumb as $key => $link) {
      if (strpos($link, 'filters=-language') || in_array($link, $langcodes)) {
        unset($breadcrumb[$key]);
      }
    }
    // The last breadcrumb is the current page, so it shouldn't be a link.
    $last = count($breadcrumb) - 1;
    $breadcrumb[$last] = strip_tags($breadcrumb[$last]);
    $vars['breadcrumb'] = theme('breadcrumb', $breadcrumb);
  }
}

Adding an empty facet to the languages block doesn't work:

From apachesolr.module function apachesolr_facet_block():

      if ($facet == '_empty_') {
         $exclude = TRUE;
         $facet = '[* TO *]';
         $facet_text = theme('placeholder', t('Missing this field'));
         $options['html'] = TRUE;
         // Put this just below any active facets.
         // '-' sorts before all numbers, but after '*'.
         $sortpre = '-';
       }

This will generate a URL with: ?filters=-language%3A[* TO *]

This doesn't work, and the logic from Pasqualle is better.

Drupal 7 is using a defined code for no language. That's the better approach I think, but requires reindexing.

Why doesn't facet missing work? It works for other fields.

Ah, that's good information. I'll look and we'll index that for no language as well. I don't know yet why the -language:[* TO *] doesn't work.

Drupal 7 field.module has:

/**
 * The language code assigned to untranslatable fields.
 *
 * Defined by ISO639-2 for "No linguistic content / Not applicable".
 */
define('FIELD_LANGUAGE_NONE', 'zxx');

so 'zxx'

Defined by ISO639-2 for "No linguistic content / Not applicable". LOL. I bet that was a bikeshed discussion. "I want zzz!"

Kind of seems like 'und' would be more correct, but whatever.

# und, for "undetermined";
# zxx, for "no linguistic content, not applicable".

http://en.wikipedia.org/wiki/List_of_ISO_639-2_codes

I upgraded to 6.x-1.0 and apparently Pasqualle's module ApacheSolr Language Filter did not work anymore. I noticed now that the solr index contains 'und' for language independent content so I enhanced his module (see last part):

/**
 * Implementation of apachesolr_modify_query().
 * Display only language neutral or active language. The negative filter is used
 * because there in no way to filter language neutral content.
 */
function apachesolr_language_filter_apachesolr_modify_query(&$query, &$params) {
  global $language;
  $languages = language_list('language');
  unset($languages[$language->language]);

  foreach ($languages as $langcode => $lang) {
    $query->add_filter('language', $langcode, TRUE);
  }
  
  // Filter out language independent content in case the default language is not the active language  
  if ($language->language != language_default('language')) {
    $query->add_filter('language', 'und', TRUE);
  }
}

subscribe

Yes, unfortunately Druapl 7 core change from zxx to und, so we changed to match.

So, should apachesolr_search.module add a default language filter, or should we leave that to custom modules? What is the standard way of doing things in Drupal? I think it's to not add a filter, in which case this is wontfix.

there should be an option in the module to filter by current (+LANGUAGE_NONE) language. Mixing different languages in search result is wrong in most cases, so multilingual sites will need this option enabled..

Ok, then this is a feature request.

I offer to solve this issue as part of Apache Solr Multilingual.

(To be honest, I start working on it right now because we need it for a project.)

Sounds good - thanks! Please paste the new issue number in this issue.

I suggest that I simply move this issue to Apache Solr Multilingual issue queue.

Given the weak support for multiple languages in the base module, this probably makes sense, though we should revisit for Drupal .7

(Ah, yes, I forgot we can move issues between projects.) Would you like to take ownership of these issues, too?

#603362: translate node types
#436578: Translated (localized) taxonomy facet blocks

Here's the patch for Apachesolr Multilingual.