企业官网建设流程全解析

简介：Aras Innovator 11 SP9 汉化补丁是为使用该开源PLM系统的国内团队定制的本地化资源包，适合需要中文界面以降低学习门槛、提升操作效率的实施人员与最终用户。补丁针对11 SP9版本提供完整的中文语言文件，覆盖菜单、按钮、提示信息等核心界面元素，同时包含批量导入脚本与语言工具，可简化部署流程。压缩包共196个文件，以xml本地化数据为主，辅以bat自动导入脚本、exe语言处理程序及少量配置与动态库文件，整体仅856KB，轻量易用。目前已有599人学习下载。借助该补丁，用户可彻底摆脱英文界面的束缚，直接使用中文完成产品结构管理、变更控制、项目协同等工作，不仅能显著缩短上手周期，还能减少因语言理解偏差造成的操作失误，是Aras 11 SP9本土化部署中极为实用的一站式语言解决方案。 这活儿我太熟了。前阵子刚帮一家做装备制造的企业把Aras Innovator 11-sp9的界面从满屏英文折腾成清爽中文，整个过程中间还走了不少弯路。今天把这套汉化思路和实操细节整理出来，给同样被Aras多语言机制搞得头疼的朋友一个抓手。

先明确一个现实：Aras Innovator官方是不提供简体中文语言包的，11-sp9这套老版本更是如此。市面上流传的所谓“汉化补丁”，本质上不是官方出的安装包，而是实施方或第三方团队基于Aras的多语言框架自己整理的一套翻译资源。你完全可以自己做，也可以基于别人放出的补丁二次修改。关键在于你得先搞清楚它的多语言机制藏在哪，否则就算拿到补丁，也只会无脑导入，一旦出问题就抓瞎。

我的建议是：别把汉化当成“装个软件”，把它当成一次“数据更新+资源替换”的运维操作。下面我会从机制原理到实操步骤，完整拆一遍。

1. 汉化前先搞懂：Aras 11-sp9的多语言机制到底藏在哪里

很多人第一次接触Aras汉化，第一反应是去安装目录找语言文件。这方向没错，但只对了一小半。Aras Innovator的界面文本来源分三个层级，弄混了就会陷入“改了没反应”或者“这里中文那里英文”的尴尬境地。

1.1 三个文本来源层级

第一层：数据库的String表。这是最核心的部分。Aras的底层数据库（通常是SQL Server）里有专门的String表，存储着大量界面标签、菜单名称、按钮文字对应的多语言键值。它的结构大致是：一个字符串标识符，加上不同locale_id对应的翻译值。汉化补丁的核心内容之一，就是往这张表里批量更新或插入简体中文的翻译条目。

第二层：客户端和Web前端的资源文件。经典客户端（Windows桌面客户端）和一些Web页面控件，有部分文本不经过数据库String表，而是直接读资源文件，比如.NET的resx文件或者样式表里写死的文字。这一层如果你只改数据库，就会漏掉——最常见的表现就是登录界面、左侧导航部分文字、右键菜单的某些选项，怎么切语言都是英文。

第三层：XSL样式表和业务数据。Aras的列表视图、表单布局很多是通过XSL渲染的，部分标题、提示文本直接写在XSL模板里。另外，管理员在后台创建的ItemType名称、属性标签、工作流邮件模板，这些属于业务数据，它们的文本存在数据库的业务表里，和String表机制还不一样。

1.2 官方的locale体系

Aras自身是支持多语言切换的，安装包里带了英语、法语、德语、日语、西班牙语等语言资源。简体中文之所以没有，纯粹是官方没做。但它的语言框架是通用的：只要你往String表里补齐简体中文（一般locale_id对应的是类似于zh-CN的记录，不同版本命名可能不同）的翻译值，再在用户配置或客户端语言选择里切到中文，系统就能正常加载。

所以，你要做的“汉化补丁”，本质上就是两个部分：一份完整的String表中文翻译数据，加一份需要覆盖的资源/样式表文件清单。

