Frontend i18n

The Langflow frontend is internationalized with i18next + react-i18next. Locales live in src/frontend/src/locales/ — currently en, de, es, fr, ja, pt, zh-Hans. A hardcoded user-facing string, or a key missing from one locale, ships broken UI for part of the user base.

The two rules

1. Every user-facing string goes through t(...) — never hardcoded JSX text for labels, buttons, tooltips, modals, toasts, errors, placeholders, aria-labels, or empty states.
2. Every new key is added to ALL locale files in the same PR (en.json, de.json, es.json, fr.json, ja.json, pt.json, zh-Hans.json). fallbackLng: "en" means a missing key silently shows English — it won't crash, which is exactly why reviews must catch it.

How it works here

• Config: src/frontend/src/i18n.ts — a custom i18next instance. en is bundled statically; other languages are lazy-loaded by loadLanguage() via dynamic import. Language preference comes from localStorage.getItem("languagePreference"), normalized (e.g. zh-CN → zh-Hans, unknown → en).
• Keys are flat, dot-namespaced by feature: deleteModal.title, errors.fileTooLarge, crash.restartButton. Follow the existing namespace of the area you're touching; create a new prefix only for a genuinely new surface.
• Interpolation uses {{variable}} in the string and an options object in the call.

Adding a string (the pattern)

import { useTranslation } from "react-i18next";