Next-Intl项目中多域名路由与本地化前缀的优化方案

背景介绍

Next-Intl是一个为Next.js应用提供国际化(i18n)支持的库。在实际应用中，开发者经常需要处理多域名场景下的国际化路由配置，特别是当不同域名需要共享部分语言但又各自拥有默认语言时，路由前缀的处理变得尤为复杂。

原有方案的问题

在Next-Intl的早期版本中，当配置localePrefix: 'as-needed'与多域名(domains)时，存在一个显著的技术挑战。例如，考虑以下配置：

{
  locales: ['en', 'fr'],
  defaultLocale: 'en',
  localePrefix: 'as-needed',
  domains: [
    {
      domain: 'ca.example.com',
      defaultLocale: 'en'
    },
    {
      domain: 'fr.example.com',
      defaultLocale: 'fr'
      locales: ['fr']
    }
  ]
}

在这个例子中，法语(fr)既作为非默认语言出现在ca.example.com上（需要/fr前缀），又作为默认语言出现在fr.example.com上（不需要前缀）。这种多对多的关系导致静态生成时无法确定是否应该添加前缀，因为相同的[locale=fr]可能用于两种场景。

技术解决方案

Next-Intl团队提出了一个更优雅的解决方案：要求每个语言代码在域名配置中必须是唯一的。这意味着需要将通用语言拆分为区域化变体，例如：

{
  locales: ['en-CA', 'fr-CA', 'fr-FR'],
  defaultLocale: 'en-CA',
  localePrefix: {
    mode: 'as-needed',
    prefixes: {
      'fr-CA': '/fr'
    }
  },
  domains: [
    {
      domain: 'ca.example.com',
      defaultLocale: 'en-CA',
      locales: ['en-CA', 'fr-CA']      
    },
    {
      domain: 'fr.example.com',
      defaultLocale: 'fr-FR',
      locales: ['fr-FR']
    }
  ]
}

这个方案的关键改进点包括：

1. 语言代码唯一性：每个语言代码只属于一个域名，消除了多对多关系
2. 精确的前缀控制：可以针对特定语言代码设置是否需要前缀
3. 静态生成优化：在构建时就能确定路由前缀，无需客户端调整

实际应用案例

以一个跨国网站为例，需要支持瑞典、挪威和美国的多个语言版本：

{
  locales: ['sv-SE', 'en-SE', 'no-NO', 'en-NO', 'fr-FR', 'en-US'],
  defaultLocale: 'en-US',
  localePrefix: {
    mode: 'as-needed',
    prefixes: {
      'en-SE': '/en',
      'en-NO': '/en',
      'en-US': '/en',
      'fr-FR': '/fr'
    }
  },
  domains: [
    {
      domain: 'domain.se',
      defaultLocale: 'sv-SE',
      locales: ['sv-SE', 'en-SE']      
    },
    {
      domain: 'domain.no',
      defaultLocale: 'no-NO',
      locales: ['no-NO', 'en-NO']
    },
    {
      domain: 'domain.com',
      defaultLocale: 'en-US',
      locales: ['en-US', 'fr-FR']
    }
  ]
}

这种配置方式使得：

• 瑞典站点默认显示瑞典语，英语版本路径为/en
• 挪威站点默认显示挪威语，英语版本路径为/en
• 国际站点默认显示美式英语，法语版本路径为/fr

技术优势

1. 消除渲染歧义：每个语言代码对应唯一的域名，SSR时能准确决定是否添加前缀
2. 更好的类型安全：使用完整语言代码(如en-US)而非通用代码(如en)
3. 本地化更精确：能够根据地区差异显示不同的日期、数字格式
4. 消息共享灵活：仍可通过语言基础代码(如en)共享大部分翻译内容

开发者注意事项

1. 在开发环境下，当访问localhost等未配置域名时，系统会选择匹配前缀的第一个语言
2. 对于确实需要跨域名共享语言的情况，建议使用区域化变体(如en-US和en-GB)
3. 可以通过Intl.Locale API轻松提取语言或地区信息，实现更精细的UI适配

总结

Next-Intl的这一改进显著提升了多域名国际化应用的路由处理能力，使开发者能够构建更健壮、更可预测的国际化应用。通过要求语言代码与域名的明确对应关系，解决了之前版本中的渲染歧义问题，同时为应用提供了更精确的本地化能力。