It's important that $params values not just get set without checking to see if something is there. In the case of hl.fl, the multilingual module simply wipes out whatever values existed before. This patch is not elegant but it allows the multilingual module to respect the incoming hl.fl values while adding its own.
This is a good example of why we need a better baseline API for these things.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 915626_6.x-1.x.patch | 5.24 KB | mkalkbrenner |
| #2 | 915626_6.x-2.x.patch | 5.25 KB | mkalkbrenner |
| hlfl.patch | 1.34 KB | robertdouglass |
Comments
Comment #1
mkalkbrennerThere's no elegant way to solve this using the current API.
I guess this issue is related to #912304: Support apachesolr_multilingual.
But I think this patch does not solve the issue completely. To apply multilingual support to any apache solr contrib module we have to replace title, body, ts_*, and tm_* fields if they occur by their language specific equivalent. Ugly ...
Comment #2
mkalkbrennerI rewrote the patch to solve the issue for all possible language specific fields. Additionally I fixed some warnings and a compatibility issue which is caused by change in apachesolr where the serialization of hidden get parameters has been changed to json format. Without fixing that language filters don't work correctly.
@Robert: Are you able to test the 2.x patch?
Comment #3
wmostrey commentedI tried the 6.x-2 patch and it doesn't solve the issue of #912304: Support apachesolr_multilingual.
Comment #4
wmostrey commentedUnless a clear test path can be given, this needs more work as per #3.
Comment #5
wmostrey commentedIt appears that patch #2 has already been committed by Markus.
I'm closing this issue and will continue in #912304: Support apachesolr_multilingual