1. 项目概述：Unity游戏翻译的痛点与XUnity Auto Translator的诞生
如果你玩过一些由独立开发者或小型工作室制作的Unity游戏，尤其是那些最初只有日文或英文版本的作品，大概率遇到过“啃生肉”的尴尬。游戏里的剧情、道具说明、技能描述全是看不懂的外语，查词典、截图翻译、切屏查攻略……一套操作下来，游戏的沉浸感早已荡然无存。对于Mod社区和汉化组来说，传统的游戏汉化更是一项浩大工程：需要反编译游戏资源、定位文本、翻译、重新打包，不仅技术门槛高，还极易因游戏版本更新而失效。
XUnity Auto Translator（后文简称XUAT）的出现，正是为了解决这个核心痛点。它不是一个简单的文本替换工具，而是一个运行在游戏进程内的、高度智能化的实时翻译插件。其核心思路是“拦截与替换”：在游戏运行时，动态拦截Unity引擎渲染到屏幕上的每一个文本字符串，将其发送到配置好的翻译服务（如谷歌翻译、百度翻译等）进行翻译，然后用翻译结果替换掉原始文本，实时呈现在游戏界面上。这意味着，玩家无需等待完整的汉化补丁，在游戏发布的第一时间就能通过机器翻译获得一个“可玩”的版本；对于汉化者，它则提供了一个强大的框架，可以方便地导入和修正机器翻译的结果，逐步打磨出高质量的本地化版本。
从技术角度看，XUAT的厉害之处在于它深入到了Unity的渲染管线。它通过Harmony或MonoMod这样的代码注入（Hook）技术，挂钩了Unity中用于显示文本的核心组件，如Text（UGUI）、TextMeshPro（TMP）以及传统的GUIText。当这些组件的text属性被设置时，插件会先检查自己的翻译缓存（一个由原文到译文的映射字典）。如果缓存命中，则直接返回译文；如果未命中，则发起一次翻译请求，将结果存入缓存并显示。整个过程对游戏本身是透明的，游戏逻辑依然操作着原始文本，但玩家看到的是翻译后的内容。
2. 核心架构与工作原理解析
2.1 核心工作流程：从文本拦截到屏幕渲染
要理解XUAT，必须厘清它从捕获文本到最终显示的全链路。这个过程可以概括为“拦截-查询-替换-渲染”四步。
第一步：文本拦截（Hook）这是所有功能的基石。XUAT会在游戏启动时，将其自身的代码注入到Unity引擎的关键函数中。具体来说，它会挂钩诸如Text.set_text(string value)、TextMeshPro.SetText(string text)等方法。无论游戏代码在何处、以何种方式设置这些UI元素的文本，执行流都会先经过XUAT的代码。插件会拿到游戏试图设置的原始字符串（比如“新しいアイテムを入手しました！”）。
第二步：翻译查询与缓存拿到原始字符串后，插件首先对其进行“标准化”处理，包括去除首尾空白字符、处理内部换行符等，目的是将不同上下文中可能出现的同一句文本（比如对话正文和历史记录里的同一句话，后者可能多了换行）归一化，以提升缓存命中率。接着，插件在一个高效的字典数据结构中进行查找。这个字典的内容来自两个地方：
- 自动生成文件(
_AutoGeneratedTranslations.txt)：由插件在之前的游戏过程中，通过调用在线翻译API自动生成并保存的。 - 手动翻译文件：用户或汉化组创建的
.txt文件，包含精心校对过的翻译。
如果字典中存在该原文的条目，则直接进入第四步。如果不存在，插件会判断该文本是否“可翻译”（例如，是否过短、是否为纯数字、是否在忽略列表中）。如果可翻译，则将其加入一个待翻译队列。
第三步：异步翻译调度XUAT维护着一个翻译任务队列。为了避免频繁请求导致API限制或游戏卡顿，插件会进行批处理（Batching），将多个短句合并为一个请求发送。它支持多种后端，从免费的谷歌、百度翻译到需要API密钥的DeepL、彩云小译等。翻译请求通常在后台线程或协程中异步进行，完成后将“原文-译文”对写入自动生成文件并更新内存中的字典。
第四步：文本替换与UI适配获得译文后，并非简单地textComponent.text = translatedText就完事了。这里涉及两个关键问题：
- 字体支持：如果翻译成中文、韩文等非拉丁字符，游戏自带的字体可能不包含这些字形，导致显示为方框（□□□）。XUAT提供了字体覆盖（
OverrideFont）和回退字体（FallbackFontTextMeshPro）功能，允许用户指定一个包含目标语言字形的字体文件或系统字体来替换。 - UI布局破坏：译文长度通常与原文不同，可能导致文本超出文本框、按钮变形等。XUAT内置了基础的UI自动重设大小功能（
EnableUIResizing），可以调整文本框的HorizontalOverflow、VerticalOverflow等属性。对于更复杂的情况，用户可以通过编写resizer.txt配置文件，针对特定的UI组件路径精确控制字体大小、行间距等。
整个流程对游戏性能的影响被控制在极低的水平。翻译缓存机制确保了同一句文本只翻译一次，后续直接读取内存，速度极快。只有在遇到新文本时，才会产生一次网络请求的延迟。
2.2 核心模块拆解：插件、资源重定向与扩展性
XUAT并非一个单一模块，而是一个由多个协同工作的部分组成的生态系统。
1. 自动翻译插件核心 (XUnity.AutoTranslator)这是主模块，负责上述的文本拦截、翻译、替换逻辑。它的配置文件（Config.ini）是控制其行为的“大脑”，涵盖了从选择翻译引擎（Endpoint）、设置语言对（SourceLanguage/DestinationLanguage），到调整空白字符处理、正则表达式匹配等所有细节。
2. 资源重定向器 (XUnity.ResourceRedirector)这是一个独立且强大的库，它赋予了XUAT超越文本翻译的能力。它的作用是拦截Unity从Resources文件夹或AssetBundle中加载资源的调用（如图片、音频、文本资产等），并重定向到用户指定的替代文件。
- 对于翻译的用途：许多游戏中的文字并非动态生成的UI文本，而是直接做在图片里的（比如技能图标上的文字、标题Logo）。纯文本翻译插件对此无能为力。资源重定向器可以拦截图片加载请求，如果发现在指定的
TextureDirectory目录下有同名（或同哈希值）的已翻译图片，就会用这张图片替换游戏原本要加载的那张。这就实现了“图片内文字”的汉化。 - 工作模式：它支持两种资源替换策略。一种是基于资源名（
FromImageName），速度快但依赖游戏资源有唯一名称；另一种是基于图像数据哈希（FromImageData），更准确但性能开销稍大。汉化组可以先用插件的“导出”功能将游戏内所有图片资源导出，然后用PS等工具修改其中的文字，再放回指定目录，即可实现无缝替换。
3. 可扩展的翻译端点 (Translators)XUAT的核心翻译逻辑是抽象为ITranslateEndpoint接口的。这意味着开发者可以轻松地为它添加新的翻译源。项目源码中已经提供了谷歌、百度、DeepL等十几种实现的范例。如果你有一个私有的翻译API或想集成某个新兴的AI翻译服务，只需要参照范例实现几个关键方法（初始化、创建请求、解析响应），编译成DLL放入Translators文件夹，插件启动时就会自动识别并加载，出现在配置选项里。这种设计让插件永远不会过时，总能跟上翻译服务的发展。
4. 对Mod开发者的友好接口XUAT考虑到了与其他Mod的共存。它为Mod开发者提供了明确的API，让其他Mod可以查询当前的翻译结果（AutoTranslator.Default.TranslateAsync），或者主动告知XUAT“不要翻译我的UI”（通过在GameObject名称中包含XUAIGNORE标签，或在IMGUI代码中调用DisableAutoTranslator方法）。这种设计避免了Mod之间的冲突，营造了健康的社区生态。
3. 实战部署：从零开始配置你的游戏翻译
理论说得再多，不如动手一试。下面我将以一款典型的日文Unity游戏为例，演示如何使用BepInEx插件框架来部署和配置XUAT。
3.1 环境准备与插件安装
第一步：确认游戏环境首先，你需要确定你的Unity游戏是否支持Mod。目前绝大多数使用Mono后端（而非IL2CPP）的Unity游戏都可以通过BepInEx来加载插件。你可以查看游戏根目录下是否存在GameName_Data/Managed/Assembly-CSharp.dll文件，这是Mono游戏的典型特征。IL2CPP游戏（通常性能更强，反编译更难）也能得到部分支持，但可能需要额外的辅助插件（如AutoTranslator.IL2CPP.BruteForceFix）且功能可能受限。
第二步：安装BepInEx
- 前往BepInEx的GitHub发布页，下载对应你游戏位数（通常是x86）的
BepInEx_x64_5.4.xx.x.zip或BepInEx_x86_5.4.xx.x.zip。 - 将压缩包内的所有文件解压到你的游戏根目录（即
GameName.exe所在的文件夹）。 - 运行一次游戏。如果安装成功，游戏目录下会生成
BepInEx文件夹，里面包含plugins、config等子目录。首次运行后关闭游戏。
第三步：安装XUnity Auto Translator
- 前往XUAT的GitHub发布页，下载
XUnity.AutoTranslator-BepInEx-5.x-{VERSION}.zip。务必选择BepInEx 5.x版本，这是与当前BepInEx框架兼容的。 - 将压缩包内的
BepInEx文件夹整体解压到游戏根目录，选择合并所有文件和文件夹。 - 安装完成后的典型目录结构应如下所示：
YourGame/ ├── GameName.exe ├── BepInEx/ │ ├── core/ # BepInEx核心 │ ├── plugins/ # 插件目录 │ │ └── XUnity.AutoTranslator/ # XUAT主插件 │ │ ├── AutoTranslatorConfig.ini │ │ ├── translation/ │ │ │ ├── en/ # 英文翻译文件（示例） │ │ │ └── zh-CN/ # 中文翻译文件（目标目录） │ ├── patchers/ # （可能为空） │ └── config/ # 插件配置文件 └── GameName_Data/
### 3.2 关键配置详解：让翻译引擎高效工作 安装后，首次运行游戏会在`BepInEx/config`目录下生成`AutoTranslatorConfig.ini`。这个文件是控制插件的核心，我们打开它进行关键设置。 **基础设置 (`[General]` 部分)**[General] Language=zh-CN # 目标语言，简体中文 SourceLanguage=ja # 源语言，根据游戏选择，如ja(日文)，en(英文) Endpoint=GoogleTranslate # 翻译引擎，初期推荐GoogleTranslate（免费，无需密钥）
* `Language`和`SourceLanguage`必须正确设置，否则翻译方向会错乱。插件支持的语言代码遵循ISO标准。 * `Endpoint`是你选择的翻译服务。对于初次使用，`GoogleTranslate`（谷歌网页翻译）是最方便的选择，它不需要API密钥，但有访问频率限制且可能不稳定。如果你有稳定的网络环境，这是最佳起步选择。 **翻译服务配置** 根据你选择的`Endpoint`，需要配置对应的区块。例如选择`GoogleTranslate`，则无需额外配置。但如果选择需要认证的服务，如百度翻译：[Baidu] BaiduAppId=你的App ID BaiduAppSecret=你的密钥
> **注意**：**绝对不要**在公开发布的翻译补丁包中包含你的个人API密钥！这会导致密钥泄露和产生巨额费用。分发补丁时，应让用户自行申请和填写密钥。 **行为优化 (`[Behaviour]` 部分)**[Behaviour] EnableTranslationScoping=True # 启用翻译范围限定，提升性能 EnableBatching=True # 启用请求批处理，将多个短句合并为一个请求发送 MaxCharactersPerTranslation=400 # 单次翻译最大字符数，防止过长文本 EnableUIResizing=True # 启用UI自动重设大小，防止译文溢出
* `EnableBatching`强烈建议开启，它能大幅减少向翻译API发起的请求次数。 * `MaxCharactersPerTranslation`默认是400，这是为了遵守大多数免费翻译API的条款。**如果你要打包分发你的翻译配置，务必确保此值不超过400**，否则可能被视为滥用。 * `EnableUIResizing`对于中文等宽字符语言非常有用，可以自动调整文本框属性以适应更长的译文。 **文件与目录 (`[Files]` 部分)**[Files] Directory=Translation{Lang}\Text OutputFile=Translation{Lang}\Text_AutoGeneratedTranslations.txt SubstitutionFile=Translation{Lang}\Text_Substitutions.txt
这部分定义了翻译文件的存储路径。`{Lang}`是占位符，会自动替换为`Language`配置的值（如`zh-CN`）。所有手动翻译的`.txt`文件都应放在`Translation\zh-CN\Text\`目录下（除了以`_`开头的自动生成文件）。`_Substitutions.txt`用于定义替换规则，比如将翻译引擎经常翻错的专有名词（人名、技能名）直接固定下来。 ### 3.3 首次运行与热键操作 配置完成后，启动游戏。如果一切正常，游戏窗口左上角或左下角会出现一行小字提示“XUnity Auto Translator initialized”。当你遇到游戏内的文本时，可能会观察到短暂的停顿（正在联网翻译），随后文本就会被替换成中文。 XUAT提供了几个非常重要的热键，你需要牢记： * **ALT+0**：打开翻译端点选择窗口。你可以在这里快速切换不同的翻译服务（如从谷歌切换到百度），或者选择“（空）”来完全禁用自动翻译。 * **ALT+T**：全局翻译开关。按一下，所有翻译文本会变回原文；再按一下，恢复翻译。这是快速检查翻译效果或截图原文的利器。 * **ALT+R**：重新加载所有翻译文件。当你手动修改了`Translation`目录下的任何`.txt`文件后，无需重启游戏，按此热键即可立即生效。 * **CTRL+ALT+NP7**：在控制台输出当前加载的场景ID等信息，用于高级的翻译范围限定（Scoping）调试。 游戏过程中，所有首次翻译的文本都会自动记录到`Translation\zh-CN\Text\_AutoGeneratedTranslations.txt`文件中。这个文件就是你的翻译缓存和后续手动校对的起点。 ## 4. 高级技巧与深度定制：从机器翻译到精校汉化 仅仅使用机器翻译是远远不够的。机器翻译在文学性、专有名词、游戏术语上经常出错。XUAT的强大之处在于它提供了一整套工具，让玩家和汉化者能够轻松地从“机翻”过渡到“精翻”。 ### 4.1 手动翻译与词条管理 机器翻译生成的`_AutoGeneratedTranslations.txt`文件格式很简单，每行一条，原文和译文用等号连接：新しいアイテムを入手しました！=你得到了一个新项目！ 魔王が現れた！=魔鬼出现了！
你可以直接用文本编辑器打开这个文件进行修改。比如把生硬的“你得到了一个新项目！”改成更符合游戏语境的“获得了新道具！”，把“魔鬼出现了！”改成“魔王现身了！”。保存后，在游戏中按**ALT+R**重载，修改立即生效。 **高效管理大量词条：** 1. **分离文件**：不要把所有翻译都堆在`_AutoGeneratedTranslations.txt`里。你可以创建新的`.txt`文件，例如`Items.txt`（道具）、`Skills.txt`（技能）、`Dialogue_Chapter1.txt`（第一章对话）。插件会读取`Translation\{Lang}\Text\`目录下**所有**`.txt`文件。手动创建的文件优先级高于自动生成的文件。如果同一原文在不同文件中有不同译文，以手动文件中的为准。 2. **使用正则表达式**：对于有规律的文本，比如道具名“`ポーション(小)`”、“`ポーション(中)`”、“`ポーション(大)`”，你可以写一条正则规则来统一处理： ``` r:"^ポーション\((.+?)\)$"=药剂($1) ``` 这条规则会把所有“ポーション(XXX)”匹配并替换为“药剂(XXX)”，无需为每个等级单独写一条。 3. **使用拆分器正则表达式 (sr:)**：对于游戏将多个独立文本拼接后显示的情况，比如“`01 シンプルリング`”（01 简单戒指），如果直接翻译“シンプルリング”这个词，但游戏里出现的都是带编号的“01 シンプルリング”，翻译就会失效。这时可以用拆分器： ``` sr:"^([0-9]{2}) ([\S\s]+)$"=$1 $2 ``` 这条规则会先将文本拆分成“01”和“シンプルリング”两部分，然后分别去翻译词典里查找“シンプルリング”的翻译，最后再组合成“01 Simple Ring”。 ### 4.2 字体替换：解决乱码与美化显示 机器翻译成中文后，最大的视觉障碍就是“口口口”乱码。这是因为游戏自带的字体不包含中文字形。 **解决方案：替换字体** 1. **寻找字体文件**：你需要一个包含目标语言字符集的`.ttf`或`.otf`字体文件，比如“思源黑体”、“方正准圆”等。注意版权，确保可用于分发。 2. **创建TextMeshPro字体资产**：大多数现代Unity游戏使用TextMeshPro（TMP）显示文本。TMP需要使用特殊的`.asset`字体资产。你需要使用与游戏相同版本的Unity Editor（可以通过查看游戏目录下`UnityPlayer.dll`的属性获取版本）来创建这个资产。 * 在Unity中新建一个项目，导入TextMeshPro包。 * 将你的`.ttf`字体文件拖入项目。 * 在TMP的Font Asset Creator中，选择该字体，生成SDF Font Asset（`.asset`文件）。 3. **让XUAT使用新字体**：将生成的`.asset`文件（以及可能相关的材质和纹理图集）放入游戏根目录。在`AutoTranslatorConfig.ini`中配置： ``` [Font] OverrideFontTextMeshPro=Fonts & Materials/YourFontName SDF ``` `YourFontName SDF`就是你创建的字体资产在Resources路径下的名字。如果直接放在根目录，可能需要打包成AssetBundle，过程较为复杂。社区通常有分享制作好的通用字体AssetBundle，可以搜索“XUnity Auto Translator 字体”寻找资源。 **更优雅的方案：回退字体** 如果你不想替换所有字体，只想让TMP在遇到缺失字符时使用中文字体，可以配置回退字体：[Font] FallbackFontTextMeshPro=Fonts & Materials/YourChineseFont SDF
这样，游戏原有字体依然负责显示英文和数字，遇到中文时则自动切换到回退字体，视觉上更协调。 ### 4.3 资源重定向：汉化图片与界面元素 对于游戏Logo、带文字的按钮图标、技能图标等“图片文字”，文本翻译无能为力。这时就需要用到资源重定向功能。 **步骤一：导出游戏内图片** 1. 在`AutoTranslatorConfig.ini`中启用纹理导出： ``` [Texture] EnableTextureTranslation=True EnableTextureDumping=True TextureDirectory=Translation\Texture TextureHashGenerationStrategy=FromImageName ``` 2. 启动游戏，遍历所有场景（主菜单、各个关卡、界面）。插件会将游戏加载到的所有纹理图片导出到`Translation\Texture`目录下，文件名类似`button_ok [ABCD1234-EF567890].png`。哈希值`[ABCD1234-EF567890]`用于唯一标识这张图片。 **步骤二：修改图片** 用Photoshop、GIMP等工具打开导出的图片，将其中的外文修改为中文。**保存时务必保留原文件名和哈希值部分**，这是插件识别和替换的关键。 **步骤三：放回并启用** 将修改好的图片放回`Translation\Texture`目录（或子目录）。确保配置中`EnableTextureTranslation=True`。重启游戏，修改后的图片就应该替换掉原来的了。 > **重要警告**：`EnableTextureDumping`（导出）和`LoadUnmodifiedTextures`（加载未修改的纹理）**绝不要**在公开发布的整合包中启用！前者会导致用户游戏目录被大量图片塞满，后者会导致游戏加载所有导出的图片（包括未修改的），严重增加内存和加载时间。分发时只应包含你真正修改过的图片文件。 ### 4.4 翻译范围限定与性能优化 当游戏内容庞大时，全场景的文本Hook和翻译查询可能带来性能开销。XUAT提供了“翻译范围限定”功能来优化。 **基于场景ID限定：** 在手动翻译文件中，你可以使用指令来限定某些翻译只在特定场景生效：#set level 5,10,15 魔王の間=Throne Room 勇者の剣=Hero's Sword #unset level
`#set level 5,10,15`表示接下来的翻译只会在场景ID为5、10、15时生效。你可以按**CTRL+ALT+NP7**在游戏内查看当前场景ID。这常用于避免不同场景中同名但意义不同的文本产生翻译冲突。 **基于可执行文件限定：** 如果你为同一个游戏的多个版本（如试玩版、正式版）制作翻译，可以按exe文件名区分：#set exe GameDemo.exe ようこそ=Welcome to Demo #unset exe #set exe GameFull.exe ようこそ=Welcome to the Full Version
这样，同一个“ようこそ”文本，在两个版本的游戏里会显示不同的翻译。 在配置文件中启用此功能：`[Behaviour] EnableTranslationScoping=True`。合理使用范围限定，可以大幅减少插件需要维护和查询的翻译字典大小，提升游戏运行时的性能。 ## 5. 疑难杂症排查与开发者指南 即使配置正确，在实际使用中也可能遇到各种问题。下面是一些常见问题的排查思路和解决方法。 ### 5.1 常见问题速查表 | 问题现象 | 可能原因 | 解决方案 | | :--- | :--- | :--- | | **游戏启动崩溃或报错** | BepInEx或XUAT版本与游戏不兼容；游戏为IL2CPP架构但未使用专用修复插件。 | 1. 确认游戏是Mono架构。2. 尝试BepInEx的`winhttp.dll`注入方式。3. 对于IL2CPP游戏，尝试`AutoTranslator.IL2CPP.BruteForceFix`插件。 | | **游戏文字无任何变化** | 插件未成功加载；翻译引擎配置错误或无法连接；源/目标语言设置反了。 | 1. 查看游戏根目录下`BepInEx/LogOutput.log`，检查插件加载日志。2. 按ALT+0确认已选择翻译端点且非空。3. 检查`SourceLanguage`和`Language`是否正确。4. 尝试切换为`GoogleTranslate`（免费版）测试。 | | **部分文字翻译了，部分没有** | 文本可能来自非标准UI组件（如自定义Shader、图片）；文本是动态拼接的；文本过短被忽略。 | 1. 尝试开启`EnableTextureTranslation`查看是否为图片文字。2. 检查`MaxCharactersPerTranslation`是否设得太小。3. 在配置中调低`MinDialogueChars`（最小对话字符数）试试。 | | **翻译后UI布局错乱，文字溢出** | 译文长度远超原文，文本框自适应失败。 | 1. 确保`[Behaviour] EnableUIResizing=True`。2. 对于特定UI，编写`resizer.txt`配置文件，精确调整字体大小或行间距。3. 考虑优化翻译，使其更简洁。 | | **翻译结果显示为方框（□□□）** | 游戏字体不支持目标语言字符（如中文）。 | 1. 配置`OverrideFontTextMeshPro`或`FallbackFontTextMeshPro`，指定一个包含目标字符集的字体。2. 确保字体文件路径正确且格式兼容。 | | **按ALT+T切换翻译无效** | 热键被游戏或其他软件占用；插件Hook的组件不支持切换。 | 1. 尝试在游戏窗口激活时按热键。2. 检查游戏是否使用非常规的文本渲染方式。3. 对于纹理翻译，需要单独开启`EnableTextureToggling`（且不保证有效）。 | | **自动生成文件`_AutoGeneratedTranslations.txt`为空或不更新** | 游戏文本未被成功Hook；所有文本都已存在于手动翻译文件中（优先级更高）。 | 1. 按ALT+0打开窗口，确认翻译服务状态正常。2. 删除或重命名所有手动翻译文件，看自动生成文件是否开始记录。3. 检查配置中`OutputFile`路径是否正确。 | | **使用百度/DeepL等API翻译失败** | API密钥错误或余额不足；网络连接问题；服务端限制。 | 1. 在配置文件中仔细核对AppId和Secret/API Key。2. 前往对应翻译服务官网控制台，确认服务已启用、有余量。3. 尝试在浏览器中手动调用该API接口，验证密钥有效性。 | ### 5.2 为Mod开发者：如何与XUAT和谐共处 如果你是一名Unity游戏的Mod开发者，你的Mod界面很可能也会被XUAT翻译。大多数情况下这是好事，但有时你可能希望保持原样，或者主动提供翻译。 **阻止XUAT翻译你的Mod UI：** * **对于UGUI/TextMeshPro**：最简单的方法是将包含`Text`或`TextMeshProUGUI`组件的GameObject命名为“`XUAIGNORE`”。插件在初始化时会检查这个名字并忽略该组件。如果你想忽略整个UI子树，可以命名为“`XUAIGNORETREE`”。 * **对于IMGUI（OnGUI方法）**：需要在你的`OnGUI`方法中，在绘制代码前后包裹禁用/启用翻译的调用： ```csharp void OnGUI() { // 查找XUAT的GameObject（只需一次） if(_xuaObject == null) { _xuaObject = GameObject.Find("___XUnityAutoTranslator"); } try { _xuaObject?.SendMessage("DisableAutoTranslator"); // 你的IMGUI绘制代码在这里 GUILayout.Label("My Mod Menu"); } finally { _xuaObject?.SendMessage("EnableAutoTranslator"); } } ``` 使用`try...finally`确保即使你的代码抛出异常，翻译功能也能被重新启用。 **为你的Mod提供专属翻译：** 你可以在`Translation\{Lang}\Text\Plugins\`目录下，创建一个以你的Mod的DLL命名的文件夹（不含`.dll`扩展名）。在这个文件夹里放置你的Mod的翻译文件。你甚至可以在翻译文件中加入`#enable fallback`指令，允许在找不到专属翻译时，回退到通用的自动翻译。 **以编程方式与XUAT交互：** XUAT提供了API供其他Mod调用。你可以在Mod初始化时（如`Start`方法中）查询翻译： ```csharp using XUnity.AutoTranslator.Plugin.Core; // ... string originalText = "Get Item!"; if(AutoTranslator.Default.TryTranslate(originalText, out string translatedText)) { // 使用翻译后的文本 Debug.Log(translatedText); } else { // 没有缓存，可以发起异步翻译请求 AutoTranslator.Default.TranslateAsync(originalText, (result) => { if(result.Succeeded) { Debug.Log(result.TranslatedText); } }); }这允许你的Mod动态获取游戏内其他文本的翻译，或者为你自己生成的文本提供翻译支持。
5.3 性能调优与配置陷阱
对于大型游戏或配置较低的电脑，不当的配置可能导致卡顿或内存占用过高。
内存与CPU优化：
- 关闭纹理缓存：如果你不使用图片翻译功能，确保
[Texture] CacheTexturesInMemory=False。如果使用，但内存紧张，也可以关闭，代价是图片加载可能变慢。 - 谨慎使用正则表达式：翻译文件中的正则表达式（尤其是
r:和sr:）虽然强大，但执行有成本。避免编写过于复杂或模糊的正则，并尽量通过#set level限定其作用范围。 - 限制翻译长度：
MaxCharactersPerTranslation不要设置过高，400是一个安全值。超长的文本（如整本书）可能不适合实时翻译，应考虑手动翻译。 - 禁用不必要的日志：在最终使用时，确保
[Debug] EnableConsole=False和EnableLog=False。调试时再开启。
配置中的“陷阱”：
EnableTextureScanOnSceneLoad：在场景加载时扫描所有纹理，能发现更多可替换图片，但会增加场景加载时间。仅在制作汉化补丁需要导出全部图片时开启，日常使用建议关闭。DetectDuplicateTextureNames：自动检测重复纹理名。切勿在分发版中启用，因为它会写配置文件，且对普通用户无意义。OutputUntranslatableText：将插件认为不可翻译的文本（如单个字符、乱码）也输出到文件。切勿在分发版中启用，这会产生大量垃圾数据。TextGetterCompatibilityMode：如果开启翻译后游戏逻辑出现错误（比如某个选项无法点击），尝试将此设为True。这会欺骗游戏，让它认为显示的仍是原文。
经过以上从原理到实战，从配置到排错的全面解析，你应该已经对XUnity Auto Translator这个强大的工具有了深入的理解。它不仅仅是一个“翻译插件”，更是一个完整的游戏本地化运行时框架。无论是想无障碍体验外语游戏的普通玩家，还是致力于制作高质量汉化补丁的爱好者，亦或是希望自己的Mod能更好融入多语言环境的开发者，XUAT都提供了近乎完美的解决方案。其背后的设计思想——非侵入式的运行时Hook、高度可配置的管道、对社区扩展的开放——也值得所有软件开发者学习。剩下的，就是启动游戏，去探索那些曾经因为语言障碍而错过的精彩世界了。
