企业官网建设流程全解析

简介：面向使用Aras Innovator 11 SP9的中国用户与实施团队，这份简体中文汉化补丁是一整套完整的本地化方案，将默认英文界面转换为熟悉的中文操作环境，显著降低学习成本，特别适合PLM项目实施人员、系统管理员以及日常业务用户。压缩包共包含196个文件，以182个XML语言资源为翻译主体，另有4个BAT导入/导出脚本、2个EXE语言工具、DLL与config等辅助文件，整体包体仅为856KB。安装时依次执行脚本导入中文语言包并重启Web服务即可完成界面汉化，无需手工修改原始文件，部署速度很快。目前已有602人学习/下载，对希望快速落地Aras本土化应用的企业来说，这套补丁覆盖菜单、按钮、提示信息等全部界面元素，同时附带语言工具、配置示例和命令脚本，便于后续二次调整、内容校对与批量部署，也可以作为团队内部培训和多语言维护时的基础模板。

1. 语言包的导入时机比翻译本身更关键

做 Aras 11-sp9 汉化补丁，最容易被带偏的一件事是一头扎进翻译资源文件里逐条改字符串，改完之后兴冲冲导入，发现界面还是英文。这种翻车在 PLM 系统本地化里太常见了：Aras Innovator 的多语言机制不是简单替换文件，而是靠语言代码、客户端区域设置、数据库国际化列三层联动。补丁的核心不在词条数量，而在导入方式是否正确、语言优先级是否生效。你真正要做的是把 11-sp9 实例里所有业务对象上的 en 字符串资源批量复制、翻译、写回对应语言列，同时把客户端里硬编码的 XML 字符串也一并处理。这篇笔记面向实施工程师和负责 PLM 运维的同事，讲清楚怎么在测试环境做一套干净的语言包，导入后如何验证，以及最容易踩的五个坑。补丁本身不难，难的是带着验证清单去做，而不是导入完就看界面。

2. Aras 11-sp9 语言机制：先搞懂字符串存哪、按什么规则加载

2.1 三类字符串资源的存在位置

拿一份 Aras 11-sp9 的库表结构来看，翻译内容并不集中在一个语言文件里，而是分散在三处，分别对应不同的加载路径。第一类是数据库中的国际化列，几乎所有核心业务表都有带 _en、_fr、_zh-CN 后缀的列，Item 表、Life Cycle 表、Workflow 表、Report 表都是这样。系统根据当前会话的语言代码去读对应那一列。第二类是 Aras 客户端安装目录下的 XML 资源文件，比如 Forms 定义、菜单标签、工具栏按钮文本，这些不走数据库，直接由客户端加载。第三类是服务器端返回的错误消息与 AML 交互文本，存在 InnovatorServer 的安装目录配置里，通常以语言包形式放在某个固定子目录。汉化补丁要覆盖这三层才算是「完整汉化」，只处理数据库列只完成了一半。

2.2 语言代码的匹配规则才是决定界面语言的原动力

Aras 的语言优先级判断依次为：服务器端配置的默认语言、客户端请求头里的 Accept-Language、登录用户个人设置里的 Language 字段、浏览器当前语言。11-sp9 在服务器管理界面里有一个 Language 选项卡，需要先确认 zh-CN 已经被注册为合法语言代码。很多补丁导入不生效，就是因为用户个人配置里的语言还停在 en，而服务器端唯一语言也设成了 en，浏览器再怎么调中文也白搭。语言代码一定要是 RFC 标准格式的小写中划线，写成 zh_CN 或者 zhCN 都可能导致无法匹配，这在 11-sp9 上没有容错处理。注意界面语言的切换还需要重新登录才会重建会话，仅刷新页面不生效是常见误操作。

2.3 数据库国际化列里的 NULL 值不会自动回退英文

另一条关键机制：Aras 对国际化列的取值逻辑是直接取当前语言列，取到就显示，取不到不显示内容，并不会回退到 _en 列。这跟很多业务系统「取不到本地化值就回退默认语言」的做法相反。所以在做汉化时，必须保证 zh-CN 列里有值，而不是只把 en 列里的英文清理掉。反过来也提醒一点：新建测试数据时如果 zh-CN 列是 NULL，前台会显示空白，而不是英文，这有助于判断当前会话语言代码是否是 zh-CN。利用这一条，导入补丁后可以新建一条测试 Item，看显示效果来决定是语言代码问题还是补丁内容问题。

