Fix quicklinks search: treat "&" and multilingual "and" equivalents as the same token

[digitalby]

Fixes #424

Problem

The Quicklinks Explorer search uses name.toLowerCase().includes(search.toLowerCase()). This means & and word equivalents like and, und, oraz, etc. are unrelated strings. A user searching b and h will not find Search B&H, and b&h won't either due to spacing.

Solution

Add a normalizeSearch helper that splits on whitespace and maps any known "and" token to a canonical & before comparison. Both sides of every filter call are normalized the same way.

const AND_TOKENS = new Set(["&", "and", "adn", "und", "oraz", "и", "e", "i"]);

function normalizeSearch(str: string): string {
  return str
    .toLowerCase()
    .split(/\s+/)
    .map((token) => (AND_TOKENS.has(token) ? "&" : token))
    .join(" ")
    .trim();
}

Token-splitting is used instead of regex word boundaries because \b does not work correctly with non-ASCII scripts (e.g. Cyrillic и). AND_TOKENS is a plain Set that can be extended with more languages or typos without touching the comparison logic.

Initial token coverage:

Token	Language / Note
and	English
adn	English typo
und	German
oraz	Polish
i	Polish, Croatian, Swedish
e	Italian, Portuguese, Spanish
и	Russian, Ukrainian

Testing

• b and h now matches Search B&H
• b&h now matches Search B&H
• b und h now matches Search B&H
• Searches with no & or "and" tokens are unaffected

[vercel]

@digitalby is attempting to deploy a commit to the Raycast Team on Vercel.

A member of the Team first needs to authorize it.