企业官网建设流程全解析

1. 从下载开源电气软件到决定自己动手汉化

做电气设计的同行应该都有这种经历：想找一个免费、跨平台、能画电气原理图的软件，翻遍全网发现要么是商业软件的破解版，要么是功能残缺的免费版。后来我接触到QElectroTech，这个开源电气软件算是把我从老旧的盗版CAD工具里解放了出来。软件本身免费开源，原理图、元件库、报表导出都做得有模有样，但它一直存在一个痛点——汉化不彻底。界面上中英文混杂，很多二级菜单和设置项还是英文，电气符号库里的图例说明更是大段大段的外文。对英文不好的工程师来说，光是把一个端子连接器的属性配明白，就得来回查词典。

所以就动了汉化的念头。本来以为就是个翻译活，真正做起来才发现，QElectroTech的本地化工作牵扯到Qt框架的翻译机制、元件库的元数据、图纸模板的文本结构这几个层面。这篇文章把我整个汉化过程拆开来讲，包括我踩过的坑、走弯路后总结出的正确操作顺序，以及针对电气专业术语的处理思路。无论你是想自己汉化一份来用，还是想给项目提交中文翻译贡献，都能从中找到可以直接照搬的办法。

先说结论：QElectroTech的汉化不是一个单一动作，它至少要覆盖四条线——程序界面、元件库项目、图纸标题栏模板、帮助文档。多数人只盯着界面翻译，结果做完后打开软件确实菜单变中文了，但调取一个接触器符号时，符号属性框里还是满屏英文。这个完整度差异，恰恰是汉化质量的真正分水岭。

2. 看清QElectroTech的软件构成，才能确定汉化的正确下手位置

2.1 不搞懂模块关系，汉化就会顾此失彼

QElectroTech从用户视角看是一个软件，实际上可以拆成几个独立又互相调用的部分：主程序负责原理图绘制逻辑，元件库管理器负责管理和预览各种电气符号，导出模块负责生成PDF、图片等格式的报表，还有一套内置的图框和标题栏系统。这些部分共用一部分翻译资源，但又各自持有独立的文本来源。

第一次汉化时我吃过亏。当时只翻译了主程序的翻译文件，启动软件后菜单栏确实变成了中文，但当我进入元件编辑器去创建自定义符号时，所有工具提示和属性标签又回到了英文。后来才意识到，QElectroTech在源码层面分成了多个模块，不同模块拥有自己的翻译文件。如果只处理了主程序的翻译条目，其他模块就会回退到默认语言。这是个特别容易忽略的环节。

2.2 从技术栈推断汉化路径

QElectroTech是典型的C++和Qt框架项目，这一点对汉化工作来说是巨大的利好。Qt自带了一套非常成熟且规范的国际化和本地化机制：开发者在代码里用tr()函数包住可翻译字符串，编译时生成翻译源文件，通过Qt Linguist工具可以逐一翻译，最后发布为轻量级的二进制翻译文件。这意味着汉化QElectroTech并不需要反编译可执行程序，也不需要去改动二进制里的字符串，只要处理翻译源文件并重新生成翻译包，就能完成界面的中文化。

这基本决定了整个汉化工程的操作逻辑：站在Qt翻译机制的轨道上做工作，而不是靠暴力替换字符串。理解了这一点，后面所有步骤都有了依据。很多新手上来就搜“QElectroTech汉化补丁”，下载别人打包好的文件直接覆盖，但这只能解决英文界面的表层问题，一旦升级版本或安装新元件库，汉化就会失效甚至报错。自己掌握翻译文件的生成和更新方法，才是一劳永逸的做法。

3. Qt多语言机制与QElectroTech的翻译文件：原理篇

3.1 tr()、ts与qm三者的关系

Qt应用的本地化工作流可以概括为一条链：开发者在源码中调用tr("Text")标记需要翻译的字符串；lupdate工具扫描源码，把所有这些字符串抽取到一个.ts文件里；翻译人员用Qt Linguist打开.ts文件进行逐条翻译；最后用lrelease工具把.ts编译成.qm文件，程序运行时加载.qm实现界面切换语言。

