facebook / facebook/astryx

PowerSearch: filter phrases are constructed (field + operator + value) — not grammatical in all languages

Open
#4,763 1 comment 0 reactions 1 assignee Claimed by @nynexman4464 View on GitHub
component enhancement
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.