i18n: extract authorization screen strings (Part of #145)

[everysingletear]

Part of #145.

Extracts every user-facing string under src/views/Authorization/ into a new auth namespace. English only — no translations in this PR, so it is language-agnostic and safe to review as a pure refactor.

What moves

Screen	Covered
LoginView	primary/sub-account tabs, credential form, social + Authentik buttons, welcome-back state, all auth error toasts
Signup	account creation form and every field-validation message
ForgotPasswordView	reset request flow and its toasts
UpdatePasswordView	new-password entry, including the mismatch/length errors

auth is registered in src/i18n/config.js; public/locales/en/auth.json holds the 75 keys.

Why this zone first

Login is the first screen a non-English user ever reaches, and right now it is entirely hardcoded — someone who picks a language in settings still gets an English login screen on their next cold start. It is also self-contained: four files, no shared components, so it does not collide with in-flight work elsewhere.

It should also compose well with the Crowdin setup that just landed on develop — the config picks up /public/locales/en/*.json by glob, so this namespace flows into the translation pipeline with no change to crowdin.yml.

Notes

• No behaviour change: every string maps 1:1 to what rendered before.
• MFAVerificationModal is deliberately left out — it is entangled with the MFA flow logic and deserves its own pass rather than being smuggled in here.
• Rebased on current develop; build is green.

[meauxt]

am sorry i think our work overlap :( did not saw this until today

[everysingletear]

am sorry i think our work overlap :( did not saw this until today

Hi — thank you for this project. I came across it some months ago and it has taken a real load of chores off my family; I wanted to give something back.

I'd had a long gap between projects and picked internationalisation as the way in. My family isn't comfortable in English, and hardcoding a translation over your strings felt like the disrespectful shortcut — so I did it properly instead: i18next namespaces, extracted locale files under public/locales/en/, English only, no translations bundled in.

I've worked through most of the app on that pattern. The Authorization PR already open is a representative sample: four files, 75 keys, every string mapping 1:1 to what rendered before, no behaviour change, green build.

Here's what I'd propose, if it works for you:

1. I open a tracking issue listing the remaining zones, so anyone can see what's claimed — we already had two people extract the same screens without realising.
2. I send them one PR per zone, each self-contained and independently revertable, at whatever pace your review time allows.
3. Anything you'd rather keep hardcoded, or any naming convention you want for namespaces and keys, I'll follow — say the word early and I'll rework the rest to match.

Happy to slow down, change the split, or drop any of it. You know the codebase and its direction far better than I do.

P.S. A separate and entirely optional thing: I also spent some time on a more contemporary look for the UI. That's a product decision, not a refactor, so I'm keeping it well away from the i18n PRs — but if you're curious I can post screenshots in a separate issue and you can decide whether it's worth a conversation at all.

[meauxt]

that perfect thank you for you help! if you can rebase this one we should be good to go on auth. and for the rest what you mention sounds good!

[everysingletear]

Thanks — and it turns out a rebase won't do it here, so I'd rather say that plainly than force-push something misleading.

This branch extracted the login strings as those screens were before the revamp. LoginView alone has been through ~780 lines of change since, and the zone was split out into AuthShell / AuthFields along the way. Every hunk here points at code that no longer exists, so what git would hand me aren't really conflicts — the extraction just has to be redone against the new structure.

That part I don't mind; it's an afternoon, and the key names carry over so nothing is wasted. What gives me pause is that #185 is still open and these screens have been reshaped twice in the past week. Redoing the extraction today stands a fair chance of needing a third pass.

So I'd rather leave this one parked and start where your refactors haven't been. I've posted a full audit in #145 — I went through all 129 components on my fork against current develop and sorted them into what can land untouched and what has to wait. First I'll trim #155 down to the files that still apply so it stops sitting in your queue as a conflict. Then Settings: 16 files, none of them touched on develop, extending a namespace that already exists — so no config.js change and nothing for it to collide with.

If you'd rather I close this PR outright and open a fresh one once the auth screens settle, that's fine too — say which you prefer.

[meauxt]

Yes, that sounds good. Please feel free to close this and open a new one. Thank you for your flexibility!

[everysingletear]

Closing this one as agreed — thank you.

The replacement is #208, extracted fresh against current develop rather than rebased: the zone had been reshaped enough that the old hunks had nothing left to apply to.

Two notes on scope. MFAVerificationModal is in this time — I left it out originally because it looked entangled with the MFA flow, and on a second read it isn't: the diff there is string replacement only. Authenticating.jsx is covered too, since the OAuth landing screen sits in the same zone and leaving it hardcoded would only have meant a follow-up round.

The extraction is verified mechanically rather than by eye: every value in en/auth.json appears character-for-character in the code it replaces, across all 130 call sites. Your e2e suite is a second check on that — it selects auth controls by visible text, so a green auth.spec.js means nothing rendered differently.

One thing the extraction surfaced, flagged in the PR as well: AuthPasswordField had label = 'Password' as a prop default and neither LoginView nor Signup passed one. A default is evaluated at module scope where t isn't available, so the label moves to the call sites — same rendered output, but it's the one place the diff isn't purely mechanical.

I also saw you localized the settings views yourself, so I've dropped that zone from my list. To avoid colliding a third time I'll claim each zone in #145 before starting it rather than after.