打个比方，.ts文件是双语对照表，里面每一行记录着英文源文本、中文译文以及这个字符串在源码中的位置；.qm文件则是把对照表压缩成程序能快速读取的“字典”。QElectroTech在运行时按当前系统语言去查找对应的.qm文件，找到就加载，找不到就显示开发时写死的默认语言。

明白了这条链之后，汉化QElectroTech的核心任务就清晰了：获取它的翻译源文件，补齐或修正中文条目，编译成.qm文件，放回正确路径。

3.2 QElectroTech里翻译文件的实际分布

QElectroTech的翻译文件通常叫qelectrotech_zh_CN.ts这样的格式，后缀里“zh_CN”代表简体中文。源码仓库里有一个专门存放翻译文件的目录，不同的发布版本、不同的操作系统安装包，这个路径可能略有差异。Linux下常见位置是在安装目录的share/qelectrotech/translations下面，Windows版本则通常放在安装目录的translations子目录里。

需要特别注意的是，QElectroTech不止一个.ts文件。主程序、元件编辑器、以及其他辅助模块各自可能有独立的翻译文件。动手之前先把自己系统里现有的翻译文件全部列出来，搞清楚每一份对应哪个模块，这一步能省下后续大量的排查时间。

3.3 中文翻译文件缺失时会怎样

当软件找不到中文翻译文件的时候，界面会用源码里默认的语言显示。QElectroTech这个项目由法国开发者发起，很多历史遗留字符串的默认语言其实是法语，所以部分界面会出现既不是英文也不是中文的情况。这也是很多国内用户觉得它界面“乱”的直接原因。另有部分字符串已经带上了基础中文翻译，但质量参差不齐，有些是机翻，有些是术语不统一，同一页面上“端子”和“接线柱”混着出现。这些都需要在汉化过程中逐一修正。

4. 两条汉化路线的取舍：改语言包还是改源码

4.1 方案A：只翻译语言文件，生成补丁

这条路线不碰源码，只处理.ts和.qm文件。适合大多数普通用户，因为操作风险低，也不会破坏软件原有的验证机制。升级版本后，只要新版本字符串没有大改，旧的翻译文件往往还能复用。我个人的判断标准是：只要不需要修改功能逻辑，纯粹是想把界面文字变成中文，方案A足够。

4.2 方案B：修改源码后重新编译

如果目标不只是汉化，还想把界面布局、默认元件库、甚至内置模板都改造成更贴合国内电气设计习惯的版本，那就需要走源码编译路线。比如国内电气图纸的图框格式、标题栏字段和IEC标准符号的命名习惯，与QElectroTech默认提供的模板有明显区别。这些改动光靠翻译文件做不到，必须在源码层面调整。

两个方案的关键差异我整理成了表，方便你对号入座：

实际做下来，我发现绝大多数人需要的是方案A。但方案A有一个隐藏前提——你手里必须有一份覆盖完整的.ts文件。如果官方仓库里的中文翻译本身就不全，或者压根没有中文条目，那就要用lupdate工具从源码重新抽取生成一份新的.ts文件，再从头翻译。这个操作会在后面实操部分详细展开。

5. 手把手汉化实操：从提取翻译文件到生成中文界面

5.1 准备工具链

无论采用方案A还是方案B，Qt Linguist是绕不开的工具。它是Qt官方提供的翻译编辑器，在Qt的安装包中可以找到，也可以单独安装。Linux发行版的软件源里通常直接用包管理器装，Windows环境建议从Qt官方下载对应版本的安装包。版本不一定要追新，能打开项目所用的Qt版本生成的.ts文件就行。

还需要lupdate和lrelease这两个命令行工具。前者负责扫描源码生成.ts文件，后者负责把.ts编译成.qm文件。在Windows上，这两个工具位于Qt安装目录的bin文件夹里，建议把路径加入系统环境变量，后面调用会方便很多。

5.2 获取翻译文件

先确认你手头QElectroTech的安装版本，然后去QElectroTech的官方源码仓库找到对应版本的源码包。如果你只是想补全翻译，直接在源码仓库中查找translations目录，把以zh_CN结尾的.ts文件取出来用。如果你要重新抽取所有可翻译字符串，那就在本地把源码解压，打开命令行进入源码根目录，执行：

