What's happening?
When prompted for target languages during lingo init, entering locales separated by , (comma + space) - the natural way to type a list - results in an "Invalid locale" error. The workaround of using no space (es,fr) works, but is not obvious and took me a while to figure out.
What makes this extra confusing is that the help text shows 'es', 'fr', 'de-AT' as examples, which implies comma-space is a valid format.
Exact Reproduction Steps
- Run
npx lingo.dev@latest init
- When prompted for target languages, enter:
es, fr (with a space after the comma)
- Observe the error
Expected
The CLI accepts es, fr and parses it as two locales: es and fr.
Actual
? Target languages to translate to. Accepts locale codes like 'es', 'fr', 'de-AT' separated by commas or spaces. Defaults to 'es'
es, fr
> Invalid locale: fr
Do you need support for fr locale? Type "help" and we will.
Note the leading space before fr in the error - that's the actual cause of the failure, but it's invisible in the output, making it very hard to debug.
Workaround
Omit the space after the comma: es,fr (no space).
Root Cause
In packages/cli/src/cli/cmd/init.ts, the --targets option parser splits on , but does not trim the resulting values:
value.includes(",") ? value.split(",") : value.split(" ")So "es, fr" becomes ["es", " fr"], and " fr" fails locale validation. A simple fix would be:
value.includes(",") ? value.split(",").map((v) => v.trim()) : value.split(" ")It's also worth checking whether other option parsers in the CLI follow the same pattern - --paths uses a similar approach and may be affected as well.
Ideas for Improvement
Even with the trim fix applied, a couple of small UX touches could make this more robust:
-
Clearer help text - explicitly show both accepted formats, e.g.:
Accepts locale codes separated by commas or spaces: es,fr or es fr
-
Quote the invalid value in the error - the current message prints Invalid locale: fr where the leading space is invisible. Wrapping it in quotes would make the problem obvious:
Invalid locale: " fr" - did you accidentally include a space?
Environment
lingo.dev CLI (latest)- Reproduced during interactive
init flow
I'd love to contribute a fix for this. Happy to discuss the preferred approach with the team before implementing anything - just let me know!
What's happening?
When prompted for target languages during
lingo init, entering locales separated by,(comma + space) - the natural way to type a list - results in an "Invalid locale" error. The workaround of using no space (es,fr) works, but is not obvious and took me a while to figure out.What makes this extra confusing is that the help text shows
'es', 'fr', 'de-AT'as examples, which implies comma-space is a valid format.Exact Reproduction Steps
npx lingo.dev@latest inites, fr(with a space after the comma)Expected
The CLI accepts
es, frand parses it as two locales:esandfr.Actual
Note the leading space before
frin the error - that's the actual cause of the failure, but it's invisible in the output, making it very hard to debug.Workaround
Omit the space after the comma:
es,fr(no space).Root Cause
In
packages/cli/src/cli/cmd/init.ts, the--targetsoption parser splits on,but does not trim the resulting values:So
"es, fr"becomes["es", " fr"], and" fr"fails locale validation. A simple fix would be:It's also worth checking whether other option parsers in the CLI follow the same pattern -
--pathsuses a similar approach and may be affected as well.Ideas for Improvement
Even with the trim fix applied, a couple of small UX touches could make this more robust:
Clearer help text - explicitly show both accepted formats, e.g.:
Quote the invalid value in the error - the current message prints
Invalid locale: frwhere the leading space is invisible. Wrapping it in quotes would make the problem obvious:Environment
lingo.devCLI (latest)initflowI'd love to contribute a fix for this. Happy to discuss the preferred approach with the team before implementing anything - just let me know!