apk 汉化反过来做：把中文应用改成英文界面的四处漏点

做汉化的人多，反过来做的人少。原因不难理解：汉化是"把看不懂的变看得懂"，动力直接；反向外翻是"把自己看得懂的东西换成别人看得懂的"，中间少了一层"我也需要它"的紧迫感。

但只要真做过一次，就会发现这两件事的难度并不对称。汉化最大的困难是"看不懂原文"，翻一遍就好了；反向外翻最大的困难是"看不出哪里有中文"——因为你全都看得懂。

这个差别带来一个很实际的后果：做完之后你以为改完了，装到英文环境里一跑，发现还有一堆中文。某个弹窗、某句提示、某个按钮、某张引导图上的字——它们不在你以为的那个文件里。而它们在哪儿，取决于当初写这个应用的人是怎么写的。

这篇讲的就是这件事：中文在 Android 应用里通常藏在四个地方，每一处的找法和改法都不一样，漏掉任何一处，界面就会夹着中文。另外还会讲三个"翻译对了但界面还是不对"的原因——文字变长、语序拼接、格式本地化。这几件事加起来，就是"能不能交出去"的分界线。

只需说话，就能让应用变成你想要的样子。这句话在语言这件事上有它自己的意思：你不需要会写代码才能把中文挑出来，你只需要能说清"这个界面上所有给人看的字，都要换成英文，一个都别剩"。——而"一个都别剩"这四个字，恰好是这类需求里最容易被漏掉的部分。

一、先分清"该翻译的"和"不该动的"

在动手之前，有一件事必须先划清：应用里的字符串分两类，一类是给人看的，一类是给机器看的。

给人看的：按钮上的字、标题、提示语、错误信息、引导文案、设置项的名字、关于页的说明。这些要翻。

给机器看的：资源文件名、渠道标识、接口参数、SharedPreferences 里的键名、广播 action、JSON 的字段名、日志的 tag。这些绝对不能翻。——翻了不会"显示成英文"，而是"功能直接坏掉"。

这个边界听起来很浅，但它是最常见的翻车点。因为很多字符串在文件里长得一模一样：一行 <string name="xxx">中文</string>，你没法从外观判断它到底是显示在按钮上，还是被当成一个键去查表。

所以需求里应该先把边界说清："只翻译会显示在界面上的文字；不要改动任何资源文件名、配置项的键名、接口参数、日志标记。"——这句"不要改"比"要改什么"更重要，因为改错一个键名，应用可能起不来。

还有一种介于两者之间的：显示出来但同时也是逻辑的一部分。比如一个下拉框的选项文字，代码里可能是靠"文字内容"来判断选了什么。这类地方翻译之后，判断就永远不成立。——遇到这种，正确做法是"只改显示、不改判断依据"，或者干脆不动它，把这一处记进"已知遗留"清单。

二、第一处：写在布局里的中文

这是最容易被想到的一处，也是最容易被"以为已经改完"的一处。

正规的写法是把文字放进字符串资源文件，布局里只写一个引用。但现实中大量应用是直接把文字写在布局里的——因为写的时候快，而且不会报错。于是你会看到这样的东西：一行 android:text="确定"。

这类文字的麻烦不在于"难改"，而在于"难找全"。一个中等规模的应用，布局文件可能上百个，每个里面又有几十处文字属性。而其中真正会显示在屏幕上的，可能只有一部分——有些布局是废弃的、有些是隐藏的、有些只在特定条件下才出现。

所以这一处的做法，不是"打开文件一个个找"，而是把这件事整体交给工具去做："把这个应用里所有布局文件中直接写死的中文文字属性，全部替换成英文；同样是'确定'的地方统一成 OK，'取消'统一成 Cancel；不要改布局结构、不要动 id。"

"统一"这两个字值得单独说。因为同一个中文词，在不同地方可能被翻成不同的英文——"确定"可能是 OK，也可能是 Confirm，还可能是 Done。如果每个地方各翻各的，用户会觉得这个应用"说话不一致"，而这种感觉比"有中文残留"更微妙、也更难改。

所以更稳的写法是：在需求里给出一个"词表"。把最常出现的十几个词（确定、取消、保存、删除、返回、下一步、完成、设置、我的、退出、重试、加载中）各自指定一个英文写法，要求全文统一。——这十几行东西，能让最终结果的"专业感"提升一大截，而且它几乎不花时间。

