Extract all remaining hardcoded UI strings into i18n keys

[Mystery-CLI]

Background

Internationalisation (i18n) support is a core feature of FuTuRe, allowing users worldwide to interact with the application in their preferred language. The project uses an i18n module with key-value translation files, but the implementation has been added incrementally over time. As a result, a significant number of user-facing strings in frontend/src/components/ are still rendered as hardcoded English literals rather than being routed through the i18n module. This means that even users who have selected a non-English language will encounter English strings throughout the UI.

Problem

Hardcoded strings in components create several problems for the internationalisation effort:

• Incomplete translations. Users who select a non-English language encounter a mix of translated and hardcoded English strings, which is confusing and inconsistent.
• Hidden scope. Because hardcoded strings do not appear in the translation key files, translators and i18n reviewers have no way to know which strings are missing from their workflow.
• Ongoing accumulation. Without enforcement, contributors continue to add hardcoded strings in new components, growing the backlog of missing translations.
• Regression risk. When UI text is updated, hardcoded strings are changed in component source files rather than translation key files, meaning the change is automatically reflected in English but silently missing from all other languages.
• Audit difficulty. There is no automated way to identify hardcoded strings, so the current extent of the problem is unknown.

Proposed Solution

Perform a systematic audit of all components in frontend/src/components/ to identify user-facing strings that are not routed through the i18n module, then extract each one into an appropriately named translation key and add it to all existing translation files.

The audit should cover:

• Button labels and link text.
• Form field labels, placeholders, and validation messages.
• Page headings and subheadings.
• Tooltip and helper text.
• Toast and notification messages.
• Empty-state messages and call-to-action copy.
• Error messages rendered in the UI.

Implementation Steps

1. Write or identify a script that statically analyses JSX files and reports string literals that are not wrapped in an i18n call (e.g. t('key'), i18n.t('key'), or equivalent).
2. Run the script against frontend/src/components/ and produce a list of all hardcoded strings with their file and line number.
3. For each identified string, create a descriptive translation key following the project's existing key naming convention.
4. Replace the hardcoded string with the i18n call in the component source.
5. Add the new key and its English value to the English base translation file.
6. Add placeholder entries (or English fallbacks) for the key in all other supported language files so that the translation files remain structurally consistent.
7. Add the static analysis script to CI so that future hardcoded strings are caught before merge.

Acceptance Criteria

• Running the i18n audit script against frontend/src/components/ reports zero unextracted user-facing strings.
• All newly extracted strings have keys following the project's naming convention.
• The English translation file is updated with all new keys.
• All other language files contain entries for all new keys (even if the value is the English fallback).
• The CI audit step passes on the PR.

Notes

Not all string literals are user-facing — CSS class names, internal identifiers, and log messages should not be extracted. The audit script should be tuned to focus on JSX text nodes and string attributes such as placeholder, alt, aria-label, and title. Coordinate with any active translators before merging so they can begin translating the new keys.