Autosuggest terms always display for the default language for multi-lingual setup

Created on 17 July 2025, about 1 month ago

Problem/Motivation

After installing the SearchStax module in Drupal, and routing searches through it, the Auto-suggest dropdown keeps displaying the default language suggestions when searching for a term in the language's Search view, even when multiple languages are configured. For example, if EN (default) and FR are the 2 languages, then searching on drupal-site/en/search will show the same suggestions as searching on drupal-site/fr/search, which will be the terms configured for EN (default) language on SearchStax.

From my understanding so far, this happens because within the SearchStax module code, the language param isn't being passed to the /emsuggest query.

Steps to reproduce

  1. Create a Drupal app and connect to SearchStax.
  2. Install and enable the SearchStax module on Drupal.
  3. Enable search_api, search_api_autocomplete, and search_api_solr for the Auto-complete feature to work.
  4. Under Configuration > Search and metadata > SearchStax settings, check the boxes which say "Re-route searches through SearchStudio" and "Configure searches via SearchStudio". Add the Auto-suggest core and click on "Save configuration".
  5. On SearchStax Site Search dashboard, go to App Settings > Languages and add a second language besides EN.
  6. Create a Search view on Drupal and populate content for testing. Index the data and enable Auto-suggest on SearchStax Site Search dashboard by going to Recommendations > Auto-suggest > Enable Auto-Suggest > Save Draft > Publish.
  7. Add different sets of suggestion terms under the 2 languages. For example, if the 2 languages configured are EN and FR, we can add "sammy" for EN and "samuel" for FR. This will help test the autosuggestions if we search for "sa"
  8. On Drupal, under Configuration > Search and metadata > Search API, select the index, then go to the "Autocomplete" section.
  9. Check the "Search" box, then click on "Edit". Check "SearchStax" under "Enabled suggesters", and hit "Save".
  10. Go to the Search view for each language, and start typing the common start letters. The suggestions that show up for both languages will be the one that's set to default (in my testing, it was EN so even for FR language, I was seeing EN suggestions).

Proposed resolution

If the language code for the language currently selected by the user on Drupal is passed to the /emsuggest params, we'll get the correct autocomplete suggestions for the corresponding language.

As a workaround, I tried adding the language parameter to the /emsuggest query after fetching the current language id, and then I was able to get different suggestions for the different languages.

I've attached a patch with the changes I made to the following file for this workaround, in case it is helpful for reference:
web/modules/contrib/searchstax/src/Plugin/search_api_autocomplete/suggester/SearchstaxSuggester.php

🐛 Bug report
Status

Active

Version

1.7

Component

General code

Created by

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @kaunaj
  • 🇦🇹Austria drunken monkey Vienna, Austria

    drunken monkey made their first commit to this issue’s fork.

  • 🇦🇹Austria drunken monkey Vienna, Austria

    Thanks for reporting this problem!

    I wasn’t aware of the language parameter that seems to exist for both /emsuggest and /emselect and apparently also causes issues by its absence in the latter – for instance, synonyms were not working as expected for the non-default languages.

    All of this should be fixed in this merge request. (It depends on this MR from Improvements for the “Relevance model” option in SearchStax Solr views Active since both require calculating a “current language” for a search query.)

  • Pipeline finished with Skipped
    about 1 month ago
    #556678
  • 🇦🇹Austria drunken monkey Vienna, Austria

    Merged into the 1.x branch, will test there.

  • 🇦🇹Austria drunken monkey Vienna, Austria

    Confirmed to work now, will be part of the 1.7.1 release.

  • 🇩🇪Germany stborchert

    Sorry to reopen, but the commit breaks searching completely for us.

    After updating to version 1.7.1 we get the following error when searching:

    { "responseHeader":{ "status":500, "QTime":0}, "error":{ "msg":"Could not find config for language: null", "trace":"java.lang.Exception: Could not find config for language: null\n\tat com.searchstax.searchstudio.solrPlugin.SearchHandler.handleRequestBody(SearchHandler.java:126)\n\tat org.apache.solr.handler.RequestHandlerBase.handleRequest[...]

    Rolling back to commit b36db3fa fixes the problem.

    Our query looks like this:
    q=(tcngramproductm_X3b_en_X2d_us_field_search_keywords:(+"lhf")+tcngramproductm_X3b_und_field_search_keywords:(+"lhf"))&wt=json&indent=true&fq=(+ss_moderation_state:"published"++sm_domain_access:"us_example_com"++ss_langcode:"en-us")&fq=+index_id:products&fq=ss_search_api_language:("en-us"+"und")&sort=score+desc&fq=(+ss_moderation_state:"published"++sm_domain_access:"us_example_com"++ss_langcode:"en-us")

    I tried debugging the code added by commit e73c1cfb but couldn't see anything suspicious.
    If you need more information about our setup, feel free to ping me on slack (stBorchert).

    thanks

  • 🇦🇹Austria drunken monkey Vienna, Austria

    Thanks for reopening!
    The error message is a bit misleading, but the root cause of the error seems to be that you have the current page’s language, en-us, is not one of the languages configured in your SearchStax app – as, indeed, it is not a language code supported by SearchStax in general. (It seems the supported language codes would be en, en_ca, en_hk and en_gb.)
    We’ll look into how to best resolve this issue for you.

  • 🇩🇪Germany stborchert

    Hey Thomas.
    There are some more languages we use that are not available in a SearchApp at SearchStax. Indexing and searching works, but you cannot add the language to the app (e.g. "ja-jp").

  • 🇩🇪Germany SteffenR Germany

    Maybe we should add something like a language mapping configuration for the remote languages.
    The tmgmt module is doing something like this within its configuration.

Production build 0.71.5 2024