第23章 MVC中的国际化与本地化

课程目录第23章 MVC中的国际化与本地化

23、MVC中的国际化与本地化：多语言支持与本地化适配实战

国际化与本地化，说白了就是让你的MVC应用能说“人话”——不同国家用户的人话。我做了这么多年项目，发现很多团队把这事想得太复杂，其实核心就三件事：文本翻译、格式适配、布局兼容。

今天咱们就聊聊，在MVC架构里怎么优雅地搞定多语言支持。我会结合自己踩过的坑，给你一套可落地的方案。

一、国际化的核心概念

先理清两个词：

国际化（i18n）：让应用具备支持多语言的能力，说白了就是“打地基”
本地化（l10n）：针对特定地区做适配，比如中文、日期格式、货币符号

我习惯把i18n比作“插座标准”，l10n就是“插头适配器”。你想想看，没有标准插座，后面适配再多插头也白搭。

核心原则：代码中不要出现任何硬编码的文本、日期格式、货币符号。所有用户可见的字符串都必须通过资源文件加载。

二、MVC中的国际化架构

在MVC里，国际化应该贯穿三层：

View层：显示翻译后的文本，格式化日期/数字
Controller层：根据用户语言偏好选择资源文件，处理本地化逻辑
Model层：存储多语言数据（比如商品名称的多语言版本）

我曾经在一个项目中，把翻译逻辑全塞在View里，结果维护起来简直噩梦。后来重构时，我坚持在Controller层做语言路由，View只负责展示——清爽多了。

下面这张图展示了典型的MVC国际化流程：

三、资源文件管理

资源文件是国际化的基石。我推荐用properties或JSON格式，按语言+地区命名：

# messages.properties（默认，通常是英文）
greeting=Hello
welcome.message=Welcome to our application
date.format=MM/dd/yyyy

# messages_zh_CN.properties（简体中文）
greeting=你好
welcome.message=欢迎使用我们的应用
date.format=yyyy年MM月dd日

# messages_ja_JP.properties（日语）
greeting=こんにちは
welcome.message=私たちのアプリケーションへようこそ
date.format=yyyy年MM月dd日

我的经验：资源文件中的key命名要有层次感，比如用点号分隔模块。我习惯用 模块.功能.具体描述 的格式，这样后期维护时一眼就能找到位置。

四、Controller层的语言路由

在Controller里，我通常用拦截器或过滤器来做语言路由。核心逻辑是：

从请求中获取用户语言偏好（Cookie、请求头、URL参数）
匹配可用的语言资源
将Locale对象绑定到当前线程或请求上下文

来看一个Spring MVC的示例：

@Controller
public class HomeController {
    
    @Autowired
    private MessageSource messageSource;
    
    @GetMapping("/")
    public String home(Locale locale, Model model) {
        // locale由Spring的LocaleResolver自动注入
        String greeting = messageSource.getMessage("greeting", null, locale);
        String welcome = messageSource.getMessage("welcome.message", null, locale);
        
        model.addAttribute("greeting", greeting);
        model.addAttribute("welcome", welcome);
        
        return "home";
    }
}

嗯，这里要注意：Locale参数Spring会自动解析，但前提是你配置了LocaleResolver。我曾经忘了配这个，结果所有用户都看到英文界面，被测试妹子追着骂了一下午。

五、View层的国际化渲染

View层要做的事很简单：从资源文件取文本，格式化日期和数字。以Thymeleaf为例：

<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org">
<head>
    <title th:text="#{page.title}">默认标题</title>
</head>
<body>
    <h1 th:text="#{greeting}">Hello</h1>
    <p th:text="#{welcome.message}">Welcome</p>
    
    <!-- 日期格式化 -->
    <p th:text="${#dates.format(today, #messages.msg('date.format'))}"></p>
    
    <!-- 带参数的国际化消息 -->
    <p th:text="#{order.confirmation(${orderId})}"></p>
</body>
</html>

资源文件中对应的参数化消息：

order.confirmation=您的订单 {0} 已确认

六、Model层的多语言数据

有些数据是动态的，比如商品名称、文章标题，这些不能写死在资源文件里。我常用的方案是：

方案	适用场景	优点	缺点
多语言字段表	数据量小，字段少	查询简单	表结构膨胀
翻译关联表	数据量大，多语言版本多	扩展性好	查询需要JOIN
JSON字段存储	NoSQL或支持JSON的数据库	灵活，无需额外表	索引和查询受限