三、第二处：写在代码里的中文

这一处是四个里最麻烦的，因为它不在你能"看见"的文件里。

应用里的字符串，除了放在资源和布局里，还有很大一部分是直接写在 Java 代码里的。代码编译之后，这些文字会变成常量，跟着代码一起进到 dex 文件里。所以你在资源目录里翻遍了也找不到它们——它们跟资源不是一回事。

这类文字最典型的三种形态：

第一种：Toast 提示。"保存成功"、"请先登录"、"网络不给力"——这类一闪而过的话，很多都是直接写在代码里的。而它们恰好是用户最常看到的文字之一。

第二种：异常和错误信息。比如 throw new RuntimeException("参数不能为空")。正常路径永远看不到它，所以测试的时候也不会发现它还是中文——直到用户真的遇到那个错误。

第三种：拼接出来的句子。比如 "共" + count + "条"。单独看"共"和"条"都是两个字的碎片，搜索的时候很难意识到它是一句话的一部分。

第三种的麻烦最大，而它的麻烦不在"找"，在"翻"。中文的"共 3 条"，在英文里是 "3 items"，顺序整个反过来了。如果你只是把"共"换成 "Total"、"条"换成 "items"，界面上会显示成 "Total 3 items"——语法上勉强能看，但再长一点就露馅了。比如"共 3 条，其中 1 条未读"，机械替换之后大概是 "Total 3 items, among 1 items unread"。看得懂，但一看就是翻译出来的。

所以这一处的需求，要写得比前一处细："应用里由代码直接输出的中文（Toast、对话框文字、错误提示），全部换成英文；特别注意拼起来的句子，不要逐词替换，要按英文语序重写整句；例如'共 X 条'改成 'X items'、'共 X 条，其中 Y 条未读'改成 'X items, Y unread'；不要在英文里保留中文标点。"

"不要在英文里保留中文标点"这一句，是很多人会漏的细节。中文的句号、逗号、括号、破折号，在英文界面里显得很突兀——尤其是一个英文句子里夹着一个全角逗号，那种"没做完"的感觉特别明显。

还有一个必须提前知道的边界：被加密的字符串改不了。有些应用（尤其是做过加固或者字符串混淆的）会把代码里的字符串加密存放，运行时才解出来。这种情况下，你在文件里看到的是一堆看不出意义的字符，改它等于破坏它。——遇到这种，正确处理是"记下来，说明这一处需要另想办法"，而不是硬改。硬改的结果通常是那个功能直接崩。

四、第三处：图片里的中文

这一处是四类里唯一"改不了"的——至少不是用改文字的方式能改的。

几乎每个应用都有几张"带字的图"：启动页上的应用名、引导页上的说明文案、活动横幅上的口号、空白页上的"暂无数据"插画、分享卡片上的水印。这些字是画在图片像素里的，不是文字。你不能"翻译"它，只能"重画"它。

所以在动手之前，先把这几张图找出来，这是最省事的顺序。做法很简单：把包解开，看图片资源目录，把里面明显带文字的图挑出来——启动图、引导图、横幅、logo、水印图。挑出来之后，你有三个选择：

选择一：换一张干净的图。如果那张图只是"纯色背景 + 一行字"，那完全可以做一张同尺寸的英文图替换掉。这是最干净的做法，也是这类问题最常见的解法。

选择二：把文字从图片里拿掉。让那张图只保留图形部分，文字改由界面上的文本框显示。这需要动布局，改起来涉及的地方多一些，但好处是"以后改文案不用改图"。

选择三：留着。这不是偷懒——如果那张图是品牌 logo，上面的中文本身就是品牌的一部分，那它不该被翻译。——"哪些中文该留"是品牌决策，不是技术决策，而这件事只有你能定。

这里我想强调一件容易被误解的事：工具能改的是"文字"，改不了"画面"。所以需求里写"把启动页的中文改成英文"，如果那行字是画在图里的，正确的做法是明确说"替换这张启动图"，而不是让它去"改图上的字"。——把需求说成"能做的那件事"，比说成"想要的那个结果"，成功率高得多。这也是使用这类工具时最值得养成的一个习惯。

五、第四处：语言这件事本身——为什么"加了英文资源还是不显示英文"