2.4 服务器端缓存的更新策略

Aras 11-sp9 在启动时会加载语言资源进内存缓存，后续通过 AML 调用读取。直接改数据库里的字符串不会触发自动刷新，需要重启 Innovator 服务或调用专门的重置缓存接口。如果数据改了很多，服务重启一次把所有缓存清干净最省心。客户端 XML 资源的加载则是随客户端启动，所以改完本机 XML 要重启 Aras 客户端。很多人改完库表数据不重启，看界面没变就以为补丁没生效，其实缓存已经把它拦住了。做补丁时的标准顺序是：改数据库 → 清服务器缓存 → 改客户端 XML → 重启客户端 → 验证。

3. 动手做一套最小可用的 11-sp9 汉化包

3.1 准备一份盘点清单而不是直接开改

我一般先在测试库上做一次资源盘点，确定要动哪些表、哪些列、多少条记录，而不是打开界面一个个打字。11-sp9 的库是 SQL Server 或 Oracle 都可以，下面以 SQL Server 为例给出盘点脚本。核心思路是查系统表，把所有带语言后缀的列找出来，再看这些表的数据量，判断翻译工作量主要集中在哪几个表上。

SELECT t.name AS table_name, c.name AS column_name FROM sys.tables t INNER JOIN sys.columns c ON t.object_id = c.object_id WHERE c.name LIKE '%[_]en' ORDER BY t.name, c.name;

这段脚本把库中所有以en 结尾的列列出来，这些列对应的表就是要处理的。同表的 zh-CN 列是否齐全，可以再用同样条件查一遍对比。注意列名过滤用的是方括号转义，SQL Server 里下划线是通配符，必须用 [] 才能匹配字面下划线。拿到清单后我会按数据量排序，优先处理记录数大的表，因为工作流模板、报表定义、菜单资源都集中在这些大表里。如果某些表只有十几条记录且明显是配置表，翻译优先级可以往后放。

3.2 批量复制英文列到 zh-CN 列的基础脚本

补丁的第一步是把已有的英文值批量复制到 zh-CN 列，先把列填满，再逐条替换为中文。这样能避免漏译后显示空白的问题。以 ItemType 表的 name 字段为例，脚本是这样的：

UPDATE it SET it.name_zh_CN = it.name_en FROM innovator.ItemType it WHERE it.name_zh_CN IS NULL;

把 ItemType、Workflow、Report 这些核心表的 *_en 列值复制到对应的 *_zh-CN 列。不是所有列都要动，像 created_by_id、modified_on 这类非语言列不需要理会。Aras 在 11 版本里对国际化列的命名统一是列名加语言代码后缀，中间用下划线，所以 name_en 对应的中文列一定是 name_zh-CN。再啰嗦一句，台湾繁体场景要写成 zh-TW，别用 zh-CN 顶替。

3.3 用 UPDATE 关联子查询做词条对照替换

复制完英文后就是正式翻译。手写几百条 UPDATE 不现实，常见做法是建一张临时对照表，把英文原句和中文译文放进去，再用一条关联 UPDATE 把译文写回目标表。对照表建议放在独立库或 Aras 库的临时 schema 里，不要直接写进 Innovator 的业务表结构里。

-- 临时对照表，english_text 存界面原始字符串，chinese_text 存对应中文 CREATE TABLE temp_translation ( english_text NVARCHAR(500) PRIMARY KEY, chinese_text NVARCHAR(500) ); -- 以 Workflow 表名为例做关联替换 UPDATE wf SET wf.name_zh_CN = tt.chinese_text FROM innovator.Workflow wf INNER JOIN temp_translation tt ON wf.name_en = tt.english_text WHERE wf.name_zh_CN IS NULL OR wf.name_zh_CN = wf.name_en;

这段逻辑里要注意三个点。第一，匹配条件是精确匹配英文原值，所以对照表里的英文串必须和库里完全一致，多一个空格都匹配不上，这也是很多补丁「部分生效」的原因。第二，WHERE 条件限定只更新还没有中文值的行，防止重复覆盖人工调整过的译文。第三，主键设在 english_text 上，如果同一英文串在不同界面出现不同译法，这个设计就不够用，需要给对照表增加上下文列再做复合匹配。翻译阶段建议多次分批导入，每批 200 条左右，完成后抽查几条数据，确认没有错位。

