国际化 dev 5.2.x 增量翻译 main 4.1.x 6 语言

版本边界（以 qxj_harmony_next_pad_nsp_browser 仓库为准）

1. 覆盖范围

QXJ 浏览器面向的使用场景横跨内地气象业务单位、港澳地区协作单位以及外籍 / 日语技术人员，因此国际化在交付版中即为一等公民，而非事后补丁：界面上从工具栏、菜单、设置页到错误提示、关于页的全部可见文案，均纳入多语言资源管理。

简繁分离为四份资源，而不是「一份简中 + 运行时转换」，是为了正确处理三地不同的用词习惯（如台湾、港澳在气象、软件术语上的差异）与本地化表达。

项目采用多 HAR / HAP 模块化结构，国际化资源也按模块各自维护，避免全局资源冲突：

每个模块的 src/main/resources/<限定符>/element/string.json 存放该模块的字符串；另有 resources/base 作为不限定语言的兜底资源。
各模块通过 $r('app.string.xxx') 引用本模块资源，键名按模块加前缀以语义分组，例如浏览器模块的 browser_back、about_app_name，设备模块的 device_*。
字符串不仅用于静态布局，也用于动态提示：需要格式化的场景（如导出成功 N 条、绑定成功并带服务器名）通过资源管理器 getStringSync($r(...), args) 按当前语言完成占位替换。

各模块的资源规模（每种语言条数，6 份严格对齐）：

应用不提供应用内语言切换入口，而是完全跟随系统语言：

代码中不存在任何自定义的语言设置 / 配置更新逻辑（全仓检索 setAppPreferredLanguage、preferredLanguage、updateConfiguration 等均无业务侧命中），语言选择完全交给操作系统。
ArkUI 在解析 $r 资源时，依据系统当前的语言 / 地区限定符自动选取最匹配的 string.json，并按系统资源回退链处理：命中具体地区资源优先；无对应语种时回退到相近语种与 base 兜底，保证不会直接显示键名。
系统语言在运行时变更后，资源引用自动重算，无需应用重启逻辑。

这种选择的工程考量是：专网平板由单位统一发放与管理，语言跟随系统与设备的区域设置保持一致，既减少一个需要维护的设置项，也避免「系统是一种语言、应用是另一种语言」造成的割裂。

6 份资源均为真实人工翻译，抽查可验证：

所有语言的键数与简中严格一致，不存在「简中更新后其他语言漏翻」的结构性缺口。

dev 分支的国际化策略与 main 一致，差异仅是功能扩张带来的字符串增量：

browser 模块的资源从每语言 134 键增长到约 229 键（6 语言合计由 804 增至 1375，新增约 570 条翻译），覆盖多标签、下载、查找、阅读、无痕、广告拦截、开发者工具、用户脚本等实验界面。
新增字符串同样在 6 种语言中同步提供翻译，语言列表与匹配机制不变。
common 与 device 模块的语言资源在两分支间无变化。

因此「支持几种语言」在 4.x 与 5.x 上没有区别；5.x 的国际化工作量主要是随功能演进而持续保持各语言资源同步。