Vikunja项目中的日期本地化问题分析与解决方案

问题背景

在Vikunja项目的前端实现中，用户报告了日期显示本地化不正确的问题。具体表现为：当界面语言设置为意大利语等非英语语言时，日期相关显示仍保持英文格式。经过排查发现，这一问题不仅影响意大利语，还涉及俄语等多个语种的日期本地化。

技术分析

多语言支持架构

Vikunja前端采用了双重日期处理库的设计：

1. dayjs：用于大部分日期处理
2. date-fns：用于特定场景的日期格式化

这种双库并存的设计在初期可能出于历史原因或特定功能需求，但也带来了维护复杂性。

问题根源

深入分析后发现三个关键问题点：

1. 语言代码映射不一致
   Vikunja使用包含地区信息的完整语言代码（如zh-CN），而dayjs使用简化代码（如zh）。两者间的转换处理存在不一致性。

2. 翻译字符串错误
   在俄语等语言的翻译文件中，"date.locale"字段被错误地设置为"en"，导致日期格式化时强制使用英语。

3. 本地化加载机制缺陷
   缺少统一的locale切换机制，不同模块各自处理语言切换，导致行为不一致。

解决方案

1. 统一语言代码转换

建立标准的语言代码映射机制，确保Vikunja的语言代码能正确转换为dayjs识别的格式。例如：

• "it-IT" → "it"
• "ru-RU" → "ru"

2. 修复翻译文件

修正各语言包中的"date.locale"字段，确保其值对应dayjs支持的正确语言代码。

3. 实现集中式locale管理

重构代码实现统一的locale管理：

// 伪代码示例
function setDayjsLocale(vikunjaLocale: string) {
  const dayjsLocale = convertToDayjsLocale(vikunjaLocale);
  dayjs.locale(dayjsLocale);
}

// 在语言切换时调用
i18n.onLanguageChanged(setDayjsLocale);

经验总结

1. 避免多库实现相同功能
   在可能的情况下，应统一使用单一日期处理库，减少维护成本。

2. 建立完整的locale测试用例
   针对每个支持的语言，都应包含日期格式化的测试用例。

3. 文档记录设计决策
   对于SUPPORTED_LOCALES等关键配置，应添加详细注释说明其维护规则。

后续优化建议

1. 考虑逐步迁移到单一日期库
2. 建立自动化检查机制，确保新增语言包包含正确的日期本地化配置
3. 在前端CI流程中加入日期本地化的自动化测试

该问题的解决过程展示了在全球化项目中处理日期本地化的典型挑战，也为类似项目提供了有价值的参考经验。