前三处都是"某段文字藏在哪儿"。这一处不一样，它讲的是"文字找出来了、也翻好了，但界面还是中文"——一个跟文字无关、跟机制有关的问题。

先讲一个基础事实：Android 的字符串资源是"按语言分目录"的。默认目录里放一套（通常就是开发者母语那套），然后可以有按语言代码命名的目录，各放一套翻译。应用运行时，系统会根据当前语言去挑最匹配的那一套；挑不到，就退回默认目录。

多数中文应用的情况是：只有默认目录，而默认目录里放的是中文。——所以你把手机语言切成英文，界面还是中文。这不是"翻译丢了"，是"没有英文那一套，系统只能退回中文"。

于是就有了两种改法，选错了会白干一轮。

改法一：直接把默认那一套改成英文。适合"只做英文版、不需要中英共存"的情况。这是绝大多数场景该选的路——因为它最稳：不管系统语言是什么，显示的都是英文，不用赌资源选择逻辑。

改法二：新增一套英文资源，默认那套保留中文。适合"中英双版本"的情况。它的好处是能跟着系统语言切换，坏处是"能不能切成功"取决于应用的资源选择是否正常——而这恰恰是很多不规范的应用会出问题的地方。

还有一个更隐蔽的坑：应用自己记了一个语言偏好。有些应用会在设置里提供"语言"选项，选了之后把结果存进本地配置，每次启动都按这个存下来的值去强制设置语言，完全不看系统。——这种情况下，你在系统里怎么切都没用，因为应用启动时又把语言改回去了。

所以第四处的需求，应该这样写："这个应用原来只有一套中文资源，请直接把默认资源里的文字全部改成英文，不要新增语言目录、不要依赖系统语言切换；如果应用里有自己的语言设置项，把那一项也改成英文显示，或者直接隐藏掉；不要改包名、不要动任何配置键名。"

"不要新增语言目录"这一句是有意为之的。因为它把"会不会显示英文"这件事，从"取决于系统"变成了"确定显示"。——这里的取舍很清楚：牺牲"中英共存"的灵活性，换取"一定生效"的确定性。而做外发版本时，确定性比灵活性值钱。

还有一类问题跟机制有关，但表现像"翻译漏了"：代码里自己判断了语言。比如某段代码写着"如果系统语言是中文，就显示 A 文案，否则显示 B 文案"。这类代码里的 B 文案，很可能本来就是中文——因为写代码的人默认"非中文用户看不到这里"。你把默认资源翻成英文，这段逻辑照样会走进 B 分支，然后显示那句中文。

这类地方只能靠"跑一遍"发现。所以验收的时候有个很具体的动作：系统语言切英文，把应用的每个页面走一遍，看到中文就记下来是哪个页面、什么操作触发的。——而那些"只在出错时才出现"的中文，靠走页面是发现不了的，只能用更笨的办法：把包解出来，搜一遍中文，看还剩哪些。

顺便说清一个常被混为一谈的边界：语言和地区不是一回事。英文有很多种写法（美式、英式），日期格式、货币符号、单位也跟着地区走。"改成英文"只是解决了"字写什么"，没解决"数字和日期怎么摆"。而后者是另一个问题，下一节单独说。——把它们分清，能避免"明明都翻成英文了，还是觉得哪里不对"这种说不清的别扭。

六、第五个问题（虽然不算"漏点"）：英文比中文长

前面四处在找"中文藏在哪儿"。这一节讲另一件事：中文全部换掉了，界面还是坏了——因为英文比中文长。

这是一个可以量化的差别：同样一句意思，英文占的宽度通常是中文的 1.5 到 2 倍。原因是中文一个字就是一个音节、一个完整意思，而英文一个词要好几个字母。再加一个事实：中文没有空格，英文每个词之间都要空一格。

几个真实的对照，看一遍就有感觉了：

"设置"两个字，换成 Settings 是八个字符；"我的订单"四个字，换成 My Orders 是九个字符还要多一个空格；"关于我们"换成 About Us 还好；但"删除后无法恢复"七个字，换成 This action cannot be undone 是二十八个字符——四倍。

而"删除后无法恢复"这句话，通常正好写在一个确认框的按钮上。——这就是为什么很多人翻完之后，第一个出问题的地方永远是确认框。

