Skip to content

feat: better i18n for CLI#1087

Draft
vladfrangu wants to merge 4 commits intomasterfrom
feat/i18n
Draft

feat: better i18n for CLI#1087
vladfrangu wants to merge 4 commits intomasterfrom
feat/i18n

Conversation

@vladfrangu
Copy link
Copy Markdown
Member

So far this PR tackles a nicer logger interface than random imported functions across the project, and also lays the ground work for i18n support (both in formatting strings, using the ICU Message format).

I am ready to port all messages and write upgrades to CLAUDE.md and such, but I want to know where we want to store these localized messages

  1. Define them where they are used
// src/commands/xx.ts
const XXMessages = defineMessages({ en: { myMessage: 'Hi {name}' } });

// And use it where needed
logger.stderr.info(t(XXMessages.myMessage, { name: 'Vlad' }));
  1. Define them in src/i18n and import where needed

@vladfrangu vladfrangu added the adhoc Ad-hoc unplanned task added during the sprint. label Apr 19, 2026
@github-actions github-actions Bot added this to the 138th sprint - Tooling team milestone Apr 19, 2026
@github-actions github-actions Bot added the t-tooling Issues with this label are in the ownership of the tooling team. label Apr 19, 2026
- Add `LoggerOutputs` interface and `setOutputs`/`reset` methods to `Logger`
- Add `NoopLoggerOutput` for silent test runs when `APIFY_NO_LOGS_IN_TESTS` is set
- Update `useConsoleSpy` to install a capturing `LoggerOutput` directly instead of wrapping raw streams
Prevents Vitest's noop-logger flag from leaking into the spawned CLI process, so e2e tests can assert on real stdout/stderr output.
@patrikbraborec
Copy link
Copy Markdown
Contributor

I think that the second option is better.

Just a side note -> have you ever seen/used CLI that use different language than English? Or we will use English, and this is just better code convention to do it?

@vladfrangu
Copy link
Copy Markdown
Member Author

I've seen Claude has several languages if I recall. I personally don't use anything but English but ik others might want it.

That said I mostly wanted to have a structured way to define messages, maybe I can refactor it to drop locales and just have a way to define the 3 variants for messages (human, markdown and json)

@patrikbraborec
Copy link
Copy Markdown
Contributor

Do you think that we need difference for human vs markdown? Should not we have everything in md as it is quite easy format to read?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

adhoc Ad-hoc unplanned task added during the sprint. t-tooling Issues with this label are in the ownership of the tooling team.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants