ops: prepare for internationalization without shipping translations yet

[joelpeace48-cell]

Problem

Every user-facing string is hardcoded in JSX. That is fine today, but several
relevant grant programmes and public-sector buyers operate in non-English
jurisdictions, and retrofitting internationalization across a built dashboard is
substantially more work than structuring for it now.

What to do

This is preparation, not translation — do not commission translations yet:

• Extract user-facing strings into a message catalogue with stable keys.
• Adopt Next.js i18n routing with English as the only active locale for now.
• Use Intl for dates, numbers, and currency rather than hand-formatting —
  this matters immediately, because a compliance export showing 1,000.50 to a
  reader expecting 1.000,50 is a real misreading of a financial figure.
• Avoid layouts that break when a string grows 30% longer, which German and
  Finnish reliably do.
• Set lang correctly and keep the door open for right-to-left.

Acceptance criteria

• Strings extracted to a catalogue with stable keys
• i18n routing configured, English-only for now
• All dates, numbers, and currency formatted via Intl
• Layouts tested against significantly longer strings

Notes

The Intl formatting is worth doing regardless of whether a second language
ever ships — ambiguous number formatting in a billing product is a correctness
problem, not a localisation one.

[Josetic224]

ops: prepare for internationalization without shipping translations yet

I’d like to take on this issue by preparing the dashboard for internationalization without introducing translations at this stage.

My approach would be to first audit the existing UI and extract all user-facing strings from JSX into a structured message catalogue using stable, descriptive keys. This will make future translations much easier and prevent translation concerns from being scattered throughout the codebase.

I’ll also configure Next.js internationalized routing with English as the only active locale for now, while structuring the setup so additional locales can be introduced without having to refactor the application again.

For formatting, I’ll replace any manual date, number, and currency formatting with the JavaScript Intl APIs. This is particularly important for financial and compliance-related data, where formats such as 1,000.50 and 1.000,50 can be interpreted very differently depending on the reader’s locale.

I’ll review the existing layouts and components with longer translations in mind, testing strings that are approximately 30% longer than the current English copy. I’ll adjust fixed widths, buttons, table columns, cards, navigation elements, and other areas where text growth could cause overflow or broken layouts.

Finally, I’ll ensure the application sets the correct lang attribute and structure the internationalization setup so that RTL languages can be supported later without requiring a major architectural rewrite.

May I be assigned this issue?

[joelpeace48-cell]

@Josetic224, you are assigned ensure all ci pipeline passes

[grantfox-oss]

🦊 GrantFox — @Josetic224 has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #80)
2. Your PR will be reviewed by the FinesseStudioLab maintainers

Good luck! Track your progress on GrantFox.