lupdate . -recursive -no-obsolete -ts translations/qelectrotech_zh_CN.ts

这个命令会让lupdate扫描当前目录下所有源码文件，把可翻译字符串抽取出来，合并进指定的.ts文件。“-no-obsolete”参数的作用是移除那些在源码中已经不存在但仍然残留在.ts文件里的条目，避免垃圾项越积越多。

第一次执行之后，打开生成的.ts文件，你会发现里面有几百上千条待翻译字符串。看到数量先别慌，其中大量字符串是重复或相近的，很多专业词汇在不同菜单里反复出现，真正需要逐一判断的远没有实际数值那么多。

5.3 用Qt Linguist逐条翻译

用Qt Linguist打开.ts文件，界面分为三栏：左侧是字符串列表，按翻译状态做了颜色区分，灰色未翻译、黄色已翻译、绿色已通过审查；中间顶部是源文本和译文输入框；下方是上下文信息和注释。

翻译时有几个操作原则值得留意：

一是优先把“已完成”数量冲上去。不必第一遍就纠结每个术语的最终译法，先把所有未翻译条目填上。因为很多条目之间存在引用关联，比如某个元件的名称会被另一处说明文字引用，先全部覆盖一遍，后面整体核对时才能看出术语是否一致。

二是利用好Qt Linguist的“短语簿”功能。对于反复出现的专业词汇，比如“terminal（端子）”“conductor（导线）”“drawing（图纸）”，可以先在短语簿里定义好标准译法。后续遇到相同源文本时，Qt Linguist会自动提示可以一键套用，效率提升非常明显。

三是遇到带占位符的字符串要格外小心。Qt里常见类似“Cannot open %1”这种写法，%1是程序运行时动态填入的文件名或路径。翻译成中文时一定要把%1保留在原位，比如译为“无法打开 %1”。占位符丢了，程序轻则显示异常，重则崩溃。这是我踩过的真实坑，检查时务必逐条确认。

5.4 生成qm文件并替换

所有条目翻译完毕后，执行lrelease把.ts生成.qm文件：

lrelease translation_zh_CN.ts -qm qelectrotech_zh_CN.qm

生成后把.qm文件复制到QElectroTech的语言目录。Windows一般是在安装目录下的translations文件夹，Linux通常位于/usr/share/qelectrotech/translations或你编译时指定的安装前缀里。

替换前建议先备份原始文件。QElectroTech的语言选择界面里选中中文，重启软件，此时应该能看到界面已变为中文。如果没变化，优先检查文件名和目录是否严格匹配。QElectroTech对翻译文件的语言代码命名有约定，比如简体中文必须是zh_CN，而不是cn或zh。文件名不对，程序根本不会加载。

5.5 善用“发布翻译”之外的校验手段

Qt Linguist的“验证”功能很多人忽略了，它在“发布翻译”时能自动检查占位符是否缺失、重复，以及某些非文本符号是否被误删。我在处理一份更新较少的.ts文件时偷懒没跑验证，直接lrelease生成qm，结果软件打开后好几处对话框直接退出。后来才定位到是一条包含两个%1的字符串被我译成了只保留一个占位符的版本。这问题从外观上看不出来，非得运行时才能暴露。

所以我的流程固定为：Linguist里逐条翻译→跑一遍验证→回到Linguist修复所有错误和警告→再发布qm。麻烦一点，但稳。

6. 电气领域术语的汉化取舍：这些词不要追求“直译”

6.1 直接从法语习惯延续过来的术语陷阱

QElectroTech由法国团队开发，不少术语带有浓重的法语背景。有一部分界面字符串甚至源码里写的就是法语，而不是英文。比如表示图纸内连接点的词，一些版本里直接用法语的borne，对应的中文应该译为“端子”而不是“边界”或“承载点”。还有表示回路连接线的词，英文写作conductor，法语习惯是conducteur，翻译成“导线”最符合电气从业者的日常表达。

