能否用SQLite替代strings.xml存储应用翻译实现应用内语言切换？

将翻译文本存储在SQLite的做法完全具备技术可行性，它是否属于不良实践没有绝对答案，核心要匹配你的具体使用场景。

为什么这套方案恰好适配你的需求 #

你的应用面向的是多数移动设备系统不内置对应语言的用户群体，这种场景下，SQLite存翻译的适配度甚至比传统的strings.xml原生方案更高：

• 彻底绕开系统资源匹配的绑定限制。传统多语言的核心逻辑和系统内置的语言列表是深度耦合的：哪怕你把稀有语言的翻译文件放到了规范命名的values资源目录下，系统的资源检索规则也未必能识别这类非内置语言。你之前调研编程修改应用语言时遇到的各类碎片化问题——比如配置变更后应用语言自动重置、不同Android版本的上下文适配bug——本质都是在和系统的资源规则做对抗。改用SQLite存翻译时，所有文本加载逻辑完全由你自己掌控，根本不需要去适配系统那套不断变动的资源匹配逻辑。
• 实现门槛极低。你只需要设计最基础的数据库表结构：比如建一张i18n_text表，设置id、language_code、text_key、translated_content四个核心字段；应用启动时根据用户选择的语言，把对应所有翻译条目加载到内存的哈希表中；封装一个替代原生getString()的文本读取工具类，就能完全替换原本依赖strings.xml的文本加载流程。
• 迭代灵活性极强。后续要新增支持的语言变体、修改翻译措辞，甚至做不需要发版的翻译热更新，都不用折腾新建资源目录、调整资源匹配规则的流程，只需要更新数据库里的对应条目即可。

什么情况下这套方案会变成不良实践 #

如果脱离了“面向系统不支持的稀有语言用户”这个核心场景，这套做法大概率会变成冗余的错误选择：

• 如果你的应用只覆盖系统内置的主流语言，完全没必要放弃strings.xml的成熟基建：原生资源系统自带自动语言匹配、翻译完整性lint检查、IDE文本预览、无障碍服务自动识别文本、应用商店元数据自动适配等一堆开箱即用的能力，改用SQLite存翻译相当于主动放弃这些便利，平白增加自己的开发维护成本。
• 就算在你的稀有语言场景下，以下操作会把这套合理的方案变成坏实践：
  • 没有把对应语言的翻译条目预打包进安装包，让用户首次打开应用时还要联网下载翻译内容，导致界面白屏、文本加载不全。
  • 没有做文本缺失兜底逻辑：如果某个语言下的某条翻译缺失，直接给用户展示空值或者原始的text_key，而不是自动降级到默认语言的同key文本。
  • 为了走自定义的文本加载流程，跳过原生View的文本设置步骤，导致无障碍服务无法读取应用内的展示内容，直接影响视障用户的使用体验。

和传统应用内切语言方案的长期对比 #

传统的应用内切换语言方案，本质是通过修改系统上下文的配置信息，强行让系统加载你放在strings.xml里的稀有语言资源——这套逻辑天然受系统API变更、版本碎片化的影响，长期维护成本极高。而SQLite存储翻译的方案，相当于你把多语言的控制权完全从系统手里拿了回来，不存在被系统规则卡脖子的问题，长期运行的稳定性反而更强。

内容的提问来源于stack exchange，提问作者San Arsa