后果有三种，跟前面讲字号时的三种"死法"很像，但成因不同：第一种是按钮文字换行，两行字挤在原本一行的按钮里，按钮被撑高或者文字被裁掉；第二种是标签栏文字被压扁，底部五个标签本来每个两个字，现在每个七八个字母，第五个直接看不见；第三种是列表右侧的内容被推走，因为左边标题变长了，右边的数字或箭头被挤出屏幕。——第三种最危险，因为被推走的往往是"删除"或者"金额"。

应对的办法有五个，按性价比排：

第一，优先用短词。这是最有效的。OK 比 Confirm and continue 好；Save 比 Save changes 好；Delete 比 Permanently delete 好。——而"短"不等于"含糊"：能把后果放进副标题，就别塞进按钮。

第二，允许换行，但最多两行。一行放不下就换行，两行还放不下就说明这个词选得太长。——"最多两行"这个上限很关键，因为不设上限的话，某些地方会出现四行字撑成一个方块。

第三，容器宽度改成随内容自适应。这一条和字号那件事是同一个道理：只要容器愿意长宽，文字就不会被切。

第四，关键位置改成"图标 + 短词"。底部标签栏是最典型的地方：图标本身能表意，文字只做辅助，那文字就可以很短。——但要注意：纯图标不行。纯图标对不熟悉的用户是猜谜，对年长用户更糟。

第五，绝对不要用缩写凑长度。"Config"、"Mgr"、"Usr"、"Qty" 这类东西，看起来省了地方，实际上让界面变得像内部工具。——而"像内部工具"这个印象一旦形成，后面做什么都补不回来。

所以需求里应该加一句总纲："英文翻译请优先选择短词；任何位置的文字换行不超过两行；底部标签、按钮、列表右侧不允许出现截断或被挤出屏幕；如果某个位置放不下，先把文字改短，不要缩小字号。"——最后半句是重点：缩小字号是最容易想到、也是最坏的一个解法，因为它把"语言问题"变成了"可读性问题"。

七、第六个问题：日期、数字、单位

这一类问题是"翻对了但还是不对"的典型。字全都换成英文了，可日期还是 2026年10月28日，金额还是 1,000元，时间还是 14:30。

先说日期。中文习惯是"年月日"从大到小；美式英文是"月日年"；英式英文是"日月年"。而纯数字的 10/28/2026 和 28/10/2026，在对方眼里可能是两个完全不同的日子。——这是个会造成真实误解的地方，不是审美问题。最稳的写法是"月份用英文缩写"：Oct 28, 2026，因为月份写成字母就不会有歧义。

再说数字。千分位分隔符在英文里是逗号（1,000），小数点是句点（1.5）。而有些地区正好相反：千分位是句点，小数点是逗号（1.000,5）。——如果你的目标用户是欧洲某些地区，这一点必须确认，否则"1.000"会被读成"一"。金额上出这种错，后果不小。

还有时间。中文界面里 14:30 很自然；英文界面里，很多人第一眼会读成"两点半"（如果那个地区习惯 12 小时制）。要改成 2:30 PM，或者干脆保留 24 小时制但在旁边标清。——这条不是硬规则，但它决定了"用户会不会看错时间"。

这一类的需求怎么写？不要写"改成英文格式"（太模糊），要写具体的例子："日期统一成 Oct 28, 2026 这种写法（月份用英文缩写，不用纯数字）；数字千分位用逗号、小数点用句点；时间用 12 小时制并带 AM/PM；金额符号放在数字前面。以上格式在列表、详情、弹窗里都要一致。"——给出一个具体样例，比给十句原则有用。因为"格式"这件事，样例就是标准。

八、两个我们自己改过的包

说两个我们自己的应用。都是自己开发的，改起来没有授权上的顾虑，也正好一个偏"对外演示"、一个偏"实际使用"。

例子一：设备巡检应用，改成英文给海外客户看

以前的改法：这个应用是我们自己写的，但当时的第一反应仍然是"改包"——因为源码分支在别人手里，重编要排期。于是走了最原始的路：反编译，翻 strings.xml，改；再翻布局文件，把 android:text 里的中文一个个改；打包、签名、装上，切英文看。

结果是三轮。第一轮翻完资源，界面上还剩一大堆中文——因为那些是写在代码里的 Toast。第二轮补了 Toast，结果底部标签栏被英文撑坏了，"我的"变成 "My Profile" 之后直接把第五个标签挤出屏幕。第三轮改短（My Account 改成 Me）、把标签栏宽度改自适应，才算能看。三轮加起来差不多一天半，而这还只是一个中等规模的应用。

