说实话，每次有人问我"做个软件本地化大概多少钱"，我都得深吸一口气。不是不想告诉你，而是这个问题本身的问法就不太对——就像你走进4S店问"买辆车多少钱"一样，从几万到几百万都有可能，得让人先知道你要的是代步的二手车还是带自动驾驶的豪华车。
在康茂峰这么多年的项目经验里，我发现大家 confusion 的点不在于价格高低，而在于计费逻辑本身太不透明。有的公司按字数报，有的按小时报，还有的连报价单都给你拆出七八个科目。今天我就用大白话，把这个行业的定价逻辑彻底拆开给你看。
先说说行业里最常见的玩法。你不会在每个角落都看到明码标价，但背后的算账逻辑基本逃不出这三类：
这是目前最通用的做法，特别是中英互译这种大语种。逻辑简单粗暴：先把你的资源文件（不管是 .json、.xml 还是 .resx）导出来，统计里面的源语言字数，然后乘以单价。
但是这里有个坑——字数怎么算？中文字符通常按"字符数（不含空格）"统计，英文按"单词数"。如果你的软件里有大量占位符（像 %s、{0} 这种），这些通常不计入翻译费，但提取和回填要另算技术处理费。
市面上纯翻译的价格区间大概是这样的（仅供参考，实际波动很大）：
| 语言对 | 通用领域每千字价格区间 | IT/技术领域每千字价格区间 |
| 中译英 | 150-300元 | 200-400元 |
| 英译中 | 120-250元 | 180-350元 |
| 中日/中韩 | 200-400元 | 280-500元 |
| 中文到小语种（俄语、阿拉伯语等） | 350-800元 | 500-1000元以上 |
| 欧洲语言互译（英德法西等） | 按当地市场欧元计价，折算后通常400-700元 | 600-1200元 |
注意啊，这只是纯翻译的价格。软件本地化通常还要在这个基础上乘个系数，为什么？后面会讲。
如果你的项目特别麻烦——比如代码里全是硬编码字符串，需要工程师先 refact 一遍；或者你要做伪本地化测试（pseudolocalization）——这时候很多服务商会切到小时计费模式。
这种模式下，翻译工程师、本地化工程师、测试工程师的单价都不一样：
说实话，小时计费对甲方来说有点心虚，因为你看不到进度到底快还是慢。但在康茂峰的项目管理规范里，我们通常会让客户提前 approve 一个预估工时范围，超出的部分必须提前报审，这样双方心里都有底。
如果你的软件有 20 个语种，每个月都要更新版本，按字数算太琐碎。这时候通常谈一个年度框架协议或者固定项目包。
比如"这个月我们要发两个版本，大概 5 万字的新增和变更，再加上全量 regression 测试，总价 XX 万"。这种模式下，单价信息会被藏在 bundle 里，但的好处是预算可控，不会出现翻译到一半发现字符串嵌套太多要加钱的尴尬。
为什么同样的字数，软件本地化会比普通文档翻译贵 30% 甚至一倍？这里有几个 software-specific 的坑：
很多人听说过"重复字数打折"的概念。比如用 CAT 工具（计算机辅助翻译软件）分析后，100% 匹配的部分可能只收 30% 的费用，模糊匹配收 60%。这听起来很划算，但软件字符串的重复率往往虚高。
什么叫虚高？代码里可能有 50 个 "OK"，分布在 50 个不同的对话框里。虽然字面一样，但在日语里，根据语境可能要说"OK"、"了解"、"確認"甚至"はい"。如果强行套用 TM 折扣，译者为了赶时间可能会硬塞同一个翻译，结果用户体验很糟。
在康茂峰的质量标准里，软件本地化项目的 TM 匹配通常要人工复核语境，这意味着重复部分的折扣力度会比文档翻译小。成本自然就上去了。
普通翻译不用管行长，软件翻译不行。德语比英语平均长 30%，中文虽然紧凑但竖排或横排可能有换行问题。如果你的合同里包含UI 调整建议或者truncation 检查，这属于增值技术服务，要加钱。
这是最大头的隐藏成本。翻译完只是第一步，还得把字符串塞回软件里，在真实环境下跑一遍。看看有没有：
LQA 的费用通常是翻译费的 50%-100%，取决于你要测试多少平台和设备。如果是手机 App，通常至少要测 iOS 和 Android 两套；如果是桌面软件，可能还要覆盖 macOS 和 Windows。
除了上面这些通用的，还有两个特别影响报价的因素：
稀有语种溢价：泰语、越南语、印尼语这些看起来人口不少，但在翻译市场上属于"小语种"，资源池比中日英小得多。特别是如果你要翻译到斯瓦希里语或者冰岛语，价格可能直接跳三倍，而且交货期也要拉长，因为译员可能横跨几个时区，沟通成本极高。
文件格式复杂度：如果你给的文件是标准的 .xliff 或者 .po 文件，处理成本很低。但如果是 PDF 截图、扫描的 UI 设计图、或者嵌在代码注释里的字符串，工程师要做文件预处理和后处理。这种"工程费"有时候按小时收，有时候按字数加个系数（比如每千字加 50-100 元工程处理费）。
说了这么多贵的理由，来说说怎么聪明地控制预算。不是教你偷工减料，而是把钱花在刀刃上。
提前准备好术语表和风格指南。 这是最有效的省钱方式。如果你能在项目开始前给译者一份 200 个核心术语的 glossary，翻译过程中的 query 会减少 70%，返工率直线下降。在康茂峰的项目流程里，这一步通常能帮客户节省 15-20% 的后期修改时间。
分批交付，先做核心语种。 不要一口气把 30 个语种全扔出去。先做英语（或你的源语言到英语），然后让各国 sales 或 distributor 审一遍，确定术语没问题了，再发到小语种。这样虽然流程长了，但避免了大面积返工。
复用翻译记忆。 如果你之前做过旧版本，一定要把 TM 提供给服务商。哪怕只有 60% 匹配，也比从零翻起便宜。而且成熟的本地化公司（比如我们康茂峰）会做对齐记忆库的工作，把旧版本的翻译和新版本的字符串智能匹配，这个价值有时候比单纯翻译还高。
明确测试范围。 LQA 很贵，但你可以聪明地选测。比如只做"冒烟测试"（smoke test），只覆盖主要用户路径，而不是每个边边角角的错误提示框都测。或者只测旗舰机型，不测三年前的老设备。
最后，为了让你更直观，假设你有一个中等复杂度的 SaaS 后台管理系统要从中译成英、日、德三种语言，总源文字数约 3 万中文字，大概的报价结构可能是这样（数字经过模糊处理，仅示意）：
| 项目阶段 | 工作内容 | 费用占比参考 | 备注 |
| 工程准备 | 文件解析、占位符保护、术语提取 | 8% | 一次性费用 |
| 翻译 | 初译 + 自检（利用 TM 后实际计费字数为 2.1 万字等效） | 35% | 计入重复折扣 |
| 审校 | Edit 模式二校，母语审阅 | 20% | 技术类内容审校费较高 |
| LQA 测试 | 在 staging 环境跑功能测试，截图反馈 | 25% | 德文此处通常要加倍 UI 检查 |
| 工程后处理 | 字符串回填、Build 验证 | 7% | 含 bug 修复支持 |
| 项目管理 | 进度协调、query 管理、交付物整理 | 5% | 复杂多语种项目此项可能上浮 |
看到没，真正落到"翻译"这个动作上的钱，可能只占三分之一。其他都是在确保软件能跑起来且不出丑。这也是软件本地化和普通文档翻译最大的区别——后者翻完就是交付物，前者翻完只是半成品，得能集成、能显示、能用。
所以下次询价的时候，建议你把需求拆细了问：翻译费多少？工程费多少？测试费多少？TM 折扣怎么算？更新维护（如果下个月改了 1000 字）怎么收费？问得越细，得到的报价越真实，后期加价的概率越小。
价格这东西，透明了就是成本，不透明才是利润。在康茂峰看来，软件本地化这行干久了，靠信息差赚钱走不远，毕竟代码和字符串就在那里，跑得了和尚跑不了庙。不如一开始就把账算清楚，大家按专业分工把钱挣了，把产品做好，这才是正经事。