3.4 客户端 XML 资源的本地化处理

数据库层搞定后，打开 Aras 客户端看一遍界面，还有不少英文。菜单栏、右键菜单、部分弹窗文本存在客户端安装目录下的 XML 文件里，路径一般是 C:\Program Files\Aras\Innovator\Client\ 下按语言代码分的子目录，默认只有 en 子目录。汉化做法是复制 en 目录为 zh-CN 目录，然后打开里面的 string 标签做替换。这个目录结构在 11-sp9 里是稳定的，至少从 11 到 12 没有大改动。脚本里用 PowerShell 批量做占位符检查会快一些。

Get-ChildItem "C:\Program Files\Aras\Innovator\Client\zh-CN\*.xml" -Recurse | ForEach-Object { $content = Get-Content $_.FullName -Raw -Encoding UTF8 if ($content -match '\$|%1|{0}') { Write-Host "$($_.Name) 包含占位符，需重点检查" -ForegroundColor Yellow } }

这段脚本的作用不是替换文本，而是找出所有带占位符的字符串文件，重点检查这些条目的翻译有没有破坏占位符结构。Aras 的资源字符串常用 {0} 或 %1 做参数插入，把占位符翻成中文或删掉，会导致运行时拼接出错。检查完占位符之后才是逐文件翻译，核心是 Forms 定义里的标题属性。这个目录下的 XML 文件替换要谨慎，不要整文件覆盖，建议逐标签修改，保留原文件结构。

3.5 导入补丁包还是直接改库：两种方案怎么选

直接改库适合小团队、数据量几千条的场景，脚本可复现、出问题容易回滚，缺点是后续升级到更高版本时补丁要重做。另一种路径是做成 Aras 标准语言包导入，也就是打包成 .zip 的 AML 文件，在管理界面里通过 Packages 导入，这种方式的好处是可以在测试环境做完整验证后再部署到生产，也可以跟随版本升级重新导入。但做一个完整可导入的包需要维护 package 定义文件、依赖列表、版本号，对于只想快速把界面转成中文的团队来说成本偏高。我的建议是：如果项目只有一套环境、一个实例，直接改库最快；如果有多套环境要同步，做成包。两种方法在 11-sp9 里的最终效果没有区别，系统读的都是数据库节点和客户端 XML，不存在「导入包才正规」的说法。

4. 汉化覆盖范围的优先级：哪些必须做，哪些可以不做

4.1 第一优先级：必现界面字符串

登录页、主导航菜单、左侧 TOC 树、表格右键菜单、Item 的编辑表单标题、常用对话框按钮，这些是用户每天打开系统第一眼看到的内容，必须优先覆盖。这类字符串大多来自数据库的国际化列，少量来自客户端 XML。做法上，登录页标题和按钮文本走客户端 XML，主导航菜单走数据库里的 Menu 表，TOC 树节点名称是 TOC 表的 name 列。建议最后验证时重点过一遍：登录 → 展开左侧 TOC → 打开一个 Item → 右键 → 新建 → 保存，这条路径走完没有英文，基础汉化就算达标。

4.2 第二优先级：工作流、生命周期、报表模板内容

工作流模板里的节点名称和路径名称、生命周期状态名称、邮件通知模板、报表输出的表头标题，这类内容直接出现在日常业务流程中，而且经常被业务部门拿来当「系统没汉化好」的证据。这类内容的特点是数据同一条记录会在多个地方显示，比如同一个生命周期状态既出现在表单下拉里，又出现在历史记录里，还出现在邮件通知里。改动前先确认各处显示的是不是同一个字段，有些状态是冗余存储的多份副本，只改主数据不够。比较稳妥的做法是先用 SQL 统计所有引用该状态名的表，统一更新，保证全链路一致。

4.3 第三优先级：错误消息与系统提示

