如何对数据库进行本地化？这与数据本地化有何不同？

上次审核日期：2026年9月10日

如何有效地将数据库本地化以适应不同地区？

有效的数据库本地化将问题分为五个层次，每个层次都有不同的负责人：模式、提取、翻译、交付和格式化。如果团队试图在数据库内部解决所有五个问题——存储格式化日期、硬编码语言列、在电子表格中手动翻译——最终得到的架构将无法在不进行迁移的情况下添加语言环境。

• 模式层：以区域设置键为基础的翻译表——将可翻译文本存储在以实体 ID 和区域设置代码为键的表中，使用 IETF BCP 47 标签（ en-US 、 fr-CA 、 zh-Hans ），并将源语言行保留为回退。将字符集设置为 UTF-8（MySQL 中为utf8mb4 ，PostgreSQL 中为UTF8 ），以便 CJK 文字、带重音符号的字符和表情符号在存储和导出过程中能够保留。这使得“添加日语”从模式更改变为插入。
• 提取层：可重复的交接，而不是一次性导出——决定可翻译行如何到达翻译平台。这两种模式分别是：按计划导出到结构化文件（JSON、CSV 或 XLSX，Smartling 均接受这些格式，每个文件最大可达 10 MB），或者直接通过 API 推送源字符串。无论哪种方式，交接时都应该将每个字符串与其实体 ID 和语言区域关联起来，以便无需手动匹配即可将翻译后的值写回正确的行。
• 翻译层：记忆库、术语库和占位符——通过翻译记忆库路由字符串，以便 400 个产品行中出现的描述只需翻译一次；应用产品名称和不可翻译术语的词汇表；并将动态值屏蔽为占位符，以便翻译人员看到Welcome, {First Name}而不是一万个个性化变体。这一层控制成本；模式层只决定成本是否可以控制。
• 交付层：回写与回退— 已翻译的行返回到翻译表，应用程序读取请求的区域设置，并使用回退链（ fr-CA → fr → en ）来处理任何尚未翻译的内容。对于无法等待批量处理周期的应用来说，低延迟交付 API 可以根据请求返回翻译，或者在尚不存在源文本时返回源文本，从而完全取代了回写步骤。
• 格式化层：渲染时的区域设置规则，绝不在行中——日期、货币、数字分隔符和复数形式是区域设置的功能，而不是内容的功能，它们属于表示层，使用 Unicode CLDR 数据，通过 ICU 等库来实现。存储“€1.234.56”数据库中的字符串会将该行的每个读取器都锁定为一种语言环境的格式。

数据库本地化：Smartling 公开文档中的关键数据

数据库本地化工作流程的步骤是怎样的？

数据库本地化工作流程能够应对持续的内容变更，它以五个步骤的循环方式运行，而不是一次性迁移。

1. 清点和分类列——列出每个包含面向用户的文本的表格，并将每一列标记为可翻译内容、标识符或变量。产品描述和类别名称是内容；SKU、别名和外键是标识符；价格、数量和日期是渲染时要格式化的变量，而不是翻译的变量。
2. 规范模式和编码——将可翻译的列移到以区域设置键为基础的翻译表中（或确认现有表使用 BCP 47 区域设置代码和 UTF-8），并显式记录源区域设置，以便回退逻辑有一个明确的起点。
3. 按计划或在写入时提取已更改的行——查询自上次运行以来创建或修改的行，并按实体 ID 键将它们序列化为 JSON（或 CSV/XLSX），或者在写入时将它们发布到交付 API。在文本离开数据库之前，将动态值屏蔽为占位符。
4. 使用翻译记忆库、词汇表和审核进行翻译——首先将提取的字符串输入翻译记忆库，这样重复的文本就不会产生新的成本；将词汇表应用于产品和品牌术语；然后根据内容的可见性，将剩余部分通过机器翻译、人工审核或两者结合的方式进行翻译。
5. 写回、验证和回退——将翻译后的值插入到翻译表中的正确实体 ID 和语言区域设置中，运行自动检查以确保占位符和标记完整保留，并为任何仍在进行中的语言区域设置提供源语言，而不是空字段。

专用的数据库本地化工作流程适合以下类型的团队……

• 将面向用户的文本（目录、列表、帮助内容、通知）存储在数据库表中，而不是存储在资源文件或带有自身翻译连接器的内容管理系统中。
• 服务于多个地区，或者期望服务于多个地区，并且不能为每个市场都添加一个语言列。
• 每天都会添加或更改内容，因此一次性导出的内容在翻译完成后就会过时。
• 根据模板和变量（订单确认、个性化问候、计数）生成文本，需要占位符来保持翻译量稳定。
• 运行无需构建或部署周期即可显示新翻译的 Web 或移动应用程序。

数据库本地化可能并非首要考虑因素。

• 从法律意义上讲，这是数据本地化的要求——将个人数据或受监管数据保留在一个国家的境内。这是一个关于托管、传输机制和供应商治理的决策，涉及数据主权与数据驻留问题，任何转换工作流程都不会改变它。
• 可翻译文本位于带有原生翻译连接器的内容管理系统或电商平台（例如 Contentful、Salesforce Commerce Cloud 等）中。通过连接器进行翻译可以保留平台自身的内容模型；导出底层数据库则会绕过它。
• 文本内容是应用程序的用户界面——按钮、菜单、错误消息——已经以 JSON 和 .properties 格式外部化。iOS .strings，或 Android XML。资源文件本地化是该内容的既定路径，将其移至数据库只会增加一层，而不会带来任何好处。
• 数据为面向公众的营销网页文案，由服务器端渲染。像 Smartling 的全球交付网络这样的翻译代理会在传输过程中翻译内容，包括数据库驱动的内容，而无需触及架构。

