iOS 多语言本地化以前的流程挺割裂的：代码在 VS Code 里写，一到要加翻译、对 key，就得切回 Xcode 打开那个 .xcstrings 的 String Catalog 界面，弄完再切回来。来回切倒不累，烦的是上下文总断——刚在代码里改了个 NSLocalizedString 的 key，转头得去另一个窗口补翻译，经常改完代码就忘了同步，跑起来一看界面还是英文（苦笑）。
后来发现 KXApp（快蝎）这个 VS Code 插件把 String Catalog 的可视化编辑直接搬进了 VS Code，.xcstrings 双击就是和 Xcode 一样的表格，代码和翻译在同一个窗口里。这篇就按实际操作顺序，把 iOS 多语言本地化在 VS Code 里怎么操作一遍讲清楚——从打开目录到源码同步、再到复数和变量这些细节。项目还是在 Xcode 项目，翻译存的也还是标准的 .xcstrings，回 Xcode 打开一模一样
先说清楚：String Catalog 到底在管什么
动手之前得知道这套东西的结构，不然编辑器点开一脸懵。
从 Xcode 15 起，苹果主推的本地化载体是字符串目录（String Catalog），文件后缀 .xcstrings，本质是个 JSON，把一个 key 在各种语言下的翻译、复数变化、设备变化全装在一个文件里。它替代了过去零散的 Localizable.strings ——但老的 .strings 和 .stringsdict 并没废，很多老项目还在用。
KXApp 的多语言编辑器把这几种文件放进同一张表来编辑：.xcstrings、.lproj 目录下的 .strings 和 .stringsdict 都认。表格每一行是一个 key，每一列是一种语言，每种语言还标着翻译进度（翻了多少、还剩多少没翻）。这意味着新老项目都能用一套界面处理，不用为了几个老 .strings 文件再去记手改语法。
一句话：String Catalog 把"一个文案的所有语言和变体"收进一个文件，KXApp 让你在 VS Code 里用表格改它，而不是手抠 JSON。
第一步：打开 .xcstrings，认清这张表
在 VS Code 的资源管理器里双击 Localizable.xcstrings，KXApp 就用表格编辑器打开它。左边是 key 列表，右边每列对应一种语言。
想看原始 JSON 也行——右键文件选「以文本方式打开」，或者在编辑器标题栏切换视图。我一般编辑时用表格，排查"为什么某个 key 没生效"时切到文本看原文，两个视图来回对，挺方便。
小提醒：
.xcstrings是 JSON，手改容易漏逗号、搞乱转义，尤其带变量和复数的条目结构不简单。能用表格就别手敲 JSON，省得格式一坏整个文件 Xcode 都读不出来。
第二步：加语言，别只在文件里加
要支持一门新语言，直接在编辑器里添加。关键点在这儿：KXApp 加语言时会同时把它登记到工程的已知语言列表里，和你在 Xcode 里点「+」加语言是一个效果。
这步容易踩坑。有些人图省事，直接往 .xcstrings 的 JSON 里塞一门语言的翻译，结果工程的 known regions 里没登记，打包出来那门语言压根不生效。KXApp 这里一步到位，加完语言表格里立刻多出一列，工程配置也同步改好了，不用再回 Xcode 补。
第三步：从源码同步字符串，把新 key 收进来
这步是我觉得最省事的地方。你在代码里新写了几处本地化调用，比如：
// 代码里新增的文案
let title = String(localized: "onboarding.welcome.title")
label.text = NSLocalizedString("settings.logout.confirm", comment: "")
不用手动把这两个 key 抄进 .xcstrings。在编辑器里点「从源码同步」，KXApp 扫一遍源码里的本地化调用，把新出现的 key 自动加进表格，等着你填翻译就行。
如果你项目里包了自己的本地化宏——很多团队会封装个 L("key") 之类的简写——默认扫描可能认不出来。这时候去设置里把你的宏名字告诉它：
// .vscode/settings.json
{
// 自定义的本地化宏，源码同步时也会被扫描
"kxapp.l10n.extraMacros": ["L", "LocalizedString"]
}
配好之后，自定义宏里的 key 也能被一起收上来。这个细节对老项目特别有用，省得一个个手工找漏网的文案。接手一个历史包袱重的项目时，我头一件事就是配好宏名、跑一遍源码同步，先把散落在各处、以前压根没进 catalog 的 key 一次性收齐，再回头慢慢补翻译，比盲找效率高太多。
第四步：翻译，处理复数、设备和变量
真正翻译的时候，几种麻烦情况编辑器都接住了：
- 按复数变化：英文 "1 item / 2 items" 这种，按 key 展开复数规则（zero/one/other 那套），每种情况分开填。
- 按设备变化：同一句话在 iPhone 和 iPad 上想显示不同措辞，可以按设备拆。
- 替换变量：带
%@、%lld这类占位符的，变量在表格里标出来，翻译时照着摆位置，不怕漏。 - 翻译状态标记：每条可以标「需复核」「已复核」，或者标「不翻译」（比如品牌名、纯符号的占位文案）。扫一眼进度就知道哪些还没弄完。
这些状态不是 KXApp 自己发明的，是 String Catalog 本来就有的字段，所以标记完回到 Xcode，状态也对得上。
第五步：改了源语言文本，记得复核
还有个容易忽略的点。你把源语言（比如中文）的某句话改了措辞，那其它语言里对应的旧翻译其实已经对不上了。
KXApp 和 Xcode 一样的处理：改动源语言文本后，已有的其它语言翻译会自动标成「需复核」，提醒你回头检查。不想要这个行为可以关掉：
// .vscode/settings.json
{
// 改源语言文本时，是否把已有翻译标为"需复核"，默认开
"kxapp.l10n.markSourceEditsForReview": false
}
我个人是留着开的——源文案一改，翻译大概率得跟着动，自动标出来比事后靠记强。
翻译完怎么确认真的生效
表格里全标「已复核」还不够，得真跑起来看一眼。本地化最常见的翻车是：翻译填了，运行时界面却还是源语言，十有八九是 key 对不上、或者那门语言没登记进工程。
验证的办法不复杂。KXApp 底层调的是你 Mac 上的 Xcode，构建和运行跟在 Xcode 里一样：在 VS Code 状态栏切好 scheme 和目标设备，Cmd+R 装到 iPhone 或模拟器上跑。想单独验某门语言，可以在运行配置里把 App 的语言固定成那一门，起来直接就是该语言界面，不用去改整个系统的语言设置来回折腾。跑起来一屏扫过去，哪条没翻、哪条串行了一眼就看出来，比在表格里干瞪着进度条踏实。
和其他几种做法比一比
- Xcode 自带的 String Catalog 编辑器：功能最正统，毕竟是苹果自家的。缺点是你得切去 Xcode，代码和翻译分在两个 App 里。
- 手改 .strings / .xcstrings：纯文本编辑谁都会，但
.xcstrings是 JSON，复数和变量的结构手写容易错，不推荐常态这么干。 - Lokalise、POEditor 这类平台：适合翻译团队协作、走导入导出流程，大项目值得上；小项目或个人开发有点重。
- KXApp 在 VS Code 里编辑：好处是和写代码同一个窗口，源码同步、加语言、复数变量都在表格里点，不用切 Xcode；它底层还是调你 Mac 上的 Xcode 来构建，翻译文件格式也标准，和团队里用 Xcode 的同事并不冲突。
没有谁能替换谁。翻译团队协作该上平台还上平台；但日常你自己写代码顺手就把文案本地化处理了，在 VS Code 里用 KXApp 这套，确实少切好几次窗口。