现在的做法：一个包导进去，写清四件事——"把这个应用改成英文界面。第一，布局文件和字符串资源里所有中文改成英文，常用词按这份词表统一（确定 OK、取消 Cancel、保存 Save、删除 Delete、返回 Back、下一步 Next、完成 Done、设置 Settings、我的 Me、退出 Sign out、重试 Retry、加载中 Loading）。第二，代码里直接输出的中文（Toast、对话框、错误提示）也全部改成英文，拼起来的句子按英文语序重写，不要逐词替换。第三，启动页那张带中文字的图我另外给一张新的，直接用新的替换。第四，默认资源直接改成英文，不要新增语言目录，不要改包名、不要动任何配置键名。"

出来之后，三轮变成一轮半。剩下的半轮是"长度微调"——这种事没法完全避免，因为英文长度和界面宽度是天然冲突的，总有几个位置要人工看一眼再改短。但"找漏掉的中文"这一轮，基本没有了。

改完怎么验：三个动作。第一，把手机系统语言切成英文（这一步不能省，因为有些中文是"系统给的"——比如权限弹窗、分享面板，那些不是应用里的字，切了才知道哪些是应用的问题）；第二，每个页面走一遍，看到中文就截图记下来，记的时候写清"哪个页面、什么操作触发的"；第三，把包解出来搜一遍中文，看还有没有残留——这一步专治"只在出错时才出现"的那类文字。

例子二：扫码点单小工具，给一家接待外宾的店做英文版

以前的改法：这个更麻烦，因为它的界面几乎全是"动态生成"的——菜单项、分类名、加料选项，都是从后台配置里读出来的。也就是说，那些文字根本不在应用里，而在服务端返回的数据里。

我们第一次改的时候完全没意识到这一点，翻了一整轮，装上去发现菜单名字还是中文。——而这一处改不了：它不是"应用里的文字"，是"数据里的文字"。

现在的做法：把范围说清，把不能改的部分单独处理。需求这样写——"把应用界面上所有'固定显示'的中文改成英文：按钮、标题、提示语、空状态文案、错误提示。店里菜单、分类、加料这些从后台读出来的内容不在本次范围内，不要动。如果界面上有'暂无数据'之类的占位文案，也要改成英文。"

然后菜单那部分，走另一条路：在后台把商品名加一份英文，让应用按语言取。——这件事跟改包没关系，但如果不提前说清，改包的人会以为"我应该让它翻"，结果要么翻不了、要么把接口参数翻了导致功能坏掉。

改完怎么验：这个例子的验收有个特殊性——必须在"真实的下单流程"里验，而不是只看页面。因为动态内容多，光看首页是看不出问题的。我们的做法是：扫一次码、点两样东西、加一个料、下一单（用最小金额，不真的支付）、看订单确认页。——走完这一遍，才发现"加料选项"那一屏有个"选好了"的按钮还是中文。那个按钮是固定文案，但它在第三步才出现，走不到那儿就看不见。

这两个例子的差别，其实比它们看起来的更大。第一个是"演示型"——对方会拿在手里翻一遍，看得清每一页，所以验收的单位是"页面"；第二个是"使用型"——对方会真的点下去、真的下单，所以验收的单位是"步骤"。页面级的漏点，翻一遍就找得出来；步骤级的漏点，非得把那一步走完才看得见。

而这两类漏点加起来，正好就是前面那六步清单要挡的东西。——所以我一直觉得，"改完怎么验"这件事不该在改完之后才想，它应该和需求一起写。因为你怎么验，决定了你怎么说；你怎么说，决定了它改成什么样。这句话反过来也成立：如果你发现自己说不清"改完怎么验"，那多半不是验收方法的问题，而是你还没想清要它变成什么样。——先想清楚验收，再写需求；顺序一旦反了，多花的往往不是一轮，而是整整两轮。

九、一份六步验收清单

前面两个例子里的验收动作，合成一份能照着走的清单。六步，大概二十分钟；跳过任何一步，都会在"交出去之后"才知道。