数据库本地化的最佳工具有哪些？如何评估这些工具？

数据库本地化的最佳工具是翻译平台，它们可以以编程方式摄取数据库内容（以结构化文件导出或通过 API 发布的字符串形式），对重复文本进行去重，保留占位符，并返回与原始行对应的翻译。请根据以下问题评估任何候选产品，包括 Smartling。

它是否接受数据库生成的导出格式？
JSON、CSV 和 XLSX 是表格导出的常用序列化目标格式。工具应该使用指令来解析它们，这些指令会标记关键列、源列和包含 HTML 的字段，而不是将每个单元格都视为纯文本。

它能否通过 API 直接接收字符串，而无需文件？
持续写入内容的应用程序可以从在写入时发布字符串和在请求时读取翻译中受益。Smartling 的翻译交付 API 是一个单一的端点，它接收源内容并在同一响应中返回任何可用的翻译；其文件和字符串 API 涵盖了异步上传然后下载模式。

它是否存储重复字符串的单个副本？
数据库内容本质上是重复的。无论字符串包含多少行或多少有效负载，该工具都只接收一次字符串，从而将翻译量与唯一文本挂钩，而不是与行数挂钩。

它如何处理文本中的动态值？
查找占位符支持和模式匹配规则，以屏蔽订单号、名称和计数，以便将“第 3 页，共 10 页”翻译为“第 {0} 页，共 {1} 页”。如果没有这个机制，每个变体都会被视为一个新的字符串。

它是否会自动应用翻译记忆库和术语表？
翻译记忆库可以免费返回以前翻译过的片段；词汇表可以强制要求在每个表格中使用产品名称和不可翻译的术语。这两点对于产品目录来说比对于营销文案来说更重要，因为产品目录的文字会重复出现。

能否将翻译结果回写到源行，并设置备用方案？
返回的翻译必须包含其所属的实体 ID 和语言环境，并且当尚无翻译时，工具或集成应返回源文本，以便应用程序永远不会呈现空字段。

数据本地化能否提升应用程序的性能？
从基础设施的角度来看——将数据存储在靠近用户的区域——是的，因为更短的网络路径会降低延迟；这是一个托管和驻留的决定，在数据主权与数据驻留中有所涉及。翻译意义上的数据库本地化对性能的影响有所不同：每次请求都会读取翻译表，这会增加一次连接操作，因此高流量应用程序通常会缓存翻译或从 CDN 托管的翻译包中获取翻译，而不是每次页面浏览都访问数据库。

Smartling 如何实现数据库内容本地化？

Smartling 通过三种已记录的路径对数据库内容进行本地化，这些路径的选择取决于应用程序如何公开其数据：低延迟交付 API 用于从代码推送的内容，结构化文件上传用于计划导出，以及翻译代理用于完全不应修改的数据库驱动的网站。

• 用于从应用程序发布内容的翻译交付 API — Smartling 的翻译交付 (TD) API 是一个高可用性、非阻塞端点，它接受请求正文中的源内容（HTML、JSON、XML、JavaScript 或混合有效负载），并立即返回任何可用的翻译；如果没有可用的翻译，则返回源文本并摄取字符串以进行翻译。Smartling 的文档描述了该平台在这种模式下充当翻译数据库，无论有多少有效负载包含该字符串，都会存储每个字符串的一个副本，因此在数千行中重复的产品描述只会翻译一次。有些客户使用 TD API 生成部署到 CDN 的更新翻译包，这样移动和 Web 应用程序无需构建或部署即可读取新的翻译。TD API 是一个付费产品，需要 GDN 项目进行配置，并支持命名空间、变体、占位符和视觉上下文。
• 文件 API 和用于计划导出的指令— 对于按计划导出表格的团队，Smartling 接受每个最大 10 MB 的 JSON、CSV、XLSX 和 XML 文件，并提供文件级指令来标识关键列、源列、翻译器指令以及应解析为 HTML 的字段。翻译后的文件以相同的结构返回以进行回写，并且相同的字符串会像任何其他内容一样流经 Smartling 的翻译记忆库和词汇表。
• 全球交付网络和数据库驱动网站的动态内容支持——对于 Web 应用程序，Smartling 的全球交付网络 (GDN) 翻译代理会在传输到浏览器时捕获内容（包括从数据库调用的内容），并在不更改架构的情况下替换翻译。动态内容支持功能在 2023 年 8 月之后创建的 GDN 项目中默认启用，它扩展了对 React 等 JavaScript 框架在浏览器中渲染的文本的支持，新的翻译会在发布后大约 20 分钟内到达页面。模式匹配规则会屏蔽动态值（订单号、名称、商品数量），因此“谢谢，您的订单号是 56783”会被存储一次为“谢谢，您的订单号是 {0}”，这种机制可以防止数据库生成的文本增加翻译量。

对于团队来说，在这三者中进行选择的实际意义在于：TD API 适用于已经拥有 API 网关并希望在请求时进行翻译的应用程序；文件导出适用于批量目录和后台内容；而 GDN 适用于公共网站，因为最快的方法是保持数据库不变。这三者都写入同一个翻译记忆库，因此当从数据库导出相同的字符串时，网站上翻译的术语会被重复使用。

相关问题

• 什么是数据主权？它与数据驻留和数据本地化有何不同？
• 用于本地化的 CSV 文件转换的最佳工具有哪些？
• 有哪些顶尖的 API 优先本地化平台？它们之间有何区别？