`lingo init`: entering target locales with spaces after commas causes "Invalid locale" error

[artembell]

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

1. Run npx lingo.dev@latest init
2. When prompted for target languages, enter: es, fr (with a space after the comma)
3. 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:

1. Clearer help text - explicitly show both accepted formats, e.g.:

   Accepts locale codes separated by commas or spaces: es,fr or es fr

2. 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!