Add i18n to a React App from a Linear Issue

The agent reads the issue and then the repository before it changes anything. In a repository shaped like alan2207/bulletproof-react there are three apps, and the issue points at apps/react-vite. Its package.json declares React 18.3.1, react-router 7, Vite 5, Vitest 2, Zod 3 and TypeScript 5.4, with Yarn scripts for test, lint, check-types, build and test-e2e. The ESLint config in .eslintrc.cjs enforces kebab-case file and folder names through eslint-plugin-check-file, and src/config/env.ts reads only VITE_APP_ variables through a Zod schema, so the locale default is read there rather than from a loose import.meta.env call.

The strings live where the app composes itself. src/app/provider.tsx wraps the tree in Suspense, an error boundary, HelmetProvider and the React Query client; src/components/layouts/dashboard-layout.tsx names the side navigation Dashboard, Discussions and Users and the menu items Your Profile and Sign Out; src/features/auth/components/login-form.tsx labels its inputs Email Address and Password; and src/app/routes/landing.tsx carries the Bulletproof React, Get started and Github Repo copy. The agent installs i18next, react-i18next and i18next-browser-languagedetector, after checking that react-i18next 17 asks for React 16.8 or newer and TypeScript 5, 6 or 7, both of which this app satisfies.

The wiring is one module and one directory. src/lib/i18n.ts initialises i18next with the browser language detector, English as fallbackLng, and resources imported from src/locales/en/translation.json and the second locale the issue names, with the kebab-case paths the lint rule requires. provider.tsx imports that module once so every route renders through it, and a useTranslation hook replaces the literal strings in the layouts, the auth forms and the landing page with keys. A language menu is added to the user dropdown in dashboard-layout.tsx, and the choice persists through the detector's localStorage cache so a reload keeps it. English stays the default, which matters because the Playwright specs under e2e/tests and the Vitest tests under src/app/routes/app/discussions/__tests__ find elements by their English text.

Verification uses the repository's own tools. src/testing/test-utils.tsx renders under AppProvider with a memory router, so a new test renders the dashboard layout, changes the language through i18next, and asserts the navigation reads in the second locale. The agent runs yarn test, yarn lint, yarn check-types and yarn build, which is the same sequence .github/workflows/react-vite-ci.yml runs in its all-cli-checks job, and it runs yarn test-e2e against the mock server the e2e job uses, so the smoke, profile and auth setup specs still pass with English as the default.

What comes back is a pull request on its own branch, scoped to apps/react-vite. The diff adds src/lib/i18n.ts and the src/locales/ directory with one JSON file per locale, adds three dependencies to package.json and yarn.lock, imports the i18n module in src/app/provider.tsx, replaces literals with t() calls in the layout, auth and landing files, and adds the language menu and its test. The description quotes the issue, lists every file whose strings moved, and names any string the agent left in place because a test or an accessibility label depends on it.

The checks are the proof. react-vite-ci.yml runs on the pull request: the all-cli-checks job builds, tests, lints and type-checks, and the e2e job installs Playwright browsers and runs the specs against the mock API, uploading playwright-report/ as an artifact. The session's trajectory at GET /o/{org}/sessions/{id}/messages keeps every yarn command with its output, so a reviewer sees the suites pass rather than reading a claim.

Before merging, a reviewer checks three things: that no key is missing from the second locale file, which the new test exercises for the navigation but not for every string; that src/config/env.ts still validates the environment with the new optional default-locale variable; and that the English copy in the locale file matches what the Playwright specs look for. The two Next.js apps in the monorepo are untouched, and nothing reaches main until the pull request merges.

Sign in to Linear once with POST /me/connections {"type": "app", "name": "linear"} and finish the authorize URL in the console. Then add an automation to the Project with this prompt and a linear trigger on linear.issue.labeled, naming the label in config.labels. The trigger adds the issue after the prompt and fills in nothing, so the agent reads which app and which locales the issue asks for from the event. The automation's max_runs_per_hour, between 1 and 30, caps how many labelled issues it takes on in an hour, each in its own sandbox with its own pull request.

From your own server instead, a handler that receives Linear's webhook for the label sends POST /o/{org}/sessions with the repository and the issue URL in resources: https://linear.app/<workspace>/issue/ENG-42 puts the issue text in the prompt through your Linear connection. A request_id derived from the issue id makes a redelivered webhook return the run it already started. Give that key a webhook_url and Rush POSTs run.completed when the turn finishes, with data.session_url to read for the pull request link.

Internationalising an app is mostly a long, careful edit: every literal in a dozen files becomes a key, every key needs an entry in every locale, and one missed string shows up as a raw key in production. On a laptop that work competes with everything else open in the editor. On Rush the agent has its own sandbox and its own clone, runs yarn test, yarn lint and yarn check-types after each pass, and pushes only when the sequence the CI workflow runs is clean.

The result is a pull request you can judge, not a branch you have to finish. The diff shows every string that moved, the locale files show every key, the new Vitest test shows the switch working, and the repository's own CI runs the unit and Playwright suites on it. Several labelled issues mean several sandboxes at once, and the trajectory keeps every command and its output for each.

Will the existing tests break when strings become keys?

Which library does it use?

Does it touch the Next.js apps too?

How is the chosen language remembered?

Will the ESLint file-name rule reject the new files?