这些词的共同特点是：在通用词典里的含义和电气场景下的专业含义差异很大。如果机械地按字面翻译，产出的中文会非常别扭，甚至误导使用。正确的做法是抛开词典含义，以电气行业约定俗成的术语为准。简单来说，翻译电气软件的判断标准只有一个——“这个中文词会不会让一个电气工程师觉得不对味”。听起来抽象，实际操作中就是个查证过程：拿源词汇到国标电气术语里找对应概念，再结合软件里的实际应用场景定夺。

6.2 一张实用术语对照表

下面是我在汉化过程中整理的常用术语表，不一定绝对权威，但对绝大多数电气图纸场景适用：

其中最需要强调的是“folio”这个词。它在通用英文里表示对开页，但在电气工程图纸软件里，它准确指代一个编号的独立图页。QElectroTech图框里有一个字段就叫“Folio”，很多汉化版本直接漏掉或音译，这是不对的。处理这类专业灰色地带时，我坚持的原则是：凡是电气行业标准中有明确中文术语的，一律用标准术语；标准里没有的，用业内交流中普遍通行的习惯说法；连习惯说法都没有的，则保留英文并在备注中说明。

6.3 同一个英文单词在不同界面的差异化翻译

举个例子，“link”这个词在某些菜单里表示“关联”（比如关联一个元件与它的引脚），在另一些界面却表示“跳转链接”（比如点击后跳到另一张图纸）。如果全项目统一翻译成“链接”，前者语义就会变得非常含混。处理办法是在Qt Linguist里观察字符串的上下文来源，再结合菜单所处位置判断具体语义。

所以术语表只是起点，真正让翻译显得专业的是“一词多译”的判断力。简单说，软件汉化不是词典替换，是在做界面体验设计。一个词语在按钮上怎么呈现、在菜单里怎么呈现、在属性表里怎么呈现，需要符合不同控件形态的操作直觉。这也是为什么我不建议直接套用网上现成的通用软件汉化包的原因——那些包大多不懂电气业务，术语质量堪忧。

7. 不只是界面：把元件库和图框模板也纳入汉化范围

7.1 元件库里的名称和描述文本

QElectroTech的元件库文件扩展名是.elmt，本质上是XML格式的文本文件。每个元件可以包含名称、分类、描述、引脚标签等可显示文本。默认元件库里大量元件的名称和描述都是法文或英文。即使主界面已经中文化，调用库里的交流接触器时，左侧元件列表显示的名称仍然是外文，属性框里引脚的说明文字也让人看不懂。

处理方式有两种。一种是直接在XML文件里把name和description字段改成中文，适合只在自己电脑上使用的情况。另一种是给元件重新分类并建立自己的中文元件库，这种做法适合团队使用，可以彻底摆脱对原始元件库的依赖。建立团队中文元件库时要注意，元件XML里的英文字段名不能改，那是软件读取数据的键值，改的是标签里包裹的显示文本。

7.2 图框和标题栏模板的修改

电气图纸必须带图框和标题栏，QElectroTech允许用户自定义图框模板。模板文件是XML格式，里面的公司名称、图纸名称、设计人、审核人这些字段的标题文字需要改成中文，日期格式也需要调整为国内习惯的“年月日”顺序。很多用户汉化完界面后出一张图纸，右下角的标题栏仍然是英文，这基本等于没汉化。

修改模板时建议先复制原始模板，重命名为中文模板，再编辑字段内容。保留原始模板的好处是方便随时对照和回退。QElectroTech的模板目录里还有一个比较隐蔽的字段——图层设置。图层的名称如“给排水”“动力”“通讯”等，虽然影响的是图层分类的显示，但直接决定一套图纸的专业观感，我在初期汉化中差点漏掉。

7.3 图纸项目本身的命名规范

这一点很多人没意识到：软件汉化之后，新建工程时默认生成的图纸名、图层名、以及分类名仍然是硬编码的。这些是在源码级别写死的默认值，单纯替换语言文件无法改变。想要默认生成的就是中文名称，只能修改源码中的默认字符串并重新编译，或者通过新建工程后手动重命名的变通方式解决。如果你走方案A的汉化路线，需要接受这个局限。

