Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I'm not sure this is the right place to post this. Seems to me that language names when language is used as a facet should be translated as well. At the moment whether I use the Search API field for language or the Drupal field for language my language name (is this what you call "label"?) doesn't get translated. Interestingly, "Language neutral" does get translated to "Indépendant de la langue".
Unless I'm missing something could this be part of facetapi_i18n? I'm happy to give it a try if you were to accept a patch here.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 1794378-4--translated_language_labels.patch | 451 bytes | drunken monkey |
| #1 | translate_language_labels-1794378-1.patch | 555 bytes | miiimooo |
Comments
Comment #1
miiimoooAttached please find my (trivial) patch. Not sure thsi is teh right way of doing this but it works nicely and uses the existing facetapi_map_language callback provided by facetapi
Comment #2
cpliakas CreditAttribution: cpliakas commentedHi miiimooo.
Thanks for the post. I actually think this belongs in the Search API module. The facets are defined by the implementing module, and the map callbacks are set in the facet definitions. This is consistent with Facet API's default facets (which are used by Faceted Navigation for Search) as well as Apache Solr Search Integration's facet definitions. To me, Search API should know which field contains the language data and set the map callback accordingly.
Thanks again,
Chris
Comment #3
gilsbert CreditAttribution: gilsbert commentedHi.
I have the same need.
Did you find a solution on how to translate the facet for a language field?
Regards,
Gilsberty
Comment #4
drunken monkeyThe label mapping we are using for language fields is
entity_metadata_language_list(), provided by the Entity API for, e.g., the node language. So probably this should be fixed there, if this is really the right way to do it.Patch attached, to be applied to the Entity API module. Please see whether it fixes the issue!
Otherwise, I guess the best way would be with a short custom
hook_facetapi_facet_info_alter()implementation that implements the same change as the patch in #1.Comment #5
drunken monkeyComment #6
gilsbert CreditAttribution: gilsbert commentedHi Drunken.
Your patch works and fixed the issue.
Thank you very much.
May it be commited to entity project?
Regards,
Gilsberty
Comment #8
gilsbert CreditAttribution: gilsbert commentedHi, I tested the patch in #4 and it works.
I don't know why the testbot tried to use the patch in #1.
Regards,
Gilsberty
Comment #9
drunken monkeyThanks for testing the patch, great to hear it works! Now we just have to wait for fago to come round and commit it. ;)
The test bot will always test all untested patches, sometimes this is what you want. However, since the last patch, #4, succeeded, it didn't set the status to "Needs work", I think.
Comment #10
fagoLooks like core runs the language names through t() as well, thus - committed. FYI I've recently committed a similar fix for translated field option label support via i18n field.
Comment #11
gilsbert CreditAttribution: gilsbert commentedHi.
This is probably expected but I would like to warn that the patch is not applied on 7.x-1.4 .
Regards,
Gilsberty