📄 web/test/i18n-mock.ts:8

The JSDoc on line 8 says "Checks translations[key] first, then translations[ns.key]" but the implementation on lines 16-21 checks translations[fullKey] (i.e., the namespaced ns.key) first, then translations[key] second. This inverted documentation will mislead contributors who want to understand or customize the lookup precedence.

Impact: Low — just a documentation mismatch, but could confuse developers when they provide translations with both bare keys and namespaced keys.

 * Create a t function with optional custom translations
 * Checks translations[ns.key] first, then translations[key], then returns ns.key as fallback

📄 web/test/i18n-mock.ts:41

The real useTranslation from react-i18next accepts an optional defaultNs parameter: useTranslation('myNamespace'). The old global mock in vitest.setup.ts forwarded this to the t function:

useTranslation: (defaultNs?: string) => ({
  t: (key, options?) => {
    const ns = options?.ns ?? defaultNs
    ...
  }
})

The new createUseTranslationMock ignores it:

useTranslation: () => ({ t: createTFunction(translations) })

Note that createTFunction already supports defaultNs as its second parameter, so the fix is straightforward.

Impact: Currently no production code in the affected test paths calls useTranslation with arguments, so this is not breaking. However, it's a regression in mock fidelity that could cause silent test failures if a component starts using useTranslation('ns').

export function createUseTranslationMock(translations: TranslationMap = {}) {
  return {
    useTranslation: (defaultNs?: string) => ({
      t: createTFunction(translations, defaultNs),
      i18n: {
        language: 'en',
        changeLanguage: vi.fn(),
      },
    }),
  }
}