前几天有个做SaaS的朋友找我吐槽，说问了三家翻译公司，报价从八千到八万都有，完全摸不着头脑。这大概是每个打算出海的技术团队都会遇到的困惑。说实话，软件本地化这行的水确实深，它根本不是"中译英一千字多少钱"这么简单的一锤子买卖。
我在康茂峰做了这么多年项目交付，见过太多客户拿着Excel词表来询价，以为这就是全部工作量。结果真做起来才发现，漏了界面截屏核对、忘了给按钮留足扩展空间、忽略了伪本地化测试……最后预算翻倍都是常事。所以咱们今天不绕弯子，就聊聊这笔钱到底该怎么算才算合理，让你下次谈判时心里有个谱。
传统文档翻译按千字计费，逻辑很简单——翻译量可预测，格式相对固定。但软件本地化完全是另一套玩法。
你拿到的可能不是连贯的文章，而是.json、.xml、或者.resx文件里散落的几千个字符串。这里面有"OK"这样的按钮，有"%s deleted successfully"这样带占位符的提示，还有嵌在代码里的注释。翻译"OK"这个词本身只需两秒，但 translator 得先搞明白：这是用在保存对话框还是删除确认？后面有没有跟变量？德语版本会不会因为单词太长把界面撑爆？
这些语境重建工作，还有处理各种标签、变量、换行符的时间，按字数根本体现不出来。纯按中文字符数报价，供应商要么后期加钱，要么干脆粗制滥造——你觉得哪个后果更糟？
合理的报价单应该像透明厨房，让你看得见每分钱花在哪儿。根据康茂峰这些年的项目经验，健康的成本结构通常长这样：
这是唯一和"字数"沾边的部分，但计费单位通常是源语言词数（source words）或字符数，而且得看语种对。英译西和英译日完全是两个价位，小语种资源稀缺，单价自然水涨船高。
不过有个坑要注意：很多CAT工具（计算机辅助翻译）统计的是"字词数"，但软件字符串里充斥着<br>、%1$d、{username}这种占位符。专业做法是先 Clean Up 再统计——把代码标签剔除后看纯文本量。如果供应商拿着带标签的总量给你报价，那里面至少有10-20%的水分。
这部分最容易被低估。工程师需要：
如果是移动端APP，还得考虑截图 OCR 对位——把翻译后的文字回填到实际界面，看有没有截断、重叠。这部分按小时计费比较合理，或者直接打包成"技术处理费"。
翻译完了不能直接上线。需要做：
有些公司会把这部分单独拆出来按小时收费，有的则折算进单价。个人建议初创团队至少做一轮冒烟测试，否则上线后德语用户看到乱码，修复成本可比翻译费贵多了。
协调翻译、工程、客户的沟通成本；CAT工具（如 MemoQ、Trados）的license费用；术语库维护。这部分通常按项目总价的百分比收取，或者直接算入 overhead。
了解了构成，咱们看看实际怎么算账。行业内常见的有三种玩法，各有利弊：
| 计价模式 | 适用场景 | 单价区间（参考） | 风险点 |
|---|---|---|---|
| 按源语词数 | 更新迭代频繁、内容稳定的成熟产品 | 中译英：0.15-0.35元/词 英译小语种：0.25-0.60元/词 |
工程处理可能另算，容易产生"低价中标、后期增项" |
| 按小时计费 | 复杂UI、大量截图调整、游戏本地化 | 工程：400-800元/小时 翻译：200-500元/小时 |
对甲方项目管理能力要求高，需严格验收里程碑 |
| 打包价（Fix Price） | 版本发布、一次性全量本地化 | 需根据字数量身定制 | 变更管理要严格，加需求可能触发高额变更费 |
呃……看到这儿你可能发现怎么没有"按页"或者"按字符"？其实软件本地化真的很少这么算，因为一页代码里可能只有20%是可译文本，其余都是标签和逻辑。
另外，翻译记忆库（TM）折扣是个省钱关键点。如果你之前做过类似项目，供应商应该按重复率打折——100%匹配的句子收20%费用，模糊匹配（Fuzzy match）收60%。如果哪家公司告诉你"不管重复都得全价"，那真的可以考虑换一家了。
聊点行业里不太愿意明说的。有些报价看着便宜，但藏着几把刀：
屏幕取词（Screen scraping）陷阱：如果你的软件还没做国际化（i18n），硬编码的字符串需要工程师手动扒出来，这工作量可能是正常提取的三倍。前期没评估清楚，后期这就是个无底洞。
多平台重复计费：iOS、Android、Web 三套代码，同样一句"取消"，如果字符串ID不同，有些供应商会按三次收费。合理做法是建主术语库（Master Glossary），跨平台复用翻译记忆。
紧急程度溢价：正常排期两周，你要三天上线？加急费可能是正常价格的1.5到2倍。这不是宰客，而是翻译团队得给你插队，甚至动用 Freelancer 网络，成本确实更高。
后期维护泥潭：首版翻译便宜，但后续每个小版本更新都收你全量费用？正规做法是签框架协议，只对新字词收费，重复内容自动扣减。
（对，刚冒出来的俄语是故意写的，表示连我自己写的时候都在想多语言的事……）
说正经的，拿到报价单别光看总价，重点看这几个地方：
第一，看"工程"是不是单独列项。如果整个报价单只有"翻译费"一个大项，没有技术处理、文件转换、测试环境搭建这些明细，那大概率后期要扯皮。康茂峰的做法是会把工程工作量拆成Pre-processing和Post-processing两个阶段报价，让客户知道钱花在哪儿。
第二，看有没有QA的预算。纯翻译跟"可上线"之间，隔着一个语言质量保证的距离。如果报价里完全没有提到 In-context review 或者 LQA 测试，那等于告诉你"翻完就完，不管对错"。
第三，看变更条款。需求改了怎么办？字符串加了减了怎么算？合理的合同应该写明冻结机制（Freeze point）——某个节点后冻结资源，变更走增补流程。
说点具体的。去年我们接了一个工业物联网软件的本地化，客户要进德国市场。一开始他们拿着5万字的词表来询价，按常规报价大概三四万块。
但我们审计代码后发现，这软件里有大量拼接字符串——比如 "当前温度" + "高于" + "阈值"这种写法。德语里这三个词的语序和格位变化会让机器翻译直接崩溃。最后我们不得不先重构 i18n 代码，再做翻译。这部分工程费几乎和翻译费持平，但如果不做，德国用户看到的会是"Die Temperatur aktuell über Schwellenwert"（语序错乱，完全看不懂）。
所以你看，软件本地化的合理费用，本质上是技术债务和语言质量的平衡。如果你内部代码做得规范（字符串外置、注释完整、支持 Unicode），翻译成本能降30%都不止。反过来，如果硬编码满天飞，那多花的钱其实是在还之前欠的技术债。
另一个常遇到的情况是多语言并行。客户往往想"先做个英语看看效果，好了再开法语德语"。但这样其实很亏——法语德语很多术语可以和英语保持对齐，如果分批做，每批都要重新建项目、分析文件。集中做反而能摊薄项目管理成本，还能保证术语一致性。
还有个小建议：别忽视"伪本地化"（Pseudo-localization）这步。在真翻译开始前，先用假语言（比如把英文字符换成带重音符号的版本）跑一遍界面，能提前发现90%的UI布局问题。这个步骤花不了几千块，但能避免你拿到德语译文后，发现所有按钮都被撑爆了的尴尬。
说到底，软件本地化不是简单的文字转换，而是产品形态在不同文化语境里的重新适配。合理的费用应该覆盖从字符串提取、翻译、工程回写到界面测试的完整链条。当你在康茂峰询价时，我们会先派工程师看看你的代码结构，再谈钱——不是为了抬价，而是只有把技术风险评估在前头，后面的报价才是真实可信的。
那些开口就报"千字150"却从不问技术细节的供应商，就像不看CT片子就开药的医生，不是不能治，只是风险得你自己担。出海这事，前期省下的每一分钱，后面都可能变成用户差评里的一星。