第一步：把系统语言切成英文。这一步听起来理所当然，但确实有人跳过——因为"反正应用里全是英文了"。可正是这一步能区分"应用里的字"和"系统给的字"。切完之后你会发现有些中文其实是系统的（权限弹窗、分享面板、输入法提示），那些不是你该改的，但你必须知道它们存在，否则你会一直以为是自己漏了。

第二步：走主路径，而且要走"出错路径"。主路径是"打开 → 登录 → 用主要功能 → 退出"。出错路径是三种：断网、列表为空、输入不合法。——这三种状态下出现的文字，恰恰是前面说的"写在代码里的中文"最集中的地方，也是正常测试最容易漏的地方。

第三步：把包解开，搜一遍中文。做法是在解出来的目录里搜中文（可以直接用中文字符范围去匹配），然后逐条看：这条是给人看的，还是给机器看的？给人看的没改，就是漏；给机器看的不该改，就别动它。——这一步是唯一能查到"隐藏页面"和"错误分支"的办法，因为没有哪个人能靠点界面把应用的所有分支都点一遍。

第四步：看四个容易撑坏的位置。按顺序看：底部标签栏、所有按钮、列表项右侧、确认框。——这四个位置占了"英文变长"问题的一大半。看的时候不要横着看，要竖着看：把手机竖起来，看有没有文字被切成两行、有没有元素被挤出屏幕右边。

第五步：看格式。找一个带日期的列表、一个带金额的页面、一个带时间的记录，看这三样是不是都改成了英文习惯的写法。——这一步最容易"看一眼觉得没问题"，因为它不像中文那么刺眼。所以要具体看：日期里有没有"年/月/日"这三个字、金额后面有没有"元"、时间是不是 24 小时制。

第六步：装到那台最旧的手机上再看一遍。理由和上一节说的一样：屏幕小、系统版本低，界面表现不一样。而英文比中文长这件事，在小屏上会被放大——大屏上勉强一行的东西，小屏上一定要换行。

十、五个具体的问答

问：我想保留中文，让用户能自己切语言，可以吗？

答：可以，但要多做一步。做法是"保留默认那套中文 + 新增一套英文"，然后在应用的设置里加一个语言切换（或者在系统设置里让用户按应用设置语言）。——代价是"能不能切成功"取决于应用的资源选择逻辑是否正常，所以验的时候必须真的切一次，而不是"应该能切"。如果只是想"对外发一版"，直接改默认语言更稳。

问：桌面上的应用名和图标要不要一起改？

答：应用名通常要改——因为它就显示在桌面上，中文名会立刻暴露"这是个中文应用"。但改之前想清楚两件事：一是名字要短（桌面图标下面放不下长名字，会被截成省略号）；二是图标里如果有中文字，就得重做图，那是前面说的"图片里的字"。

问：英文是自己写好，还是让它翻？

答：关键位置自己写，其余交给它。关键位置是：应用名、首页标题、主要按钮、付费和删除相关的确认文案。这几处一旦措辞不对，用户会直接不信任这个应用。其余大量重复的提示语，让它统一翻就好——但一定要给词表，否则同一个词会出现好几种写法。

问：改完之后，系统语言切回中文会怎样？

答：如果你选的是"直接改默认资源"，那它显示的仍然是英文——因为它已经没有中文那一套了。这通常正是你想要的（"这是一个英文版"）。但如果你希望"中文系统下显示中文"，那就必须走"双资源"那条路。——这两条路不能事后兼容，选之前就要定下来。

问：那阿拉伯语、希伯来语这种从右往左的语言呢？

答：这类语言不只是"换文字"，还要"换方向"。整个界面的布局要镜像：返回箭头指向右边、进度条从右往左走、图文排列顺序反过来。翻译解决不了这个，它需要单独做一次布局镜像，而且要在真机上验。——所以如果你的目标市场里有这类语言，最好把它当成"另一个项目"，而不是"同一个项目的另一套翻译"。——这条不是吓人，是因为只翻文字不做镜像的结果，比不做还糟：文字从右往左读写，布局还是从左往右排，读起来会错位。

十一、有六处中文，翻之前就该决定"留着"

前面一直在讲"怎么翻干净"。这一节反过来：有六类中文，翻了反而错。

第一类：用户自己输入的内容。昵称、备注、地址、工单描述——这些是数据，不是界面文字。翻它等于改用户的资料。而这一类"该不该翻"的判断标准很清楚：如果这句中文是"某个人写下来的"，就别动；如果这句中文是"程序要说给所有人听的"，才翻。