注意：不同Service Pack版本（比如sp8和sp9）的String表结构、内置条目数量是有差异的，数据库表结构也可能有细微变化。汉化补丁必须严格匹配11-sp9版本，混用sp10或12.0的补丁，轻则部分翻译不生效，重则报错。

2. 核心实操：用SQL脚本批量注入中文翻译

现在进入正题。不管你是拿到现成的补丁文件，还是想自己在原版基础上做一套完整汉化，都得跟数据库打交道。以下是我在11-sp9上实际验证过的流程。

2.1 先定位基础数据

登录SQL Server，找到Aras Innovator对应的主数据库（一般是Innovator库）。先查一下语言环境表里有没有简体中文：

SELECT * FROM [Innovator].[dbo].[Locale] WHERE [locale] LIKE '%zh%' OR [locale] LIKE '%cn%'

如果查询结果为空，说明当前数据库根本没有创建中文语言环境记录，需要先插入一条：

INSERT INTO [Innovator].[dbo].[Locale] ([id], [locale], [name], [core], [keyed_name]) VALUES ('你的唯一ID', 'zh-CN', 'Chinese (Simplified)', '1', 'Chinese (Simplified)')

这里的id需要你自己生成一个GUID格式的唯一值。如果已经有这条记录了，跳过插入直接查String表里中文条目数量：

SELECT COUNT(*) FROM [Innovator].[dbo].[String] WHERE [locale_id] = '刚才查到的Locale记录ID'

如果count为0，说明一个中文翻译都没有，接下来要做批量插入；如果已经有部分数据，那你可以只做增量更新覆盖，避免破坏已有内容。

2.2 批量更新的正确姿势

Aras的String表数据量很大，手工一条条update不现实。一般的汉化补丁SQL脚本长这样：

-- 备份目标表再做更新，永远是好习惯 SELECT * INTO String_Backup_2024 FROM [Innovator].[dbo].[String]

然后针对每条英文记录，找到对应的中文翻译，用update语句更新。比如：

UPDATE [Innovator].[dbo].[String] SET [value] = N'新建' WHERE [key] = N'New' AND [locale_id] = '中文Locale的ID'

但这样写很累。实际成熟的汉化补丁脚本通常是用临时表把中英文对照导入，再一次性join更新。我自己更推荐的方式是准备一个翻译对照表（Excel或者CSV），通过SSMS的导入功能先把数据导进临时表，再执行merge更新：

MERGE INTO [Innovator].[dbo].[String] AS target USING [TempTranslate] AS source ON target.[key] = source.[key] AND target.[locale_id] = source.[locale_id] WHEN MATCHED THEN UPDATE SET target.[value] = source.[value] WHEN NOT MATCHED THEN INSERT ([id], [locale_id], [key], [value], [is_comment], [created_on], [...]) VALUES (NEWID(), source.[locale_id], source.[key], source.[value], 0, GETDATE(), ...);

这里有几个坑必须提醒：

• 给value赋值时一定要加N前缀，它就是为Unicode准备的。如果忘记加N，中文写入后直接变乱码或问号。
• 排序规则要统一。如果库里字段的collation本身对中文不友好，写入时可能会报错或截断。
• String表里的value有些带格式化占位符（比如{0}、{1}），翻译的时候不能删掉这些占位符，否则界面显示会缺参数甚至崩溃。
• 有些英文条目是多义词，脱离上下文盲翻会出笑话。比如“Type”在Aras里通常指ItemType类型，但某些场景指“打字”。翻译补丁的质量差异就在这种细枝末节上。

2.3 更新完必须做的缓存清理

这个步骤极其容易漏。Aras有客户端缓存和服务端缓存，String表更新后，不清理缓存的话，界面看到的还是旧英文或者空值。操作路径是：

• 客户端：关闭Innovator客户端，删除本地缓存目录（一般在%ProgramData%\Aras\Innovator\下的ClientCache或类似目录），重新登录。
• 浏览器端：清理浏览器缓存之外，还要在Innovator登录页面的工具栏里有刷新缓存选项，有些版本在管理员工具里可以直接执行Clear Cache。
• 服务端IIS：回收一下应用程序池，让ASP.NET进程重新加载资源。

