Skip to content

test: keep the client suite independent of the host locale - #280

Open
miadisabelle wants to merge 1 commit into
johannesjo:mainfrom
miadisabelle:contrib/session-picker-locale-test
Open

miadisabelle wants to merge 1 commit into
johannesjo:mainfrom
miadisabelle:contrib/session-picker-locale-test

Conversation

@miadisabelle

@miadisabelle miadisabelle commented Sep 19, 2026 •

Copy link
Copy Markdown
Contributor

Two client test files assert English output from code that formats in the host's default locale — correct for the app, but it fails the suite on a developer machine set to another language.

The two files on 3.1.0:

LC_ALL before after
fr_FR.UTF-8 3 failed 0
de_DE.UTF-8 4 failed 0
empty (Intl resolves und) 2 failed 0
en_US.UTF-8 0 0

SessionPicker

relativeTime formats with Intl.RelativeTimeFormat(undefined, …) and its tests match /day/ and /second/. Two days ago is 'avant-hier' under fr_FR, 'vorgestern' under de_DE, and '-2 d' under und.

The function already takes now so its tests are deterministic. It now takes an optional locale for the same reason, and the tests pass 'en'. The call site passes nothing, so the app still formats in the user's locale.

ContextMeter

The context and session titles use toLocaleString(), and the tests expected '50,000 of 200,000' and '12,500 tokens · 12,000 input' — '50.000' under de_DE, U+202F-grouped under fr_FR. The expected text is now built with toLocaleString(), as AnnotationMarker's and StatusDot's tests already do.

With both, npm run test:client passes 1150/1150 under fr_FR, de_DE and an empty LC_ALL.

If you'd prefer one line instead, setting test.env.LC_ALL in vitest.client.config.ts also works, since the forks pool starts its workers with that environment — but it pins every client test to English and depends on the pool staying process-based, so I went with fixing the tests.

typecheck, lint and format:check pass.

🤖 Generated with Claude Code

@miadisabelle
miadisabelle force-pushed the contrib/session-picker-locale-test branch from f9b3651 to a7a14ea Compare September 19, 2026 09:58
@miadisabelle

Copy link
Copy Markdown
Contributor Author

Rebased onto 3.0.1 (f190ba0), no conflicts. Re-measured npm run test:client on the rebased branch: 930 passed under LC_ALL=fr_FR.UTF-8, de_DE.UTF-8, empty and en_US.UTF-8 — none of the client tests added since assume English.

@miadisabelle
miadisabelle force-pushed the contrib/session-picker-locale-test branch from a7a14ea to 1f72616 Compare September 23, 2026 12:50
Two client test files assert English output from code that formats in the
host's default locale, which is right for the app but fails the suite on a
developer machine set to another language. The two files on 3.1.0:

  LC_ALL=fr_FR.UTF-8   3 failed
  LC_ALL=de_DE.UTF-8   4 failed
  LC_ALL= (empty)      2 failed   Intl resolves `und`
  LC_ALL=en_US.UTF-8   0 failed

- SessionPicker: `relativeTime` uses `Intl.RelativeTimeFormat(undefined, ...)`
  and its tests match /day/, /second/. Under fr_FR two days ago is
  'avant-hier', under de_DE 'vorgestern', under `und` '-2 d'. The function
  already takes `now` so its tests are deterministic; it now takes an optional
  `locale` for the same reason, and the tests pass 'en'. The app passes none.
- ContextMeter: the context and session titles use `toLocaleString()`, and the
  tests expected '50,000 of 200,000' and '12,500 tokens · 12,000 input'. Under
  de_DE those are '50.000' and '12.500'; under fr_FR the groups are separated
  by U+202F. The expected text is now built with `toLocaleString()`, as
  AnnotationMarker's and StatusDot's tests already do.

With both, `npm run test:client` passes 1150/1150 under fr_FR, de_DE and an
empty LC_ALL.
@miadisabelle
miadisabelle force-pushed the contrib/session-picker-locale-test branch from 1f72616 to 86ffb22 Compare October 3, 2026 22:48
@miadisabelle

Copy link
Copy Markdown
Contributor Author

Rebased onto 3.1.0 (8c09c4c). The chat rebuild moved the context meter and its tests out of AgentChatView into chat/ContextMeter, and the new test hardcodes the same English grouping, so the fix moved with it. Re-measured on 3.1.0: the two files fail 3 / 4 / 2 under fr_FR / de_DE / empty before, 0 after, and the full client suite passes 1150 under all three.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant