Maintaining Nextra 2: Multi-domain i18n Support & Modern Features

[RiverTwilight]

The Power of Domain-based i18n

The web isn't flat. Different regions need different domains, not just different paths. When serving content globally, we often need example.com for international users and example.com.cn for China. This isn't just about translation - it's about complying with local laws and serving region-specific content.

Nextra 2 handles this elegantly. It lets us configure different locales based on deployment targets:

import defaultConfig from "./default-config.mjs";
import nextra from "nextra";
const withNextra = nextra({
    theme: "./theme.tsx",
});

const targetRegion = process.env.TARGET_REGION;
let config;

if (targetRegion === "china") {
    config = {
        ...defaultConfig,
        i18n: {
            locales: ["zh-CN"],
            defaultLocale: "zh-CN",
        },
    };
} else if (targetRegion === "global") {
    config = {
        ...defaultConfig,
        i18n: {
            locales: ["en-US", "zh-CN"],
            defaultLocale: "en-US",
        },
    };
} else {
    config = defaultConfig;
}

export default withNextra(config);

V3 and V4 moved to path-based localization only. While we could use CI scripts to achieve similar results, it adds complexity where none is needed. Nextra 2's approach is simpler: one project, clean architecture, no extra build steps.

Proposed Solution

Rather than letting Nextra 2 fade away, I propose maintaining it as a parallel version that preserves this crucial functionality while bringing in modern improvements. I'm willing to contribute by:

1. Backporting key features from Nextra 4:

   • React 19 support
   • MDX 4 integration
   • Other relevant new features

2. Fixing existing issues, starting with React 19 compatibility:

   Attempted import error: '__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED' 
   is not exported from 'react'
   

This isn't about resisting change - it's about preserving a valuable approach to internationalization while keeping the codebase modern and maintained.

Would anyone be interested in collaborating on this effort?

[dimaMachina]

Rather than letting Nextra 2 fade away, I propose maintaining it as a parallel version that preserves this crucial functionality while bringing in modern improvements. I'm willing to contribute by:

I disagree about the possibility of maintaining Nextra 2 and 3. Only last stable Nextra is maintained

[RiverTwilight]

I understand the focus on maintaining only the latest stable version. However, this raises an important question: Is domain-based i18n support completely off the roadmap for future Nextra versions?

If there are no plans to restore this functionality in newer versions, I'd be happy to maintain a community fork of V2 with modern features backported. This could serve projects that depend on domain-based i18n while reducing the maintenance burden on the core team.

What are your thoughts on either of these approaches?

[dimaMachina]

you can override generateStaticParams with desired locales in

nextra/examples/swr-site/app/[lang]/[[...mdxPath]]/page.tsx

Line 6 in 627d88f

export const generateStaticParams = generateStaticParamsFor('mdxPath')