业务对象级校验、权限不足提示、AML 执行失败报错，这些内容出错频率低、但一旦出现就是用户必须理解的信息。Aras 的错误消息有一部分从数据库读取，有一部分内置在服务器安装目录的 XML 配置文件里。前一类的处理方式和前面一样；后一类不建议彻底翻译，因为错误消息还含服务端日志编号，改了之后排查问题时会失去对应关系。我一般只翻对用户可见的那几句，比如「Item 不存在」「没有权限执行此操作」，保留技术性错误原文。这样既减少工作量，又避免把错误消息翻得偏离技术原意。

4.4 第四优先级：可选内容

帮助文档链接、在线教程内嵌说明、示例库里的演示数据、管理界面里的环境配置项说明，这些内容非核心用户高频路径，可以在项目稳定运行后再慢慢补。管理界面里的配置项说明通常从数据库读，切到中文时如果没翻，会显示英文，对管理员来说可以接受。示例库演示数据不要翻译，因为这些数据通常是验收时的测试基准，翻掉之后验收脚本比对会失败。这些内容放到后期做增量包即可，不影响一期上线。

4.5 汉化范围决策的一个原则

原则就一条：用户高频路径优先，报错信息里给用户看的内容优先，日志文本和技术描述不优先。与其在离线文档上花一周做完美翻译，不如先保证最常用的二十个操作路径完全没有英文漏出。很多项目汉化失败不是词条不够多，而是都给用户平均用力翻译了，结果最关键的新建、查询、审批按钮还是英文。补丁的核心价值是业务可用，不是语言纯净度。

5. 汉化补丁避坑指南：五个真实翻车点

5.1 语言代码写法不一致，界面纹丝不动

现象：导入补丁后重新登录，界面还是英文，查看用户语言设置已经是 Chinese，浏览器首选语言也调整了，重启客户端无效。

原因：服务器端注册的语言代码是 zh-CN 还是 zh_CN，用户设置里选的是哪种代码，浏览器 Accept-Language 带的是什么格式，三者不匹配的时候以服务器端配置为准。Aras 11-sp9 对语言代码的匹配区分大小写，文件名和数据库后缀都必须用一致的小写格式。

解决：把服务器端语言选项卡里注册的语言代码删掉重新添加，统一写成 zh-CN。同时把用户的 Language 字段手动改成 zh-CN，不要依赖浏览器设置继承。改完退出客户端，重新登录一次，再打开任意 Item 验证。

5.2 中文变成问号或乱码

现象：翻译完导入后，所有中文显示为问号，少数地方显示为方框，数据库里查数据是正常中文。

原因：客户端传入的字符串编码与服务端数据库字符集不一致。Aras 11-sp9 服务端默认按 UTF-8 处理请求，但如果数据库的排序规则是非 UTF-8 的旧版本兼容设置，写入时会发生隐式转换。常见场景是 SQL Server 实例排序规则是 Chinese_PRC_CI_AS，而客户端持 UTF-8 传入，在写入含生僻字时出问题。

解决：把 SQL Server 数据库的排序规则改为支持 UTF-8 的版本（SQL Server 2019 以上），或者把涉及语言列的所有表的列类型改为 nvarchar，避免隐式转换。Oracle 库则检查 NLS_CHARACTERSET 是否 AL32UTF8，并把 NLS_LANG 设为对应编码。改完后重跑一遍翻译更新脚本，已写入的乱码行需要先清空再更新。

5.3 导入后一半生效一半没生效

现象：主界面菜单变成中文了，但工作流里的节点名称还是英文，邮件通知模板一半中文一半英文。

原因：字符串资源分散在不同存储位置，更新了数据库但客户端 XML 资源没改，或者数据库里这张表改了、另一张表没改。另一种可能是对照表的英文原值不精确，部分行的匹配失败。

解决：先把第 2 章里的资源盘点 SQL 跑一遍，列出所有带 _en 后缀的列和所在表，然后逐表核对更新语句是否覆盖。对于工作流这类内容，打开模板看具体字段属于哪个表，找到对应表再补一次 UPDATE。对于客户端 XML，确认对应语言目录下的文件与 en 目录的文件数量和名称一致，缺文件的复制过去再改。

5.4 做好的翻译被系统重新生成的英文覆盖

现象：手动翻译完几个表单标题，过了一天再看，标题又变回英文。

原因：Aras 在升级服务端包、导入新包或安装新扩展时，会自动刷新部分字符串资源，覆盖数据库里对应语言列的值。另一种情况是业务对象本身在开发环境被重新导出导入，语言列被源系统带的英文值覆盖。

