Localizable.strings 检查器
放入两个或更多 .strings 文件，看看少了什么、重了什么、哪些其实从没被翻译过，以及哪些行根本解析不了。不会上传——这些通常是生产环境的文件，它们就留在这一页里。
重复值这条规矩
两个键配着同一句英文，是那种反复回来的老毛病。译者看到同一句出现两次，就翻两次，得到两个不同的结果——更糟的情况是，某种语言本该在两个语境里用不同的词，结果两处用了同一个词，直到母语者抱怨才有人发现。这项检查会忽略大小写和末尾标点，因为 "Done" 和 "Done." 是同一个问题换了顶帽子。
「一模一样」不等于「没翻译」
和基准文件一样的值，通常意味着还没人动它。有时候它就是对的——品牌名、单位、在每种语言里都原样不动的缩写。工具只把它们标出来，判断留给你，因为别的做法要么会漏掉真正的缺口，要么会为每一个 OK 唠叨个不停。
坏行会被报出来，而不是被咽下去
.strings 的语法很小，但边角情况是真实存在的：块注释、值里被转义的引号、漏掉的分号、从表格里粘过来的花引号。一个默默跳过读不懂内容的解析器，会在某个键悄悄消失的时候告诉你这个文件没问题。所以每一行解析不了的内容都会连着行号列出来，方便你去看一眼。
UTF-16 也一样
Xcode 多年来一直会把 .strings 写成 UTF-16，很多仓库里至今仍有这样的文件。所以文件会先被嗅探字节序标记再按对应编码解码，免得一个 UTF-16 文件变成满屏空字节和上百条解析错误。
常见问题解答
它支持 .xcstrings 吗？
还不支持。字符串目录是形状完全不同的 JSON，它值得有自己的处理方式，而不是一层只能勉强凑合的转换。
该把哪个文件当基准？
哪一个是权威的就用哪一个——通常是开发语言。所有比较都以它为准，所以某个键在基准里没有、在别处却有，会被报成多余而不是缺失。
什么算一处问题？
缺一个键、值重复、值和基准完全相同，或者某一行解析不了。这个计数把所有文件里的这几类加在一起。
我的文件会被上传吗？
不会。它们由浏览器的文件读取器读入，比较也在这里完成。这一点对这个工具比对别的都重要，因为它们是真正的产品文件。
由反复撞上这个问题的 GO AI 团队打造。 全部免费工具