Inconsistent search query handling: Korean characters are ignored in mixed-input searches unlike English

[hi2242]

Describe the bug

First of all, thank you for the great work on VitePress. I really enjoy using it.

I noticed an inconsistency in the search behavior when mixing numbers with different languages.

• English + Number: When searching for a non-existent token like eeee9, the search correctly returns "No results found".

• Korean + Number: When searching for a non-existent token like ㄷㄷㄷㄷ9, the search seems to ignore the Korean characters (ㄷㄷㄷㄷ) and returns results matching only the number 9.

This inconsistency might confuse users, as the strictness of the search query varies depending on the language used. I believe the behavior should be consistent regardless of the input language.

Reproduction

1. Open the search bar in a VitePress site.

2. Type eeee9: Observe that "No results found" is displayed (Correct behavior).

3. Type ㄷㄷㄷㄷ9: Observe that it displays results containing the number 9, effectively stripping the Korean characters (Inconsistent behavior).

Expected behavior

Searching for ㄷㄷㄷㄷ9 should return "No results found", strictly matching the entire query string just like the English example (eeee9). It should not fall back to partial matching by dropping characters.

System Info

System:
    OS: Windows 11 10.0.26100
    CPU: (12) x64 13th Gen Intel(R) Core(TM) i5-1335U
    Memory: 4.44 GB / 15.69 GB
  Binaries:
    Node: 22.19.0 - C:\nvm4w\nodejs\node.EXE
    Yarn: 1.22.22 - C:\nvm4w\nodejs\yarn.CMD
    npm: 10.9.3 - C:\nvm4w\nodejs\npm.CMD
    pnpm: 10.22.0 - C:\nvm4w\nodejs\pnpm.CMD
  Browsers:
    Chrome: 142.0.7444.176
    Edge: Chromium (140.0.3485.54)
    Internet Explorer: 11.0.26100.1882

Additional context

I suspect this issue arises from the default query expansion settings in the underlying search implementation.

To ensure a consistent UX, I suggest enforcing stricter query handling by setting removeWordsIfNoResults: 'none' in the search client configuration. (In src/client/theme-default/components/VPAlgoliaSearchBox.vue)

I would love to contribute to fixing this issue. Could you please assign this issue to me? I am ready to submit a Pull Request.

Validations

• Check if you're on the latest VitePress version.
• Follow our Code of Conduct
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.

[brc-dd]

Hmm, not sure if we should do that. eeee 9 (with space) will behave same as ㄷㄷㄷㄷ9. If we set it to none, then it won't show any result for queries where complete matches are not available. Also, people can use quotes in the query ("ㄷㄷㄷㄷ9") if they want exact matches.

I understand the behavior is bit inconsistent, but for most queries it performs better with allOptional than none.

[hi2242]

@brc-dd
First, thank you for the quick response; it's an honor.

While I understand allOptional prevents empty results, I believe precision is more critical than recall in technical documentation. The current behavior creates an asymmetry: English eeee9 is strict (single token), whereas Korean ㄷㄷㄷㄷ9 splits and returns loose matches, which can mislead users looking for specific error codes or APIs. Since the quote("") workaround isn't intuitive to average users, I still think none ensures a more consistent and trustworthy experience. I would be grateful if you could consider this perspective one more time. However, I fully respect your final decision.

[brc-dd]

which can mislead users looking for specific error codes or APIs

Yeah, but things like error codes and APIs are in English. So if you're trying to search for an export, a composable, a slot, etc., you're going to have to type the English name anyway.

Also, query expansion only kicks in when there are no results. With none, if nothing comes back, the user has zero chance of finding what they need without another query. With allOptional, there's at least some chance - still small, but not zero.

So in your example it feels odd that one returns results and the other doesn't, but if you look at the broader picture, the behavior actually helps in cases where someone would otherwise have to keep trying till all keywords match.

[hi2242]

@brc-dd

I see your point. You are right that most technical terms and APIs are searched in English, so the fallback behavior of allOptional likely benefits the majority of users by avoiding zero results.

Thanks for taking the time to explain the rationale in detail. I'm happy to close this issue.