这一套操作下来，基本第一层的文本就能变成中文了。

3. 突破第二层：XSL样式和资源文件里“漏网”的英文

数据库翻译完了，只是完成了一半。真正让汉化看起来专业、不露馅的，是处理那些不经过String表的硬编码文本。

3.1 XSL样式表修改

Aras 11-sp9经典客户端的很多表单布局用XSL渲染，比如我的桌面、部分查询结果的表格表头、右键菜单的动作名称。这些文本很多是直接写在XSL文件里的。它们的存放位置一般在服务端安装目录的..\Innovator\Client\Themes\或..\Innovator\Styles\下，不同模块的XSL分散在对应子目录。

网上流传的汉化补丁如果比较完整，会带一份覆盖用的XSL文件列表，你只需要按文件路径覆盖到服务端对应目录，然后重新加载客户端。如果你要自己改，用文本编辑器搜索英文关键词，找到对应的<td>或<label>里的文字直接替换成中文即可。

这里要注意：改XSL之前一定要先备份原文件，因为Aras升级Service Pack时很可能覆盖这些文件，维护基线很重要。

3.2 客户端resx资源文件

经典客户端（Windows窗体客户端）本身有些内置菜单，比如主菜单的File、Tools、Help，这些走的是.NET的resx资源文件。汉化方式是用ILSpy或Visual Studio打开客户端的程序集，找到对应的resx文件，翻译后重新编译，或者直接修改客户端的Language配置目录下已有的语言资源文件。

这个操作相对硬核，普通运维可能搞不定。实际项目中我经常看到的情况是：主界面、表单界面中文了，但客户端顶部菜单栏还有个别菜单项是英文。很多团队选择忽略，因为确实影响不大。如果你追求极致，那就得按这个路子来：先确认客户端是.NET Framework版本，用工具反编译定位资源，翻译后rebuild，再替换安装目录下的程序集。

这条路的代价是需要开发人员介入，而且Aras升级后要重做，维护成本较高。我的个人评估是：如果只是内部使用，改数据库+XSL就覆盖95%了，resx里的残留英文可以在培训时口头说明，不值得为了几个菜单项投入反编译改造的工程量。

3.3 中文字体问题

改完这些之后，如果你发现在某些报表预览、图表导出、PDF生成时中文变成方框或者乱码，那就不是翻译的问题，是服务器缺中文字体。Aras的报表引擎（特别是老版本常用的SSRS或水晶报表组件）在生成PDF时需要操作系统里有对应字体文件。

解决办法很粗暴但有效：在运行Aras报表服务的Windows服务器上安装中文字体包，比如宋体、微软雅黑（按服务器授权许可来），装完重启报表服务和IIS。

提醒一句：这一步最容易在项目验收时被翻出来。业务人员打开一张导出的报表，全是“□□□”，然后整个项目就打上了“汉化不全”的标签。提前把字体装好，能省无数沟通成本。

4. 别漏掉业务数据：ItemType属性和工作流邮件模板

界面翻译完了，还有一个容易被忽略的领域：业务人员自己在Aras里创建的ItemType、属性、工作流邮件通知模板。这些东西的文字默认存在业务表里，不是String表管的，必须单独处理。

4.1 ItemType属性显示名称

假设你们在系统里建了一个叫“Supplier”的ItemType，它的属性“Address”“ContactName”在表单上默认显示英文。要汉化这些，需要管理员进入Innovator的ItemType配置界面，逐个属性的“Label”字段改成中文，同时把多语言支持下对应的语言条目补上。

操作路径是：管理程序 → ItemTypes → 找到目标ItemType → Properties标签页 → 选中属性 → 编辑Label。如果你的系统开了多语言，还能在Label属性旁给不同locale单独设置翻译值。

这一步是纯手工活，但确实躲不掉。好在一般企业自建的ItemType数量有限，花半天时间就能处理完。

4.2 工作流邮件通知模板

Aras的流程邮件通知默认模板也是英文的，业务人员收到邮件看到满屏英文，体验很差。这些模板存放在管理程序的“Emails”或“Notification”相关配置里，可以直接在界面上编辑HTML内容。

