[OSS101] Task 1: Refactor the existing multiple languages feature by adopting a third i18n library

[tyn1998]

Description

This task originates from #669.

What is i18n?

Internationalization, abbreviated as i18n, is a process of designing software so that it can be adapted to various languages and regions without significant changes to its structure. It allows software to manage and integrate different languages easily from a localization perspective, enhancing the user experience.

Current Scheme and Its Limitations

HyperCRX currently uses a rudimentary self-contained module get-message-by-locale.ts to handle internationalization. Although this module meets basic i18n needs, it exhibits several significant limitations:

• Hardcoding and maintainability issues: Language resources are hardcoded directly into the source files, requiring code modifications and re-deployments with each addition or update of translations.
• Lack of dynamic loading support: All language resources are loaded statically at application startup, which does not support on-demand loading and may lead to prolonged initial load times.
• Lack of robust error handling: The code uses @ts-ignore to ignore TypeScript's type checking and lacks handling for non-existent locale or key.
• Limited advanced features: The implementation does not support advanced i18n features such as pluralization, context variations, and formatting.
• No support for hot updates: Updating translation resources requires redeploying the application, lacking support for hot updates.

Recommended Improvement Plan

To address these limitations and enhance the project's internationalization quality, it is recommended to introduce a mature third-party i18n library. We suggest using react-i18next, a powerful internationalization framework based on i18next widely used in React projects. Adopting react-i18next can bring the following benefits:

• Dynamic resource management: Supports on-demand loading of language resources, effectively reducing delays during initial loading.
• Robust feature support: Offers a wealth of internationalization features, such as plural forms, context support, and localization of dates and numbers.
• Ease of maintenance and expansion: The structure is clear and easy to expand and maintain, allowing easy additions or modifications of language resources.

Task Objectives

The goal of this task is to refactor the current multi-language feature of HyperCRX by replacing the existing self-contained module with react-i18next. Through this refactoring, we aim to improve the application's internationalization quality and user experience, while laying the foundation for potential future expansions.

任务描述

此任务来自 #669。

i18n是什么？

国际化（Internationalization，缩写为 i18n）是一个软件设计的过程，使得软件可以适配多种语言和地区，无需进行重大的结构改动。它允许软件从本地化的角度来轻松管理和集成不同语言，提供更佳的用户体验。

当前的方案及其局限性

HyperCRX 目前使用了一个简陋的自封装模块 get-message-by-locale.ts 来处理国际化需求。尽管该模块能基本满足简单的国际化需求，但存在以下局限性：

• 硬编码和可维护性问题：语言资源直接硬编码在源文件中，每次添加或更新翻译都需要修改代码并重新部署。
• 缺乏动态加载支持：所有语言资源在应用启动时静态加载，不支持按需加载，可能导致初始加载时间过长。
• 缺乏错误处理和健壮性：使用 @ts-ignore 忽略了类型检查，缺乏对不存在的 locale 或 key 的处理。
• 缺乏扩展功能：不支持复数、上下文变化、格式化等高级国际化功能。
• 不支持热更新：翻译资源的更新需要重新部署应用，不支持热更新。

推荐的改进方案

为了解决现有的局限性并提升项目的国际化质量，建议引入成熟的第三方国际化库。我们推荐使用 react-i18next，这是一个基于i18next的强大国际化框架，广泛应用于React项目中。引入 react-i18next 可带来以下好处：

• 动态资源管理：支持按需加载语言资源，有效减少初次加载时的延迟。
• 强大的功能支持：提供丰富的国际化功能，如复数形式、上下文支持、日期和数字的本地化等。
• 易于维护和扩展：结构清晰，易于扩展和维护，可以轻松添加或修改语言资源。

任务目标

本任务的目标是重构 HyperCRX 当前的多语言特性，采用 react-i18next 来替换现有的自封装模块。通过这次重构，我们期望能够提升应用的国际化质量和用户体验，同时为未来可能的扩展奠定基础。

[taketaketakeru]

我先用react-i18next实现了一个界面hypertrons-crx\src\pages\Options\Options.tsx的本地化，我是这样做的：① 配置i18n的相关信息 ② 将原来调用getMessageByLocale函数的部分替换成i18n的实现方法，比如替换为t('options_locale_title.message')。但我不确定这样实现是否正确？并且这样一来原来每处调用getMessageByLocale函数的部分都要进行修改，改用i18n实现本地化依旧很麻烦，也没有感受到上述提出的i18n的三个优点？

[wxharry]

我先用react-i18next实现了一个界面hypertrons-crx\src\pages\Options\Options.tsx的本地化，我是这样做的：① 配置i18n的相关信息 ② 将原来调用getMessageByLocale函数的部分替换成i18n的实现方法，比如替换为t('options_locale_title.message')。但我不确定这样实现是否正确？并且这样一来原来每处调用getMessageByLocale函数的部分都要进行修改，改用i18n实现本地化依旧很麻烦，也没有感受到上述提出的i18n的三个优点？

替换每处现有的getMessageByLocale是不可避免的，这应该不是问题。i18n的库更灵活，性能上也更高效。可能我们项目当前没有很多能体现它优势的地方，但改用i18n能有效帮助提高代码性能，也为我们以后的功能提供支持和灵活性。你可以先提一个PR，这样我们可以具体对着代码讨论，如果代码还处于未完成，可以把pr设置成draft。

[taketaketakeru]

我先用react-i18next实现了一个界面hypertrons-crx\src\pages\Options\Options.tsx的本地化，我是这样做的：① 配置i18n的相关信息 ② 将原来调用getMessageByLocale函数的部分替换成i18n的实现方法，比如替换为t('options_locale_title.message')。但我不确定这样实现是否正确？并且这样一来原来每处调用getMessageByLocale函数的部分都要进行修改，改用i18n实现本地化依旧很麻烦，也没有感受到上述提出的i18n的三个优点？

替换每处现有的getMessageByLocale是不可避免的，这应该不是问题。i18n的库更灵活，性能上也更高效。可能我们项目当前没有很多能体现它优势的地方，但改用i18n能有效帮助提高代码性能，也为我们以后的功能提供支持和灵活性。你可以先提一个PR，这样我们可以具体对着代码讨论，如果代码还处于未完成，可以把pr设置成draft。

好的，感谢回复