第二类：第三方品牌和支付渠道名。"微信支付"、"支付宝"、"银联"这些，各有自己的官方英文写法（WeChat Pay、Alipay、UnionPay）。自己硬翻成 "Weixin Pay" 或者 "Alipay Wallet" 都不对——品牌名的翻译权不在我们手里，用错了比留着中文更不专业。

第三类：法务文本。隐私政策、用户协议、许可证声明、备案信息。这些不能机翻——因为它们的每一句话都有法律含义，翻错一句可能带来真实的责任。正确做法是保留原文位置，把入口改成指向一份正式的英文版文档，而不是让工具把三千字协议翻一遍。——这条边界值得说重一点：改包能让界面"看起来像英文产品"，但它不能让一份中文协议变成一份有效的英文协议。

第四类：客服联系方式。电话、微信号、邮箱地址、工作时间。号码不能翻；"工作日 9:00-18:00"这类说明翻了有用，但要顺带说清时区——不然对方会在自己那边的凌晨打电话，然后觉得"这家没人管"。

第五类：中国特有的业务概念。发票、实名认证、社保、公积金、增值税专票——这些词在英文里没有一一对应的说法。直译（"real-name authentication"）技术上没错，但对方不知道要准备什么。这类地方的处理是"翻译 + 一句解释"，而不是"找一个最像的词换上去"。——而这件事只能人来判断，因为它需要的不是语言能力，是业务理解。

第六类：品牌 logo 里的字。这个前面提过——如果那些字是品牌标识的一部分，它就是"名字"，不是"文案"。名字当然可以不翻，但你要接受一件事：英文界面上出现一行中文字，看起来会像一个"没做完的地方"，除非它明显是 logo。——所以要么把 logo 做得明显是 logo（图形 + 字一体化），要么干脆换成英文标识。中间状态最尴尬。

把六类合起来看，会发现一个共同点：它们都不是"文字"，而是"别人的东西"——别人的数据、别人的品牌、别人的法律文本、别人的业务概念。而改包能改的，是"你自己的界面"。——这条边界清不清，决定了一次外翻是"交付"还是"埋雷"。

十二、做过这件事的人怎么说

十三、语言这件事，最后落在"一致"两个字上

把前面所有内容收一下，其实就是在讲一件事：一个界面像不像"给英文用户做的"，不取决于翻译得准不准，而取决于它是否一致。

不一致有六种表现，每一种单独看都很小：同一个"确定"在一处是 OK、另一处是 Confirm；一句英文里夹着一个全角逗号；日期在列表里是 10/28，在详情里是 2026年10月28日；按钮文字是一行，旁边那个是两行；一半界面说 "Settings"，另一半说 "Set up"；某个弹窗里的字还是中文。——单独看每一条都"不算错"，但它们叠在一起，读者会得到一个整体印象：这个东西不是为我做的。

而这个印象一旦形成，后面再改十处也补不回来。——所以"一次性把词表和格式定下来"这件事，看起来是流程上的讲究，实际上是在保护最终那个印象。

这也是为什么我在前面反复强调"给样例、给词表、给范围"。不是因为写需求要正式，而是因为这三样东西是"一致性"唯一可执行的保障：词表管用词，样例管格式，范围管"哪些不该动"。三样都给，一轮就差不多；哪样不给，那一处就会在验收时回来找你。

最后说一句关于"反过来做"的感想。做汉化的时候，我们习惯了当"读者"——看不懂原文，所以格外小心。反过来做的时候，我们成了"作者"，而作者最大的盲区是：我看得懂，所以我以为别人也看得懂。——那些漏掉的中文，全都是在这个盲区里活下来的。

只需说话，就能让应用变成你想要的样子。而在这件事上，"说话"的价值在于：你只需要说清"这个界面上所有给人看的字都要换成英文，一个都别剩"，剩下的找、翻、替换、重打包，都不必你动手。——但"一个都别剩"这四个字背后的那六步验收，还是得你自己走一遍。因为只有你知道，那句话该是什么语气。

安卓修改大师智改工坊的产品页在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。它接手的是反编译、搜字符串、替换、打包、签名这些机械环节，而"该翻成什么"这件事，它只能照你说的做——所以词表和样例，值得你多花十分钟。

---