Internationalization (i18n) Architecture for Supabase Studio

[aiyi404]

Title: [Proposal] Internationalization (i18n) Architecture for Supabase Studio

Hi Supabase Team and Community,

I am a huge fan of Supabase and have been using it extensively. As the community continues to grow globally, I believe adding Internationalization (i18n) support to the Supabase Studio (Dashboard) would be a significant step forward. It would lower the barrier to entry for non-English speakers and further boost Supabase's adoption in regions like East Asia, Latin America, and Europe.

I understand that apps/studio is a large Next.js application and that retrofitting i18n is a massive undertaking. Therefore, I am proposing a gradual, non-disruptive strategy to implement this, and I am willing to volunteer to set up the infrastructure.

🐛 The Problem

Currently, all UI strings in the Studio are hardcoded in English within the .tsx files. This makes it impossible to support other languages without forking the project, which limits accessibility for global developers.

💡 The Proposed Solution

Since the Studio is built on Next.js, I propose integrating a standard i18n library.

Technical Stack Choice:
I suggest using next-i18next (based on i18next) or next-intl.

• Why: They are mature, handle SSR/SSG well, support pluralization/interpolation, and have excellent performance.
• Structure: We can store translation files in standard JSON format (e.g., apps/studio/locales/en/common.json), making it easy for the community to contribute translations via platforms like Crowdin or simple PRs later.

🗓 Implementation Plan (The "Incremental" Approach)

To avoid a "Code Bomb" (a massive PR that is impossible to review), I propose breaking this down into strictly defined phases:

• Phase 1: Infrastructure (RFC & Setup)

  • Install dependencies.
  • Configure next.config.js and i18n providers.
  • Add a simple language switcher in the Settings.
  • No text replacement yet. This ensures the build process and existing tests remain stable.

• Phase 2: MVP (Proof of Concept)

  • Select one isolated page (e.g., the "Settings" page or "Login" page).
  • Extract hardcoded strings to en.json.
  • Replace them with translation hooks (e.g., t('settings.title')).
  • Verify that CI/CD and Tests pass.

• Phase 3: Community Adoption (The Long Run)

  • Once the pattern is established and merged, we can create a "Call for Contributors."
  • Community members (including myself) can pick specific modules (e.g., Auth, Database, Storage) to migrate one by one.

❓ Questions for the Maintainers

Before I start working on a PR, I would love to hear your thoughts:

1. Is i18n currently on your internal roadmap? If you are already working on a rewrite or refactor, I don't want to duplicate efforts.
2. Do you have a preferred library? (e.g., next-i18next, react-intl, linguijs, etc.)
3. Are you open to accepting a PR for the Phase 1 (Infrastructure) setup?

I am happy to take the lead on the initial infrastructure setup if this aligns with the project's goals.

Looking forward to your feedback!

Best regards,

[Pakvothe]

+1 on this. I use Supabase for my own project and the hardcoded English strings in Studio have always stood out to me as something that'll need to change eventually.

@aiyi404's phased approach makes sense. Starting with infrastructure and one isolated page before touching the rest keeps the risk low.

I've been building i1n (github.com/Pakvothe/i1n-cli), a localization CLI that handles AI translation + TypeScript type generation. I'd be happy to help with the translation workflow side of this if the team decides to move forward. The tooling could handle the initial bulk translation across languages and keep things in sync as Studio evolves.

Either way, would be great to hear from the Supabase team on whether this is something they'd accept community PRs for.

[ahmedalmnsour]

@aiyi404 thanks for the detailed proposal. Two dimensions worth flagging before any string is extracted:

1. ICU MessageFormat should be decided before the first string is extracted. Retrofitting ICU later is expensive. Arabic alone has six CLDR plural forms (zero, one, two, few, many, other), and gender/select syntax matters once translations move beyond English-shaped strings. next-intl supports ICU natively; next-i18next needs a plugin.

This also ties into @Pakvothe's tooling proposal. ICU-aware schemas significantly improve the quality of AI-assisted bulk translation in morphologically rich locales, so the schema decision affects the translation workflow as well.

2. RTL is a parallel concern, not an extension of i18n. Most RTL work (logical properties ms-*/me-*, icon direction, bidirectional text) is CSS work, independent of the i18n library choice and doable today. Settings/Login works fine as an i18n smoke test, but won't surface RTL friction. A page like Table Editor would. Worth treating RTL as a separate workstream that can start in parallel with Phase 1 rather than waiting until Phase 3.

One low-cost step that would protect against future debt: a lint rule banning physical properties (ml-*, mr-*, pl-*, pr-*) in new code. Low-cost now, prevents expensive cleanup later.