opy-provider (wrightkit/opy-provider#2) and wright's LPP client (wright/crates/wright-lpp/src/provider.rs ~line 613) both use a params.locale field on lpp/check / lpp/compile to select the provider's source/output language (e.g. "en-US", "zh-CN"). Wright's --locale flag already depends on it.
The field is protocol-visible but absent from docs/spec/*: §6 (params) and §8 (check/compile) never mention locale. Any provider-visible field needs normative spec coverage (§19 rule 1), so this is a spec ownership decision:
- Add
locale?: string to the check/compile params with defined semantics (BCP-47 tag; absent = provider default; unknown values → provider-defined fallback vs. invalidParams), or
- Decide that language selection is out of LPP scope and remove the field from both sides.
Either way, providers and clients should converge on the spec, not silently diverge.
opy-provider(wrightkit/opy-provider#2) and wright's LPP client (wright/crates/wright-lpp/src/provider.rs~line 613) both use aparams.localefield onlpp/check/lpp/compileto select the provider's source/output language (e.g."en-US","zh-CN"). Wright's--localeflag already depends on it.The field is protocol-visible but absent from
docs/spec/*: §6 (params) and §8 (check/compile) never mentionlocale. Any provider-visible field needs normative spec coverage (§19 rule 1), so this is a spec ownership decision:locale?: stringto the check/compile params with defined semantics (BCP-47 tag; absent = provider default; unknown values → provider-defined fallback vs.invalidParams), orEither way, providers and clients should converge on the spec, not silently diverge.