UI Internationalization (i18n)

I haven't opened the code, so this review is based only on the facts you gave. I can't cite files or line numbers yet, and step 1 of the plan is a code audit to find them.

Assumptions to confirm

• Languages: German (de), Japanese (ja) and Arabic (ar), plus English. Arabic means RTL has to be built in from the start.
• Arabic region: The choice affects the calendar, numerals and currency. For example, ar-SA defaults to the Islamic calendar, while ar-EG and ar-AE use Gregorian. I recommend ar-AE or ar-EG with Latin digits unless the product team says otherwise.
• Currency and time zone: These should stay independent of language.
• Translations: I'm assuming they come from people or a vendor, so the catalog needs translator context.
• Charts: I don't know if the dashboard has charts, and I'd check. Axes, legends and tooltips would need RTL handling too.

Review findings

Hard-coded text

• Inline strings in components. Every label, placeholder, tooltip, aria-label, error message and page title needs a catalog key. Fix: adopt a library (react-intl or i18next with ICU), use stable keys, and add a translator description for each key.
• count === 1 plurals. This is wrong for Arabic, which has six plural categories (zero, one, two, few, many, other). It is also wrong for Japanese, which has only "other". Fix: use ICU {count, plural, ...} messages. Arabic needs all six forms written out.
• Likely string concatenation. Inline strings usually come with count + " items in " + name patterns. Fix: whole messages with named placeholders. I'd grep for + " and template literals in JSX.
• Ambiguous one-word labels. Words like "Open" or "Filter" can be a verb or a noun. Fix: separate keys per meaning.

Formatting

• Hand-written MM/DD/YYYY. This is wrong for all three new languages. Fix: Intl.DateTimeFormat(locale, options), with dates stored as ISO or timestamps. Check whether the data layer holds already-formatted strings.
• Numbers, currency, percentages. These are probably formatted by hand too. Fix: use Intl.NumberFormat, with currency as an explicit code and not derived from the language.
• Other formatters. Relative time ("3 days ago"), lists, and sorting should use Intl.RelativeTimeFormat, Intl.ListFormat and Intl.Collator.
• Language and region. Keep these as separate settings.

Layout and truncation

• Fixed pixel widths on buttons and tabs. German will overflow them and clip. Fix: remove the widths and use min-width, padding and flex or grid with gap. Where truncation is unavoidable, use an ellipsis plus a tooltip or accessible name.
• Fixed heights. Check for these as well, since text will wrap to more lines.
• Verification. Use pseudo-localization (about 40% longer, accented, in brackets) to find every clipped element before real translations exist.

Scripts and fonts

• No lang on the document. Set <html lang> per locale. This is needed for Japanese glyph selection, since the Han characters render differently under ja.
• Font stack. Add Japanese and Arabic fallbacks; a Latin-only stack will give inconsistent system fallbacks. Check that the bold weights exist for those scripts.
• Typography.
  • Give Japanese more line-height.
  • Remove any italic emphasis, any forced uppercase, and any letter-spacing on Arabic. Letter spacing breaks Arabic joining.
  • Don't truncate strings by character index; use Intl.Segmenter if any code does.

RTL

• margin-left and text-align: left. These will break the Arabic layout. Fix: switch to margin-inline-start, padding-inline, text-align: start, inset-inline-* and border-inline-*. Do this by codebase-wide search and replace, then review each hit. Also check for float, left: / right:, and translateX.
• dir. Set dir="rtl" on the root for Arabic.
• Icons. Audit them one by one. Mirror chevrons, back and next arrows, and progress bars. Don't mirror logos, play/pause icons, clocks or numerals.
• Mixed-direction content. Wrap user-generated or unknown-direction text in <bdi>. Give email, URL and code fields dir="ltr".
• Charts. If there are any, decide deliberately whether to mirror the time axis. Numerals and axis values stay LTR.

Routing and switching

• No language switcher. Add one labeled in each language's own name (English, Deutsch, 日本語, العربية), with no flags.
• Locale order. Use saved choice, then URL, then browser Accept-Language, then default. Don't force a redirect.
• Persistence. Remember the choice.
• URLs and SEO. If the dashboard is public, use a path prefix per language with hreflang, x-default and canonical URLs. If it's behind a login, a saved preference may be enough, but I'd confirm.
• Fallback. Missing translations fall back to English and log the gap. Raw keys should never show.

Plan

1. Audit (about 1–2 days). Grep for hard-coded strings, count ===, manual date code, width: in px, and left/right/margin-left. This gives a real inventory and effort estimate. Confirm the Arabic region and numeral choice, the translation source, and whether the app has charts or is public.
2. Foundation.
   • Pick the i18n library and set up the message catalog, with the en catalog as the source.
   • Add a locale provider, a lang/dir setter and the switcher.
   • Add the font stacks and a pseudo-locale.
   • Add a lint rule against literal JSX text (e.g. eslint-plugin-i18next).
3. Layout and CSS (can run in parallel with step 4). Remove fixed widths and convert to logical properties. Make buttons and tabs flexible, and audit icons for mirroring. Verify with the pseudo-locale and with Arabic under dir="rtl".
4. Extract strings. Move them component by component into the catalog, with translator notes and ICU plurals. Replace concatenation with whole messages.
5. Formatting layer. Make one helper module wrapping Intl.* for dates, numbers, currency, lists and relative time. Replace every manual format and store dates as ISO or timestamps.
6. Translation. Send the catalog to translators with context, including the six Arabic plural forms. Flag legal text, examples and region-specific content for review.
7. QA and verification. Run every screen in en, de, ja, ar at phone and desktop widths. Test plurals with counts of 0, 1, 2, 5 and a large number (Arabic needs 0, 1, 2, 3–10, 11–99 and 100+ to cover all forms). Compare dates and numbers across two regions. Check lang and dir in the DOM. Search again for leftover hard-coded strings.

Order and risk: the CSS conversion (step 3) and string extraction (step 4) are the largest pieces of work. RTL is the riskiest because it touches every component, so do it early and not at the end.

Not checked: I haven't looked at the codebase, run anything, or tested any real RTL or translated text. All of the above comes from the facts you listed.

If you'd like, I can start with step 1 once you point me at the project directory. The working directory appears to be empty.