Support i18n translations in the language mapping callback

Thanks for the post and patch. Marking as "needs work for a couple of reasons.

It looks like facetapi_map_language() passes the language variable through t(), which is against best practices. See http://drupal.org/node/322729, specifically the passage below:

Using dynamic values, such as t($type). Whenever you use dynamic strings to call the above functions, make sure that all possible values are already in the code elsewhere in literal form using the API. Do not translate user provided content.

Are we sure that these strings have already been passed through t()? This is an area I am not too familiar with, so any clarification or confirmation would be helpful.

Also, based off of comments on the Facetapi i18n project, the patch to i18n_taxonomy at http://drupal.org/node/1340858#comment-5259368 apparently resolves the taxonomy issue.

Thanks,
Chris

Great! Thanks for pointing that out and confirming.

I think based on thegreat's commets in his sandbox project we can skip the changes to the facetapi_map_taxonomy_terms() callback since the i18n module is being worked on to support this without any changes to Facet API. Based on your feedback, the change to the facetapi_map_language() callback is valid and I think would be a great addition to the module.

In terms of the facetapi_map_bundle(), I am hesitant to start committing code with module_exists() calls. In addition, there is work going on at #1338350: Extend facetapi_map_bundle() to all entity types which make this callback generic to all entities which would effect the proposed logic in the patch. I am thinking that this might be a good candidate for a project like Facetapi i18n where you could implement hook_facetapi_facet_info_alter() to modify the appropriate map callback keys to point to a custom callback with the i18n code you posted.

This is great. Thanks for opening the issue against i18n as well. Let's see what comes out of that and we can revisit in Facet API if necessary / once the facetapi_map_bundle() function gets re-worked.

Changing title to focus it down to what the patch accomplishes.

Committed at http://drupalcode.org/project/facetapi.git/commit/8004a76.

Congrats on becoming the 16th committer to Facet API!

As a quick solution you can always alter the facet info in a custom module and implement your own mapping callbacks. I have to do some research to figure out a consistent i18n strategy for the entire module. The new current search functionality introduces a whole new set of issues, so I want to make sure we are consistent in our approach.

Changing title for transparency as to what was done.

Note that the Facet API Translation module now provides the content type mapping capability.

Thanks,
Chris

Benys, thank you for your patch. I saw one error in if($i18n_taxonomy_on) { condition. Adding working patch for me.

Closing this issue, as the only supported translation method moving forward will be the Facet API Translation module.

Thanks,
Chris