我的做法是：选一个最常用的通知类型，把英文HTML整体替换成中文HTML模板，保留里面的占位符变量（如<ItemNumber>、<CreatedByName>），改完以后所有走这条通知的邮件都会用新模板。注意不要误删变量，否则邮件里就会出现空值或者原样输出标签。

4.3 历史数据里的英文内容

如果系统已经跑了一段时间，历史流程历史任务里存了英文的名称字段，这部分即使切了语言也还是英文。这种情况不用强求，因为业务数据本身的名称属性就是英文，翻译成中文反而会跟原数据不一致。我们上线时跟业务部门达成的共识是：历史数据保留英文原样，新数据进入系统前由录入人员使用中文填写，系统界面类文本全部汉化。

这个取舍很重要，提前讲清楚，就不会有人拿一条旧记录来质疑“为什么这里还是英文”。

5. 汉化补丁的打包、验证和上线流程

最后说一下补丁本身怎么组织、怎么测试、怎么发布，让这套汉化能在团队里安全落地。

5.1 补丁包的文件结构

一份完整的Aras 11-sp9汉化补丁应该包含：

• SQL目录：String表更新脚本、Locale插入脚本、可选的恢复/卸载脚本。
• XSL目录：需要覆盖的样式表文件，目录层级跟服务端安装路径一致。
• Client目录：替换客户端资源文件的可选文件。
• Docs目录：变更说明、覆盖文件清单、验证Checklist。

按这个结构整理的好处是：交付给同事或客户时，对方知道先跑什么、再覆盖什么、最后验证什么，不用你全程手把手指导。

5.2 验证Checklist

上线前，我建议按下面这个清单逐项过一遍，每项都实际点开看，而不是只截图：

• 登录界面：能否正常显示中文，语言切换器是否出现中文选项。
• 主导航和仪表盘：左侧菜单、欢迎页文字全中文。
• 表单视图：打开各核心ItemType的创建和编辑表单，字段标签是否中文。
• 右键菜单：列表上右键，菜单项是否中文。
• 查询/搜索框：内置查询命令、快捷搜索提示是否中文。
• 工作流：发起流程、审批任务邮件通知是否中文模板。
• 报表：导出PDF后中文是否正常显示。
• 权限和角色：权限配置界面是否正常中文。

每项如果有遗漏，就回到对应的层级去排查：是String表没命中，还是XSL没覆盖，还是缓存没刷新。按这个分层思路定位，基本十分钟内能锁定问题。

5.3 上线顺序建议

我踩过的坑是直接在正式环境上跑脚本，结果某个条目Key冲突导致页面报错。稳重一点的做法是：先在测试环境完整跑一遍全部SQL和文件覆盖，确认无报错、无异常，再在正式环境做同样操作。SQL部分务必提前备份String表和相关表，文件覆盖部分也先备份原文件。这样万一出问题，可以一键回滚。

另外，如果你们后续有升级计划，升级到12.0或更高版本时，这套补丁大概率不能直接复用，但里面的翻译对照表是宝贵资产，可以导出保留，给新版本的汉化工作打个底子。

6. 关于补丁的维护，我再说几句

汉化不是一锤子买卖。Aras里的ItemType、属性、流程模板会随业务推进不断增加，每新增一个属性或模板，就可能有新的英文文本需要翻译。我们现在的做法是把翻译对照表放进一个Excel放共享盘，每次新增业务对象时，实施人员顺手把新出现的界面文本补充进去，积累一段时间后就形成了企业自己的标准词库。

这样做的另一个好处是：同一个英文术语在全系统里的翻译能保持一致。比如“Part”统一译成“零件”，而不是有的地方“零件”、有的地方“部件”，这种一致性对制造业客户尤其重要，很多质量体系审核会盯着术语规范。

11-sp9虽然已经算老版本了，但国内存量项目还是不少。希望这篇拆解对正在和它较劲的兄弟有点帮助。特别是如果你拿到的汉化补丁只带SQL脚本，那请你一定记得验证一下XSL和资源文件那一层——大多数“汉化不彻底”的投诉，源头都在那里。

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