8. 汉化补丁的打包与分发：让别人也能用上

8.1 补丁的常见形式

汉化打包最基本的形式就是直接分发.qm文件，配合使用说明告诉用户应该放在哪个目录。这种形式最简单，但也有个严重问题——不同版本之间翻译格式可能不兼容，高版本编译的.qm放到低版本里，可能加载不上或造成乱码。所以分发补丁时一定要标注清楚适配的版本号。

稍微进阶一些的做法是同时提供.ts文件和使用说明。用户安装了包含对应字符串的新版本后，可以自己用lrelease重新编译一份新的.qm。这样补丁就具备了跨小版本适配的能力，因为即便若干新增字符串未翻译，软件也会通过回退机制显示默认语言，不至于直接失效。

8.2 增量补丁还是全量安装包

对普通分发场景，我建议用增量补丁，理由很简单：QElectroTech的官方源码仓库会持续更新，如果每次更新都让用户重新下载整个汉化安装包，维护成本太高，而且下载慢的镜像还会劝退用户。增量补丁由两个文件组成，一个是说明文档，一个是.qm文件。用户只要覆盖原目录同名文件，五分钟内就能完成汉化。

但也要提醒一句，QElectroTech升级版本后，部分界面新增了带新原文的字符串，旧汉化包无法覆盖新功能界面的显示。这属于正常现象，不用惊慌，等空下来重新拉取新版本的.ts文件补翻即可。

8.3 Windows与Linux的路径差异

Windows安装版的语言文件在安装目录的translations子目录下，绿色免安装版则跟随解压包路径变化。Linux下需要注意，如果QElectroTech是发行版仓库里安装的，语言文件位置在/usr/share目录下，普通用户没有写入权限，需要加sudo执行替换。不少Linux用户在汉化时卡在这里，以为补丁无效，实际只是文件没拷进去。

另外Flathub或Snap商店渠道安装的QElectroTech则藏得更深，它们在只读的沙盒目录里挂载应用文件，直接改起来非常麻烦。这种情况下建议改用系统原生包，或直接下载官方提供的AppImage压缩包解压后替换，路径更可控。

9. 汉化之后的版本跟进与开源回馈

9.1 版本升级的常用操作节奏

我给自己定了一个版本跟进的固定流程：每次QElectroTech发布新版本后先做翻译状态对比，用lupdate重新抽取最新源码中的字符串，和上一版翻译文件合并；打开Qt Linguist看新增了几条待翻译项；若新增数量很少便当场补齐并发布新补丁；若新增量很大，则先发布一个对应旧版qm文件保留可用性的说明，等全部翻完再发正式包。

这个流程最大的好处在于不让汉化工作形成历史债务。越晚处理新版本字符串，积累的未翻译文案越多，一次补齐的压力越大。间隔版本太久的话，有可能出现源码重构导致大量字符串上下文变化，旧翻译文件里大批条目被标记为obsolete，对比排查起来非常痛苦。

9.2 把汉化成果贡献给项目本身

既然软件本身是开源的，最理想的状态其实是把中文翻译直接提交到上游官方仓库，让所有中文用户都能受益。QElectroTech社区对翻译贡献普遍持欢迎态度，官方维护者会审核翻译文件并合并进主线。提交方式一般是先到官方代码托管平台获取仓库地址，在本地建立与上游仓库相同的分支结构，修改.ts文件后发起合并请求。提交前要确认.ts文件的语言标签与翻译状态元数据一致，并且没有任何验证错误，否则很容易被维护者打回。

我在整个汉化过程中最大的感受是：本地化工作远比想象中需要耐心，但一旦完成，后续版本跟进反而越来越轻松。QElectroTech这款开源电气软件的底子很好，功能逻辑扎实，跨平台表现稳定，它缺的只是让中文电气工程师顺手的那层语言外壳。花一个周末把界面、术语、元件库和模板梳理一遍，换来的长期使用体验提升是非常划算的。如果你已经开始动手了，记住先把术语表定下来再逐条翻，这个顺序能让你少走一半弯路。