fix(cli): force English locale for yargs in tests

[amsminn]

TLDR

Fixed test failures on non-English systems by forcing English locale in test-setup.ts. Yargs was generating error messages in the system's locale (e.g., Korean) while tests expected English messages.

Dive Deeper

The root cause was that while the main CLI correctly sets .locale('en') in production code, test files were creating yargs instances without locale configuration. This caused yargs to automatically detect and use the system locale for its built-in error messages.

The fix adds LC_ALL='C' and LANG='en_US.UTF-8' environment variables to
packages/cli/test-setup.ts, which forces English locale for all CLI package tests. This
approach:

• Requires only a single file change
• Applies consistently to all current and future tests
• Follows the same pattern used in packages/core/test-setup.ts
• Has no impact on production code

Reviewer Test Plan

1. Reproduce the issue (optional):

# Set your system to a non-English locale
export LANG=ko_KR.UTF-8  # or any non-English locale

# Run tests

2. Verify the fix:

# Checkout this branch
git checkout fix/test-locale-issues

# Run tests

Testing Matrix

	🍏	🪟	🐧
npm run	✅	❓	❓
npx	✅	❓	❓
Docker	❓	❓	❓
Podman	❓	❓	❓
Seatbelt	❓	-	-

Linked issues / bugs

This PR makes progress on #8241

[gemini-code-assist]

Summary of Changes

Hello @amsminn, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses an issue where CLI tests were failing on systems configured with non-English locales. By enforcing an English locale for yargs within the test setup, the PR ensures consistent test execution regardless of the host system's language settings, thereby enhancing the reliability and portability of the test suite.

Highlights

• Test Stability: Resolved test failures occurring on non-English systems by explicitly setting the locale for yargs within the CLI test environment. This ensures yargs error messages are consistently in English, preventing mismatches with test expectations.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request addresses an issue with test failures on non-English systems by forcing an English locale within the test setup. The method of setting environment variables is appropriate for this purpose. My review focuses on a small improvement to remove a redundant environment variable setting, which will enhance the clarity and maintainability of the configuration.

[cornmander]

Thank you for your contribution. I think this is an OK way to do this but I would rather that our tests don't make assumptions that break internationalization. We're currently working with a contributor on landing internationalization in #8060 so it would be counterproductive to hardcode our tests to English.

Do you have a list of tests that are broken, and can we make them do less literal string comparison to make them pass?