Facet items title are not translated

Actually, the facet texts (for taxonomy term names, etc. – if they are available in different languages) should already be translated to the currently used language. Of course, if they are values occurring in the items as-is, we can hardly translate them.
What are your concrete complaints, what would you like to have translated?

Based on #1734730: Taxonomy terms with apostrophe are encoded with "&#39", I would recommend that you modify the patch to use the snippet below so the values aren't double-escaped by Facet API.

foreach(array_keys($map) as $key){
  $map[$key] = array(
    '#markup' => filter_xss(t($map[$key])),
    '#html' => TRUE,
  );
}

Thanks,
Chris

This seems to work, but I'm quite sure it was working earlier when I just translated the term itself. Now I noticed after updating drupal core and bunch of other modules that the term names are not translated in search_api views, but in other views translations work. I will probably have to open a separate issue for that.

I finally had some time to try this with a vanilla drupal and latest releases of different modules required for having multilingual fields and indexing them. And the term used as a facet indeed is not appearing correctly in different languages. I'm using Apache Solr as the search backend and if I check the index, the term is stored there as a string using the default (source) language of the entity, although I think it should be stored as tid.

This issue is probably related #1775678: Term labels not localized

It came to my mind, that there is the i18n_taxonomy module which allows to translate terms in the first place. So I wrote a simple facet item alter to get the translated term name when I index the tid using Solr. You need to enable the "Rewrite facet items via callback function" in the "configure filters" settings of the facet.

<?php
function YOUR_MODULE_facet_items_alter(&$build, &$settings) {
  if ($settings->facet == "FACET_NAME") {
    global $language;
    foreach($build as $key => $item) {
      $term = taxonomy_term_load($item["#markup"]);
      $build[$key]["#markup"] = i18n_taxonomy_term_name($term, $language->language);
    }
  }
}
?>

This will fetch the localized name for the term when your vocabulary is using the setting "Localize".

What makes it interesting is that views exposed filters are translated fine and I couldn't find any string "i18n_" when searching the whole views folder. I have attached a picture, hopefully it shows what is working and what is not.

I'm not sure how to proceed from here, but when the terms are localized, there should be a way to show the localized versions instead of the default which seems to pop out from different places.

I don't think the proposed patch is the right way to do this. Now I have to translate the terms two times. The term shouldn't be indexed by it's name, instead using term ID sounds more logical and then displaying the term in the proper language. I'm not sure where this would have to happen, since core makes it possible to translate entities, but i18n_taxonomy provides the UI to actually translate them. But like I said previously, Views exposed filters work correctly without any i18n integration, so there must be a way to index and display the terms for any language.

My workaround above is less hackish and works also after updating the module. But it's depending on the i18n. And it's only for taxonomy terms, I'm not sure how it should be done for fields which are using entity translation.

I would like to hear maintainer's opinion on this.

Just to weigh in here, Facet API does have a map callback for taxonomy terms that works with the i18n_taxonomy module. Specifically, it runs the terms through entity_label() which allows i18n to do it's magic. Might be worth trying to leverage Facet API's map callback or replicating the logic in Search API's custom map callback. See #1276812: Multilingual facet items for some background and more detailed explanations on how this works.

This issue has not seen activity in over 2,5 years. I am therefore closing this issue to clean up the issue queue. Feel free to re-open and update this issue if you feel this issue is still relevant and of importance.