Repository navigation
Spec: document params.locale on lpp/check and lpp/compile #42
Description
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?: stringto 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.
Activity
docs(spec): make locale fallback behavior descriptive
e54-bot commentedon Oct 20, 2026
Reopened: #96 was merged with a squash message that kept the first commit's
Fixes #42, which closed this issue by mistake. #96 documentsparams.localeas implemented, but it intentionally leaves the open question of this issue undecided: provider-defined fallback versusinvalidParamsfor a locale the provider does not serve. That decision is still needed. Also noted from review:localeis the Workshop client locale, not the source language.e54-bot commentedon Oct 20, 2026
Closing. #96 documents
params.localeas implemented, and the spec now says that behavior for a locale the provider does not serve is provider-defined. The remaining question (provider-defined fallback versusinvalidParams) is deferred: only theopyprovider serves locales today, and itslocale-unsupporteddiagnostic is implemented in opy-rs'sopy-providercrate. Open a new issue if a protocol-wide rule becomes necessary.