我个人比较推荐翻译关联表方案。举个例子：

-- 商品主表
CREATE TABLE product (
    id BIGINT PRIMARY KEY,
    sku VARCHAR(50),
    price DECIMAL(10,2)
);

-- 商品翻译表
CREATE TABLE product_translation (
    product_id BIGINT,
    locale VARCHAR(10),  -- 'zh_CN', 'en_US'
    name VARCHAR(200),
    description TEXT,
    PRIMARY KEY (product_id, locale)
);

查询时根据用户语言关联翻译表：

SELECT p.id, p.price, pt.name, pt.description
FROM product p
LEFT JOIN product_translation pt 
    ON p.id = pt.product_id AND pt.locale = ?
WHERE p.id = ?

避坑指南：我曾经在翻译表上没加locale索引，结果上线后查询慢得像蜗牛。记住，locale字段一定要建索引，而且联合主键的顺序要把locale放在前面。

七、本地化适配的细节

国际化不只是翻译文本，还有很多“隐形”的适配工作：

日期格式：美国用MM/dd/yyyy，中国用yyyy-MM-dd，日本用yyyy年MM月dd日
数字格式：千位分隔符不同，小数点符号不同
货币符号：$、¥、€，而且位置不同（$100 vs 100¥）
排序规则：中文按拼音，日文按五十音图，德文有特殊字符排序
文本方向：阿拉伯语、希伯来语是从右到左

Java中可以用java.text包下的类来处理：

// 数字格式化
NumberFormat nf = NumberFormat.getNumberInstance(locale);
String formatted = nf.format(1234567.89);  // 中文：1,234,567.89

// 货币格式化
NumberFormat cf = NumberFormat.getCurrencyInstance(locale);
String currency = cf.format(99.99);  // 中文：¥99.99

// 日期格式化
DateFormat df = DateFormat.getDateInstance(DateFormat.LONG, locale);
String date = df.format(new Date());  // 中文：2024年1月15日

八、实战中的常见坑

这些年我踩过的坑，列出来给你提个醒：

硬编码字符串：哪怕是一个“确定”按钮，也要从资源文件取。我见过有人偷懒直接写死，结果后期要加日语支持时，满世界找字符串。
忽略区域变体：zh_CN和zh_TW虽然都是中文，但用词和编码不同。别偷懒只做一个中文资源。
忘记处理复数形式：英文有单复数（1 item vs 2 items），中文没有。如果你的资源文件要兼顾多种语言，建议用ICU MessageFormat。
缓存问题：资源文件修改后，如果不重启应用或清缓存，用户看到的还是旧翻译。我习惯用带版本号的资源文件名。

我的建议：国际化不是后期加的“补丁”，而应该在项目启动时就规划好。哪怕你只做中文版，也要用资源文件管理所有文本。这样未来扩展时，你只需要加文件，不用改代码。

九、测试国际化

测试多语言支持，我一般分三步走：

功能测试：切换不同语言，检查所有页面文本是否正确显示
边界测试：测试不存在的语言、空语言、特殊字符（比如日文汉字、阿拉伯文）
布局测试：不同语言文本长度不同，比如德文单词很长，可能导致按钮溢出。我习惯用“最坏情况”的文本测试布局

自动化测试中，我会写一个脚本遍历所有资源文件，检查是否有缺失的key：

// 伪代码：检查资源文件一致性
Set<String> defaultKeys = loadKeys("messages.properties");
for (String locale : availableLocales) {
    Set<String> localeKeys = loadKeys("messages_" + locale + ".properties");
    Set<String> missing = new HashSet<>(defaultKeys);
    missing.removeAll(localeKeys);
    if (!missing.isEmpty()) {
        System.err.println("Locale " + locale + " 缺少key: " + missing);
    }
}

好了，关于MVC中的国际化与本地化，核心就是这些。记住：好的国际化设计，是让用户感觉这个应用本来就是用他的语言开发的，而不是生硬翻译过来的。

📚 课程目录

23、MVC中的国际化与本地化：多语言支持与本地化适配实战

一、国际化的核心概念

二、MVC中的国际化架构

三、资源文件管理

四、Controller层的语言路由

五、View层的国际化渲染

六、Model层的多语言数据

七、本地化适配的细节

八、实战中的常见坑

九、测试国际化