Transcript keyword search only works for single-character queries (Korean & English)

[yanghoonkim]

It seems that keyword search within transcripts is not functioning correctly.

In our case, the meeting transcript is primarily in Korean, with some English mixed in. However:
• Searching in Korean does not work properly
• Searching in English also does not work properly
• Only single-character queries return results
• Any query with two or more characters returns no results

This makes it effectively impossible to search for meaningful keywords.

Steps to Reproduce
1. Open a transcript from a recorded meeting
2. Try searching for a keyword with 2+ characters (Korean or English)
3. Observe that no results are returned
4. Try searching with a single character
5. Observe that results appear

Additional Notes
This may be related to tokenization, indexing, or language-specific text processing logic (e.g. handling of CJK characters).

[SaiThanushreddy]

Hi @yanghoonkim ,
I've submitted a PR (#3423 ) that fixes the in-transcript search (Ctrl+F) for multi-word queries.

Quick question: Does this issue also cover the global search (the "Search anything..." bar at the top)?

I noticed that global search has a separate issue with Korean text - it uses different tokenization that doesn't handle CJK characters well. If that's also part of this issue, I can look into fixing it as well.

Let me know if the in-transcript fix resolves your issue or if the global search needs attention too.

[Vanashreeshankar]

Hi @yanghoonkim ,

I independently investigated this issue and traced the root cause to the in-transcript search matching logic, where the full query string is matched against individual word spans ([data-word-id]). This causes multi-character and multi-word searches (English & Korean) to fail unless the query is a single character.

I opened a draft PR (#3424) documenting the investigation and a minimal, logic-only fix:

• Tokenize the query by whitespace
• Match spans that include all query terms
• Preserve existing per-word highlighting and navigation behavior

I noticed there is already an active PR addressing this issue, so PR #3424 is shared purely for context and documentation of the findings. Happy to close or adjust it based on maintainers’ preference, or help extend this to related areas if needed.

Thanks!