[BUG] React Compiler bug

[mini2s]

Problem (one or two sentences)

#9565

Causing partial internationalization failure

Context (who is affected and when)

#9565

Causing partial internationalization failure

Reproduction steps

#9565

Causing partial internationalization failure

Expected result

Dynamic internationalized entries display the corresponding language normally

Actual result

Partially invalid, partially effective

Variations tried (optional)

No response

App Version

main branch

API Provider (optional)

None

Model Used (optional)

No response

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote-v0]

I have analyzed this issue and here is my proposed implementation plan:

Problem Analysis

PR #9565 added React Compiler integration which automatically handles memoization in React applications. The issue is that the TranslationContext in webview-ui/src/i18n/TranslationContext.tsx has a memoization bug that React Compiler exposes:

const translate = useCallback(
    (key: string, options?: Record<string, any>) => {
        return i18n.t(key, options)
    },
    [i18n],  // <-- Problem: i18n object reference never changes, only its internal language state
)

The i18n object is a singleton whose reference stays the same even when i18n.changeLanguage() is called. This means the translate callback is never recreated when the language changes, and React Compiler may aggressively cache the results of components using translations.

Proposed Fix

1. Add i18n.language to the dependency array of the useCallback hook in TranslationContext.tsx
2. This ensures the translate function is recreated when the language changes
3. This will cause all components using useAppTranslation() to properly re-render with updated translations

const translate = useCallback(
    (key: string, options?: Record<string, any>) => {
        return i18n.t(key, options)
    },
    [i18n, i18n.language],  // <-- Add i18n.language as dependency
)

This is the minimal change needed to fix the issue while maintaining compatibility with React Compiler optimizations.

Please mention @roomote in a comment saying that you approve this plan, and I will proceed with the implementation.

[mini2s]

@roomote approve

[roomote-v0]

Thanks for the approval! I've seen your comment and will proceed with the implementation. I'll open a PR to share progress shortly.

[roomote-v0]

Opened a PR with my attempt at addressing this: #11103

The fix adds i18n.language to the dependency array of the translate useCallback hook in TranslationContext.tsx. This ensures the translate function is recreated when the language changes, preventing React Compiler from over-caching translation results.

Feedback welcome!

[mini2s]

@roomote There are still issues

const [enableButtons, setEnableButtons] = useState(false)
const [primaryButtonText, setPrimaryButtonText] = useState<string | undefined>(undefined)

[roomote-v0]

I've seen your comment and will investigate the React Compiler issues with useState<boolean>(false) and useState<string | undefined>(undefined) patterns in ChatView.tsx. I'll explore a potential fix and open a PR to share progress.

[roomote-v0]

I have created PR #11104 to address the React Compiler i18n caching issues.

Key changes:

1. TranslationContext.tsx: Added i18n.language to the translate callback dependency array. This ensures the translation function is re-memoized when the language changes, which React Compiler was missing.

2. ChatView.tsx:

   • Changed button state from storing translated values (primaryButtonText) to storing translation keys (primaryButtonKey)
   • Translations are now computed at render time: const primaryButtonText = primaryButtonKey ? t(primaryButtonKey) : undefined
   • Removed redundant useState<boolean>(false) type annotations that may confuse React Compiler type inference
   • Simplified tooltip rendering with pre-computed key-to-tooltip mappings

Root cause: When setPrimaryButtonText(t("chat:retry.title")) was called, the already-translated string was cached in state. React Compiler aggressively memoized this, and when language changed, the stale value persisted because React Compiler did not track that t() results depend on i18n.language.

Solution: By storing keys instead of values, t() is called fresh on every render and properly reflects the current language.

PR: #11104