在非国际化路由的Next.js项目中集成Lingui的实践指南

背景介绍

在Next.js项目中，当我们需要实现多语言支持但又不希望使用国际化路由（即不在URL中包含语言标识，如domain.com/contact而非domain.com/en/contact）时，会遇到一些特殊的挑战。Lingui作为一款优秀的国际化库，其官方示例主要基于Next.js的国际化路由功能实现，这给不使用该功能的开发者带来了困惑。

核心问题分析

传统Lingui与Next.js集成方案依赖于router.locale来获取当前语言环境。但当禁用Next.js内置的i18n路由功能后，这一属性将不可用。此时开发者需要自行实现语言检测机制，并确保在服务端和客户端都能正确工作。

解决方案详解

服务端语言检测

在服务端渲染(SSR)场景下，我们可以通过HTTP请求头来检测用户偏好语言。在Next.js的getServerSideProps方法中，可以这样实现：

export async function getServerSideProps(context) {
  const acceptLanguage = context.req.headers['accept-language'];
  const userLocale = detectLocaleFromHeaders(acceptLanguage);
  
  return {
    props: {
      locale: userLocale
    }
  };
}

客户端语言检测

在客户端，我们可以使用浏览器提供的navigator.languageAPI来获取用户语言偏好：

const getClientLocale = () => {
  return navigator.language.split('-')[0];
};

统一处理方案

为了在服务端和客户端都能正确初始化Lingui，我们需要创建一个自定义hook来统一处理语言环境：

import { useRouter } from 'next/router';

export function useLinguiInit(locale) {
  const router = useRouter();
  
  // 优先使用props传入的locale
  // 如果没有则尝试从router获取（兼容国际化路由）
  // 最后回退到客户端检测
  const activeLocale = locale || router.locale || getClientLocale();
  
  // 初始化Lingui配置
  // ...
}

实现注意事项

1. 语言持久化：考虑使用cookie或localStorage存储用户选择的语言偏好，避免每次刷新都重新检测

2. 回退机制：当检测到的语言不支持时，应回退到默认语言

3. 性能优化：避免在客户端频繁检测语言，特别是在静态生成(SSG)页面中

4. SEO考虑：确保服务端渲染时返回正确的语言内容，这对搜索引擎优化很重要

最佳实践建议

1. 创建一个语言上下文(Context)来全局管理当前语言状态

2. 实现语言切换组件时，更新上下文而非仅依赖URL参数

3. 对于静态页面(SSG)，考虑预生成所有语言版本并通过客户端路由切换

4. 在_app.js中统一处理语言初始化逻辑，避免重复代码

通过以上方案，开发者可以在不使用Next.js国际化路由的情况下，依然能够完美集成Lingui实现多语言支持，同时保持应用的简洁URL结构。这种方案特别适合那些对URL有严格要求或需要保持简洁URL结构的项目。