PowerSearch: filter phrases are constructed (field + operator + value) — not grammatical in all languages
- Dominant language
- TypeScript
- Stars
- 13.1k
- Forks
- 1.1k
- Avg merge
- 1d 15h
- Merged PRs (30d)
- 687
Description
## Problem
PowerSearch renders a filter as a sequence of independently-rendered pieces – **field**, **operator**, **value** – laid out in a fixed `field operator value` order ("Status is Open"). That order is effectively English subject-verb-object baked into the UI.
This is the classic i18n/l10n anti-pattern of building a sentence from separately-translated fragments. It reads fine in English and other SVO languages, but:
- **Word order differs by language.** The field/operator/value sequence isn't correct in every language; some need the pieces in a different order, which a fixed chip layout can't express.
- **Grammatical agreement (case, gender, number) ripples across the phrase.** The operator or value form can depend on the field noun, and vice-versa. Fragments rendered independently can't carry agreement they don't know about.
- **Operators aren't always a clean fit.** A small fixed operator set (`is`, `is any of`, …) may need different wording depending on the field it attaches to in some languages.
## Why it's hard here (and maybe not fully solvable)
Unlike a static UI string, PowerSearch can't wrap the whole phrase in one translatable message, because the pieces are **consumer-supplied and dynamic**:
- **Field names and values come from the consumer's data model** – the library can't pre-translate them or tag them with grammatical metadata (gender/case).
- Only the **operator set** is owned by the library and fully translatable.
So the realistic ceiling is: make the *frame* a single ICU message with placeholders so it's at least reorderable per language (ICU's guidance is to put choice logic as the outermost structure and write full sub-phrases), while accepting that full grammaticality across arbitrary user-supplied field nouns isn't achievable at the library layer. Mature faceted-search UIs generally treat filter chips as labelled/telegraphic fragments (`Field: value`) rather than fluent sentences for exactly this reason.
## Scope
Design/investigation. This is the l10n-correctness side of PowerSearch (grammar/word-order), distinct from the responsive-layout overflow tracked separately. Worth deciding what the honest target is:
- reorderable ICU template for the operator frame, and/or
- a `Field: value`-style telegraphic presentation that sidesteps sentence grammar, and/or
- consumer-provided per-locale field metadata (probably out of scope for the library).
Part of the i18n & RTL effort (#3636).
Contributor guide
Assessment
This issue has not been assessed yet.