解决：把翻译前原值备份到独立表里，做一次基线归档。每次系统包更新后，基于归档表做差异比对，找出被重置的条目，重新应用译文。如果更新频繁，可以把翻译做成触发更新后自动执行的存储过程，避免手工反复操作。覆盖发生时先别急着重翻，确认是正常覆盖还是数据错误，避免用错误逻辑把正确译文再覆盖一遍。

5.5 占位符被改坏，运行时弹窗报错

现象：某些弹窗里出现「{0}」或者「%1」的字样，甚至整个弹窗无法渲染。

原因：翻译时把界面上的原始英文当成整体句意处理，把占位符删掉或者调整了顺序。Aras 客户端渲染字符串时按索引找参数，占位符丢失或顺序乱了就会拼接失败。

解决：做替换前先跑一遍本章第 3.4 节的 PowerShell 检查脚本，把所有包含占位符的文件列出来，翻译这些条目时把占位符原样保留、整体移动到中文语境下合理的位置，不能删除。如果已经改坏，把对应 XML 文件回退到 en 目录原版，重新翻译一遍。占位符相关条目建议单独建立对照清单，避免和其他词条混在一起。

6. 汉化成果验证与后续增量更新的三个技巧

6.1 用一条 SQL 快速检查翻译覆盖率

导入补丁后，与其一遍遍点界面，不如直接跑一条覆盖率统计，把所有核心表的翻译进度拉出来看。以 11-sp9 的库为例，下面这段脚本统计核心表的 zh-CN 列填充比例：

SELECT 'ItemType' AS table_name, COUNT(*) AS total_rows, SUM(CASE WHEN name_zh_CN IS NULL OR name_zh_CN = name_en THEN 0 ELSE 1 END) AS translated_rows FROM innovator.ItemType UNION ALL SELECT 'Workflow', COUNT(*), SUM(CASE WHEN name_zh_CN IS NULL OR name_zh_CN = name_en THEN 0 ELSE 1 END) FROM innovator.Workflow;

把表名换成盘点清单里的核心表，依次执行即可。覆盖率不等于质量，但它帮助确认没有大面积漏译。如果某张表翻译率很低，先看这张表是不是真的需要翻译，比如系统日志表就无所谓。注意这个统计不能查出翻译错位问题，错位还是要靠界面抽查。

6.2 用浏览器开发者工具定位未汉化文本的来源

界面上出现漏网英文时，按 F12 打开开发者工具里的 Network 面板，重新加载页面，看页面发起请求返回的数据里对应字符串是来自数据库节点还是客户端返回的 XML。如果是 AML 请求返回的 result 里带着英文，那就是数据库列漏翻；如果是客户端本地加载的 XML 文件，刷新后直接在 Sources 面板里搜索原英文词，能快速定位到具体文件。这个技巧比在几十个 XML 文件里翻找高效得多，实测定位一个漏译词通常不超过两分钟。记住这个定位动作的关键：先确定来源层，再动手改，不要凭感觉把英文串在数据库和 XML 里都翻一遍。

6.3 增量补丁维护要带着基线走

第一次汉化做完，后续每季度可能有一批新词条出现，比如新表单、新流程模板、新系统包。我现在的习惯是维护一份翻译基线表，记录历史已翻译词条和对应译文。新词条进来时，直接和基线表做 LEFT JOIN，匹配不到的就是需要新增的词条，匹配到但源码变化了的就需要确认是否沿用旧译文。这个操作我在项目里负责后续维护时一直在用，效果是后面每次系统升级或新增流程，只需要花很少时间完成翻译增量，不用从零再盘一遍。做基线表的核心是坚持维护，哪怕刚开始只有几百条。另一个补充习惯是每次改完数据库字段，都会顺手检查一下对应客户端 XML 文件里有没有同名文本，因为 Aras 里同一个英文词很可能在两处同时存在，只改一处界面不彻底。

到这个程度，一套 Aras 11-sp9 的汉化补丁就达到了「业务可用」的标准。要说一点血泪经验：本地化本质是持续维护工程，不是一次性导入就收工，每次环境更新、包升级都要把验证清单跑一遍再放给业务用。希望这套流程和坑位判断能帮到你，祝一次导入就生效。

本文还有配套的精品资源，点击获取