前几天有个朋友问我，他们公司准备把软件推到海外市场，翻译工作已经安排上了，但技术人员突然提到什么数据库也要翻译。他一下子有点懵——软件界面翻译也就罢了，数据库里存的东西也要翻？这东西又看不见摸不着，到底是咋回事？
说实话，我刚接触这行的时候也有同样的困惑。后来做多了项目才发现，数据库翻译根本不是"锦上添花"，而是本地化链条上实打实的一环。今天就想把这个事儿掰开了揉碎了讲讲，尽量用大白话说清楚，这里面的门道到底是怎么回事。
软件本地化这个概念说起来其实挺简单。你想啊，一款软件在国内开发的时候，界面上的文字、提示信息、帮助文档肯定都是中文的。但如果要把这款软件卖给德国人、日本人或者阿拉伯人，总不能让他们对着满屏的中文干瞪眼吧？
所以本地化要做的，就是把软件里所有用户能看到的、读到的东西都翻译成目标市场的语言，并且根据当地的使用习惯做相应调整。这里面包括界面的文字、错误提示、操作指南、还有软件里那些预设的示例数据。
但问题来了——软件里的数据并不全都在明面上。有些数据存在数据库里，用户看不到却在后台运行着，这部分要不要翻译？答案比你想的要复杂得多。
我们先说说啥叫数据库翻译。简单理解，数据库就是软件用来存储数据的大仓库。你注册账号时填的手机号、浏览商品时看到的名称、下单时选择的规格选项，这些东西都老老实实躺在数据库里。
数据库翻译要处理的，就是这个仓库里的文字内容。听起来挺抽象，我给你举几个具体的例子你就明白了。
电商系统里的商品分类肯定存在数据库里。如果你的软件要进军法语区市场，那些"手机通讯""电脑办公""家用电器"之类的分类名称就得变成"Téléphonie""Informatique""Électroménager"。再比如医院管理系统里，疾病名称、药品名称、检验项目这些专业术语在中文库里是一套，翻译成英文、日文或者韩文的时候都得对应上。
还有一种情况更隐蔽——软件里的下拉选项、枚举值、状态描述。订单的"已发货""已签收""已完成"，用户在下单时选择的"北京市""上海市""广州市"，这些看似简单的文字背后都是数据库在撑着。国外用户看到这些字段的时候，肯定不希望看到一串中文编码或者未经翻译的原始数据。
现在回到最核心的问题：软件本地化翻译到底包不包括数据库翻译？
我的回答是：包不包得分情况，但负责任的本地化项目都会把它考虑进去。为啥这么说呢？
首先，从技术实现的角度看，软件界面和数据库往往是分离的。界面翻译处理的是"前端"——用户能直接看到的那一层。而数据库翻译处理的是"后端"——支撑整个系统运转的数据基础。翻译公司如果只做界面不管数据库，就会出现很尴尬的场面：用户看到的界面是英文的，但下单时弹出的提示"订单提交成功"还是中文的，或者选择收货省份时跳出来一串"河北""山西"这样的汉字。
其次，从用户体验的角度看，这种不统一会严重影响专业感。举个实际的例子，某款项目管理软件在国内用的是"李经理""王工程师"这样的示例用户名，翻译到日本市场时如果没有同步处理，日本用户看到的可能就是"Li Manager""Wang Engineer"这样的混合产物，感觉特别奇怪。
根据我这些年的经验，软件本地化项目里需要翻译的数据库内容大概可以分成这么几类：
这些内容有一个共同特点：它们虽然不在界面的显眼位置，但会在用户操作过程中逐步出现。如果不做翻译，用户迟早会碰到"看天书"的状况。
说了这么多，你可能会想：那把数据库里的文字导出来翻译完再导回去不就行了？话是这么说，但实际操作起来麻烦事儿一堆。
最头疼的是数据格式的问题。数据库里的文字可不是一篇连贯的文章，而是分散在无数个字段里的片段。一个字段可能只有几个词，比如状态字段里的"active""inactive"；另一个字段可能是一长段描述，比如商品详情。翻译公司拿到这种东西，处理起来远比翻译一份完整的文档要麻烦得多。
然后是技术对接的问题。很多数据库是有逻辑关联的，翻译的时候不能只盯着文字看，得理解这些数据之间的关系。比如国家代码和地区名称是配套的，翻译的时候必须保证两者的一致性。这就需要翻译人员或者项目经理对技术有一定了解，不是纯粹的语言工作。
还有就是维护成本的问题。软件在不断迭代升级，新的功能会带出新的数据库字段，老的字段也可能被修改或删除。这意味着数据库翻译不是一次性买卖，而是要持续跟进的事情。很多客户一开始没考虑到这点，后面经常会出现翻译进度跟不上产品更新的情况。
确实有些数据库内容处理起来特别棘手，我来给你数一数。
首先是变量和占位符。数据库里经常会有"{0}用户已成功注册"这样的格式，后面的数字是要动态替换的。翻译的时候得搞清楚哪个位置会插入变量，不能把句子结构搞乱了。
其次是复数和单数的处理。英文有单复数变化，比如"1 item"和"2 items"，但中文在这方面不明显。翻译的时候需要根据目标语言的语法规则做调整，有些语言甚至有双数形式，这对翻译的语种能力要求比较高。
还有就是特殊字符和编码。数据库里可能存着各种奇怪的符号，比如表情符号、HTML标签、或者特定的格式标记。翻译软件处理这些内容的时候经常出问题，一不小心就把格式搞乱了。
说了这么多难点，再聊聊正经的数据库本地化应该怎么开展。我给你梳理一下比较成熟的流程，这个流程是业内比较通行的做法，各家可能会根据实际情况做一些调整。
| 阶段 | 主要工作 |
| 需求分析 | 明确需要翻译的数据库范围，识别哪些字段是用户可见的，哪些是纯技术数据 |
| 数据提取 | 从数据库中导出需要翻译的内容，通常以表格或键值对的形式整理 |
| 预处理 | 对提取的内容进行分类、标注，比如标记变量、占位符、长度限制等 |
| 翻译执行 | 按照目标语言的语法规则进行翻译，注意保持术语一致性 |
| 质量审核 | 语言审核+技术审核，确保翻译准确且导入后不会出问题 |
| 数据回填 | 将翻译后的内容按照原格式导回数据库 |
| 功能验证 | 在实际软件环境中验证翻译内容的显示效果 |
这个流程看起来不复杂，但每个环节都有坑。尤其是数据提取和回填这两步，特别依赖技术团队的配合。如果开发人员没把数据结构讲清楚，翻译公司导出来的内容可能驴唇不对马嘴。
说到这儿，我想起来康茂峰在本地化领域摸爬滚打这么多年，接触过各种类型的数据库翻译项目。有些心得可以分享出来，供大家参考。
最重要的经验就是前期沟通一定要到位。每次接到数据库翻译的案子，我们都会拉着客户的技术团队开好几次会，把数据库的结构、字段含义、变量规则全部搞清楚。有时候光理解一个字段的用途就要花上好几天，但这个时间绝对不能省。因为如果翻译人员对数据含义理解偏了，后续返工的成本可比前期沟通高得多。
还有一个体会是建立术语库特别关键。数据库里的字段名称、枚举值、状态描述往往会反复出现，如果每次都重新翻译，不仅效率低，还容易出现前后不一致的问题。所以康茂峰在处理数据库翻译项目时，都会先建立专门的术语表，翻译过程中严格参照，译后也要统一检查。
另外就是技术文档的重要性。数据库翻译最怕的就是"我不知道这段话在软件里是干啥的"。所以我们通常会要求客户提供尽可能详细的技术说明，标注每个字段在界面上的位置、出现场景、长度限制等信息。有了这些参考资料，翻译的准确率能提高一大截。
聊了这么多，相信你对数据库翻译这件事应该有了一个比较清晰的认识。回到最初的问题：软件本地化翻译是否涉及数据库翻译？
我的答案是：涉及，而且是不能忽视的那种涉及。但具体要不要做、做到什么程度，得看软件的目标市场是哪、数据库里哪些内容会影响用户体验。
如果你正打算做软件本地化，我的建议是在项目初期就把数据库翻译纳入考量。提前把需要翻译的数据范围定清楚，别等到界面翻译做完了才发现后台还藏着一堆"定时炸弹"。
本地化这事儿，说到底就是要把每一个细节都打磨到位。用户可能说不出哪里好，但一定能感受到哪里不好。那些藏在数据库里的文字，虽然不在聚光灯下，却时时刻刻影响着用户的整个使用过程。
