本地化详解

本地化负责把数据库和脚本中的技术标识转换成玩家真正看到的文字。兵种名称、建筑说明、部队技能、法术、物品、事件文本等内容可能属于不同系统，但只要它们通过 Loc 显示，核心关系都是“某个系统需要哪条 Loc Key，Loc 文件再为这条 Key 提供文字”。

这篇教程主要解决三类需求：

1. 为自己新建的单位、建筑、技能等内容补上中文名称与说明。
2. 修改原版或其他 Mod 已有内容的显示文字。
3. 使用 RPFM 检查缺失文本，并处理需要批量翻译的 Loc。

先理解本地化链路

游戏显示一段文字时，通常不是直接读取 DB 表中的中文，而是经过下面的连接：

DB 记录或脚本
    ↓ 通过记录 Key、文本 Key 或本地化字段确定目标
Loc Key
    ↓ 在 Loc 文件中查找完全相同的 Key
Text
    ↓
游戏界面显示的文字

以陆战单位名称为例：

land_units_tables.Key
wh3_main_cth_inf_jade_warriors_0

对应 Loc Key
land_units_onscreen_name_wh3_main_cth_inf_jade_warriors_0

对应 Text
玉勇

DB 中的wh3_main_cth_inf_jade_warriors_0仍然是单位的技术标识，Loc 只是告诉游戏应该把这个单位名称显示成“玉勇”。改Text不会改变单位引用；改了单位 Key，则必须同步准备与新 Key 对应的 Loc Key。

Loc Key、DB Key 和游戏显示文字是三种不同的东西。不要把中文名称填进 DB Key，也不要把一条看起来相似的 Loc Key 当作任意内容都能使用的通用文本槽位。

Loc 文件的三列

《战锤 III》的中文原版文本集中在local_cn.pack中的 Loc 文件里。图中筛选出了玉勇的名称条目，橙框依次标出原版 Loc 文件、Key和对应的中文Text。

Loc 的结构固定为三列，不依赖 DB Schema：

列	作用	编写要点
Key	唯一标识这条文本，供 DB、界面或脚本查找。	必须与系统期待的 Key 完全一致；复制时不要改大小写、空格或下划线。
Text	玩家实际看到的文字。	可以填写中文，也可能包含换行、颜色、图标和数值占位符。
Tooltip	Loc 格式自带的布尔列。	RPFM 源码也把它标为用途未知；它不等于“勾选后自动变成提示框”。普通条目按原版模板处理，没有依据时保持默认不勾选。

一条 Loc 记录只提供一段文字。它不会自动创建单位、赋予技能、产生效果，也不会决定文字出现在哪个界面；实际显示位置仍由引用这条 Key 的 DB、UI 或脚本决定。

不要把原版 Loc 整个导入 Mod

原版local_cn.pack中的text/localisation__.loc包含大量游戏文本，它适合查询，不适合整份复制进自己的 Pack。这样做会带来几个问题：

• Pack 体积无故增大；
• 内部路径与原版文件重复，可能变成整文件覆盖；
• 以后游戏更新了原文，你的旧副本仍可能压住新内容；
• 很难看出 Mod 真正修改了哪些文字；
• 其他本地化 Mod 更容易与它发生冲突。

正确做法是给自己的 Mod 建立一个独立 Loc，例如：

text/twcn_tutorial.loc

Loc 文件名只用于区分 Pack 内的文件，不决定游戏里显示什么；真正建立连接的是每一行的Key。文件名应带自己的作者或 Mod 前缀，避免与其他 Mod 使用相同路径。

创建 Loc 文件

1. 打开正在制作的 Mod Pack。
2. 在左侧Pack 内容中右键自己的 Pack 或目标文件夹。
3. 点击创建 → 创建 Loc 文本，也可以使用界面显示的快捷键Ctrl+L。

4. 输入完整的 Pack 内部路径，例如：

text/twcn_tutorial.loc

5. 点击确定，展开text文件夹并打开新建的 Loc。
6. 在空白表格中右键，点击添加行。
7. 分别填写Key与Text；Tooltip没有明确模板依据时保持不勾选。

图中的单位只是演示写法，不是要求所有 Mod 都以twcn_tutorial开头。请把前缀换成自己的稳定标识，并保证同一项目始终使用相同规则。

Loc Key 不能靠中文直译

Loc Key 是技术标识，不是英文名称。它通常由下面几部分组成：

表名去掉 _tables + 本地化字段名 + 该记录用于本地化的主键值

例如：

内容	DB 记录	Loc Key 结构
陆战单位界面名称	land_units_tables.Key	land_units_onscreen_name_ + 单位 Key
陆战单位隐藏名称	land_units_tables.Key	land_units_concealed_name_ + 单位 Key
单位短说明	unit_description_short_texts_tables.Key	unit_description_short_texts_text_ + 说明 Key
单位背景说明	unit_description_historical_texts_tables.Key	unit_description_historical_texts_text_ + 说明 Key

这只是常见规律，不是允许手写所有 Loc Key 的万能公式。有些表使用多个字段拼接本地化主键，拼接顺序由 Schema 定义；还有少数系统存在特殊处理。可靠顺序应该是：

1. 先找一个与目标相同类型的原版记录。
2. 找到它实际使用的 Loc Key。
3. 确认前缀、本地化字段名和主键拼接方式。
4. 再把模板记录的主键部分替换成自己的新 Key。

如果同一表同时出现onscreen_name、description、short_description等字段，它们代表不同显示位置，不能只写一条名称文本就假设所有界面都有说明。

从 DB 记录定位 Loc

已知原版 DB 记录时，最方便的方法是从表格直接跳转：

1. 打开目标 DB 表并选中一整行或该行任意单元格。
2. 右键该行，展开转到...。
3. RPFM 会列出这张表拥有的本地化字段，例如onscreen_name和concealed_name。
4. 点击需要的转到 Loc 条目。

如果目标 Loc 已存在，RPFM 会打开对应文件并定位该行。如果是刚新建的 DB 记录，还没有为它写 Loc，点击后可能没有可打开的结果；这时应使用后面的“生成 Loc 文本数据”检查缺失 Key。

截图中的land_units_tables只是展示一个同时拥有多个本地化字段的例子。建筑、部队技能、角色技能、法术、物品和其他系统应打开各自实际使用的表，不要把单位名称前缀套到其他内容上。

从游戏文字反查 Loc

只知道游戏里显示的中文时，使用全局搜索：

1. 按Ctrl+Shift+F打开全局搜索。
2. 在搜索范围中启用文本（Loc）。
3. 在搜索来源中选择游戏文件；没有依赖项缓存时，也可以只读打开local_cn.pack后搜索当前 Pack。
4. 先搜索一段足够独特的连续文字，不要一开始就搜“伤害”“护甲”这样的高频词。
5. 打开匹配结果，记录完整 Loc Key。
6. 用 Loc Key 的后缀或其中的 DB Key 再搜索数据库（DB），确认是谁在引用它。

同一句中文可能被多个 Loc Key 使用，也可能出现在正文、标题、按钮、百科或脚本消息中。搜索到中文只是找到候选项，必须继续核对引用系统。全局搜索的搜索范围、来源和结果筛选可参见本站《查找原版数据》。

为新内容写 Loc

新内容的常规流程是先完成 DB 连接，再补 Loc：

1. 给新记录使用带个人前缀且不会与原版冲突的 DB Key。
2. 找到同类原版记录的全部本地化字段。
3. 按原版结构为每个需要的字段建立 Loc Key。
4. 在自己的 Loc 文件中填写中文Text。
5. 搜索新 DB Key，确认没有漏掉名称、隐藏名称、短说明、长说明或其他界面文本。

以自定义单位为例，至少要分别判断：

• onscreen_name：常规界面显示名称；
• concealed_name：系统需要隐藏真实名称时使用的文本；
• 短说明：通常来自单位短说明记录；
• 背景说明：通常来自单位背景说明记录；
• 兵种标签：自定义标签还会拥有自己的 Loc Key；
• 部队技能与法术：属于技能或法术自己的 Loc，不会因为单位拥有它们就自动生成。

单位只是例子。制作建筑时要检查建筑名称、短说明、长说明和效果文本；制作角色技能时要检查技能名称、说明和实际效果文本。读者应从同类原版内容查找完整链路，而不是照抄单位所用的四类文字。

修改原版显示文字

如果只想修改一条原版文字，不需要复制原版 Loc 文件。应当：

1. 在local_cn.pack中找到目标 Loc Key。
2. 在自己独立的 Loc 文件中新增相同Key。
3. 把Text改为需要的内容。
4. 保存并进游戏检查最终加载结果。

这叫覆盖同名 Loc Key。它适合改名、修正文案或替换说明，但要注意：

• 所有读取这条 Loc Key 的位置都会得到新文字；
• 另一个 Mod 如果也覆盖相同 Key，就会发生本地化冲突；
• 最终显示哪个版本会受启用的 Pack 和加载顺序影响；
• 游戏更新可能改变原文含义，覆盖类 Mod 需要跟进检查。

如果只是让自己的新单位显示不同名称，应该给新单位建立新 Loc Key，而不是覆盖原版单位的 Key。

自动生成缺失 Loc

RPFM 可以扫描当前 Pack 中的 DB 表，并按 Schema 列出的本地化字段生成缺失文本。它适合在完成一批 DB 记录后查漏补缺。

1. 先保存或确认当前 DB 表已经回写到 RPFM 后端。
2. 在目标 Mod Pack 中选中一个 DB 文件夹或表文件并右键。
3. 点击生成 Loc 文本数据。该命令会检查当前所选 Pack 中的 DB 表，不只检查鼠标指向的单行。

RPFM 可能生成两类临时文件：

文件名前缀	内容
text/zzz_missing_locs_	依赖项中没有现成文本的新 Loc Key，Text会先写成PLACEHOLDER。
text/aaa_missing_locs_	依赖项中已经存在，但当前 Pack 的 DB 记录会使用或覆盖的 Loc Key；RPFM 会带入依赖项中的现有文本。

下面的示例单位拥有onscreen_name和concealed_name两个本地化字段，所以 RPFM 一次生成了两条缺失记录。

aaa_missing_locs_*.loc和zzz_missing_locs_*.loc是检查用临时文件。RPFM 自己的诊断会警告这些文件不应该保留。把真正需要的行整理进自己的正式 Loc，完成文本后删除生成文件，不要直接把带有PLACEHOLDER的结果发布。

生成后按下面的顺序整理：

1. 打开生成文件，判断每条 Key 是否确实属于自己的内容。
2. 把需要的行复制到正式 Loc，例如text/twcn_tutorial.loc。
3. 把PLACEHOLDER替换成最终中文。
4. 对从依赖项带入的原文，只保留自己确实要覆盖的条目。
5. 删除两个生成文件。
6. 再运行一次诊断，并在自己的 Pack 中全局搜索PLACEHOLDER。

如果生成结果为空，不一定是程序出错。可能是 Pack 里没有带本地化字段的 DB 记录，也可能是需要的 Loc 已经存在。若结果明显不完整，先确认当前游戏、Schema 和依赖项缓存正确，再检查目标表是否真的由 Schema 声明了本地化字段。

Loc 文本语法

Loc 的Text不是 Markdown，也不是 HTML。双中括号、双大括号、百分号和井号开头的内容，可能会被《全面战争：战锤 III》的界面解析器当成格式标签、文本引用或运行时参数。语法能否生效还取决于这条 Loc 被哪个界面调用；原版某处能用，不代表换到任意说明框仍然有效。

先区分五类写法：

外形	类型	谁负责替换
[[名称:参数]]...[[/名称]]	颜色、图标、粗体、链接等界面标记	显示这段文本的界面组件
{{名称:参数}}	Loc 引用、悬浮提示引用或 CCO 表达式	本地化与上下文对象系统
%n、%d、%1%等	数值或文本参数	效果系统或调用这段文字的程序
#(对象.属性)	事件上下文参数	事件消息系统
`		、\n、\t`

不要因为它们最后都能显示成文字，就把几套语法互换。最安全的做法始终是找到“同一界面、同一用途”的原版 Loc，复制完整结构后只修改玩家可读文字。

下图在 RPFM 5.0.6 中打开当前中文local_cn.pack，使用全局搜索查找[[col:。上方框内是搜索的原始语法，下面的匹配结果能看到它与图标、换行及其他标签组合后的真实写法。

颜色语法

基本结构是：

[[col:颜色Key]]需要着色的文字[[/col]]

例如：

[[col:yellow]]护甲：%+n[[/col]]

yellow不是随意填写的颜色英文名，而是ui_colours_tables中的key。RPFM 的翻译器也会从这张表读取颜色值。需要其他颜色时，在依赖项中打开ui_colours_tables查找可用 Key，再参考目标界面附近的原版 Loc；不要把 Schema 的字段说明当成游戏里一定可用的颜色名。 颜色；如果颜色 Key 不存在，显示结果取决于具体界面，不能假定游戏会自动改成最接近的颜色。 颜色标签必须成对出现。开始标签决定从哪里变色，[[/col]]决定在哪里恢复原来的颜色。如果漏掉结束标签，后面的整段文字都可能继承

原版也存在[[col:%s]]...[[/col]]。这里的%s表示颜色 Key 由调用界面在运行时传入，不是让作者把所有动态颜色都写成%s。只有同一调用位置的原版模板已经这样写时才应照用。

图标与图片语法

基本结构是：

[[img:图片标识]][[/img]]

《战锤 III》的原版 Loc 同时存在两种图片标识：

[[img:icon_growth]][[/img]]
[[img:ui/battle ui/ability_icons/spell_mastery.png]][[/img]]

• icon_growth这类短标识通常来自ui_tagged_images_tables.key，实际图片路径在同一行的image_path。
• ui/...png这类写法直接填写 Pack 内部的图片路径。
• 图片标识和路径都属于技术内容，不翻译，不添加中文标点，也不要把 Pack 内部的/改成 Windows 路径的\。
• 即使图标中间没有文字，也要保留[[/img]]。

RPFM 的翻译器会先用ui_tagged_images_tables解析短标识，找不到时再把内容当作图片路径尝试读取。游戏中的具体界面仍可能限制图标尺寸、对齐方式或可用资源，所以新增图标后必须在目标界面实测。

粗体与斜体

原版使用下面两组标签：

[[b]]粗体文字[[/b]]
[[i]]斜体文字[[/i]]

它们可以和颜色组合，但结束标签应按与开始标签相反的顺序闭合：

[[b]][[col:white]]重要提示[[/col]][[/b]]

不要只复制[[b]]或[[i]]的开头。某些字体、字号或界面未必能明显显示粗体和斜体差异，标签正确也仍要在游戏中确认。

引用另一条 Loc

{{tr:LocKey}}会把另一条 Loc 的文本插入当前位置：

{{tr:land_units_onscreen_name_wh3_main_ksl_inf_kossars_0}}

这适合复用已经存在的单位名、名词或图标文本。它引用的是完整 Loc Key，不是 DB 记录 Key，也不是把大括号里的内容直接显示给玩家。使用时注意：

1. Key 必须完整存在于当前语言能够加载到的 Loc 中。
2. 大小写、下划线和标点必须与目标 Key 完全一致。
3. 不要翻译tr或冒号后的 Key。
4. 不要让两条 Loc 互相引用，否则会形成循环引用。
5. 目标 Loc 自己带有颜色、图标或占位符时，这些内容也会一并插入；先检查组合后是否重复套标签。

原版常把图标也包装成可复用文本，例如{{tr:icon_income}}。这不表示所有图标都必须经过{{tr:...}}；能否直接使用[[img:...]][[/img]]仍应参考同类原版文本。

内部链接与悬浮提示

下面这些都不是普通网页链接：

形式	原版中的常见用途
[[sl:帮助主题]]文字[[/sl]]	把文字连接到游戏帮助系统中的主题。
[[sl_link:帮助主题]]文字[[/sl_link]]	另一类脚本化帮助链接，常见于战役玩法说明。
[[sl_tooltip:帮助主题]]文字[[/sl_tooltip]]	为文字连接相应的帮助或说明提示。
[[url:script_link_...]]文字[[/url]]	调用游戏内部的script_link，不是打开任意互联网网址。
[[tooltip:{{tt:提示Key}}]]文字[[/tooltip]]	为可见文字绑定一条悬浮提示。

原版事件消息中常见这样的嵌套结构：

[[url:script_link_campaign_settlements]][[tooltip:{{tt:tooltip_campaign_settlements}}]]城镇[[/tooltip]][[/url]]

这里的城镇是玩家看到并可交互的文字，script_link_campaign_settlements和tooltip_campaign_settlements都是技术标识。{{tt:...}}用于提示系统，不能因为外形相似就改成{{tr:...}}。这些链接依赖具体界面和脚本注册的目标；随意编造 Key 通常不会得到一个新的帮助页面。

效果数值占位符

effects_tables的说明 Loc 经常使用以n结尾的占位符。它们由效果系统把当前效果数值填入文本：

写法	显示意图	示例结构
%n	插入效果数值，不额外强制正号。	物理抗性：%n%
%+n	正值前显示+，常用于加成。	近战攻击：%+n
%-n	用负号形式显示数值，原版用于部分“降低”类说明。	维持费：%-n%
%n%、%+n%、%-n%	占位符后再显示百分号。	射程范围：%+n%

这里的字母n不是“第 n 个参数”，也不是让作者手动替换成数字。它能工作，是因为对应效果与显示位置会把效果数值传给这条说明 Loc。把%n写进单位名称、普通剧情正文或其他没有效果参数的 Loc，不会凭空获得一个数值。

正负号还会受到效果本身的数值方向和显示用途影响。不要只看中文意思决定用%+n还是%-n；先找使用同类effect、同类effect_scope和同类数值方向的原版行，再在游戏中检查最终符号。

界面格式参数

%d、%s和%S属于另一套由界面调用方传入的格式参数，不等于效果系统的%n：

写法	常见传入内容	注意事项
%d	整数，例如数量、等级或秒数。	同一文本出现多个%d时，顺序与调用方传参顺序对应。
%+d	带正负号显示的整数。	只在原版同类模板已经使用时照用。
%s、%S	运行时传入的文本或资源标识。	大小写有意义，必须保留原模板写法。
%%	在这套格式化文本中输出一个普通百分号。	因此原版会出现%d%%或%+d%%。

例如：

装备盾牌||这支部队有%d%%的概率格挡前方射来的小型投射火力

假设调用方传入35，%d%%的目标结果是35%：第一个%d接收数字，后面的%%输出百分号。不要把它简化成%d%，也不要照搬效果说明中的%n%。

下面这种组合表示图片标识和数字都由界面传入：

[[img:%s]][[/img]]%d

作者不能仅凭 Loc 看出调用方一定会传入什么。需要修改这类文本时，优先复制同一个 Loc Key 的原版结构，只调整中文语序；新建整套界面功能时，还必须同步检查调用这条 Loc 的 UI 或脚本。

带序号的参数

%1%、%2%、%3%表示第 1、2、3 个参数，常见于任务目标和战役奖励说明：

令%1%名%3%类人物提升至%2%级

这套写法允许译文为了中文语序调整参数位置，但不能改变参数编号所代表的内容，也不能漏掉调用方提供的参数。检查同一 Key 的英文原文可以确认参数总数和大致含义；中文原版可以确认更自然的排列顺序。

%1%两端的百分号属于完整占位符。它与%d%%中用于输出百分号的%%不是一回事。

事件上下文参数

事件消息会使用#(对象)或#(对象.属性)取得本次事件中的人物、派系、城镇等内容：

#(character)
#(target.faction)
#(settlement.region_and_province)

点号表示继续读取上下文对象的属性。括号中的名称由事件系统提供，不能翻译，也不能把target想当然地换成任意英文词。只有调用这条 Loc 的事件确实提供了对应对象和属性，游戏才能显示实际名称。

#(...)与%s都可能最后变成文字，但来源不同：前者读取事件上下文，后者接收界面函数传入的格式参数。修改事件文字时复制同一类事件的原版结构；制作新事件时同时检查事件记录或脚本到底提供了哪些目标对象。

CCO 表达式

较新的战役界面还会直接在 Loc 中读取 CCO（Context Object）属性。基本外形是：

{{Cco类型:表达式}}

当前原版数据中的简单形式包括：

{{CcoCampaignPooledResource:Max}}
{{CcoCampaignEventIncident:FirstTargetName}}

也存在带函数、引号和多层属性的复杂表达式。CCO 类型名、属性名、函数名、引号和括号都属于程序语法，不翻译、不改变大小写。CCO 表达式只在界面提供了相应上下文对象时有效；不能把它当成通用的“读取任意 DB 值”语法。

对于只是制作单位、效果或建筑名称的初学者，通常不需要自己编写 CCO 表达式。遇到它时先保留整个{{...}}，只翻译表达式之外的可见文字；确实要制作新的动态界面文本时，再从同一个 UI 组件使用的原版 Loc、UI 文件或脚本反查上下文。

分段、换行与制表

写法	常见作用	正确处理
`		`
\\n	插入一个转义换行。	在 RPFM 单元格中输入两条反斜杠和字母n。
\\n\\n	连续两个转义换行，形成空一行的段落间隔。	两组都要完整保留。
\\t	插入转义制表。	当前原版用量很少，只在同类模板中照用。

例如：

装备盾牌||正文说明
第一段\\n\\n第二段

RPFM 会把单元格中的真实换行和真实制表诊断为问题；这里需要的是字面量\\n和\\t。从 Excel、网页或聊天软件粘贴文本时尤其要检查，避免软件把转义字符自动变成真正的换行或 Tab。

||也不能一律理解成两个换行。原版装备盾牌||这支部队……之类的写法明显承担“标题和说明”的结构分隔，而其他界面可能用不同方式呈现；应以目标界面实际效果为准。

标签组合与闭合顺序

一条 Loc 可以同时使用多种语法：

[[col:yellow]]所在行省的[[img:icon_public_order]][[/img]]{{tr:hp_campaign_public_order_term}}变动%n[[/col]]

拆开看：

1. [[col:yellow]]开始黄色文字。
2. [[img:icon_public_order]][[/img]]插入图标。
3. {{tr:hp_campaign_public_order_term}}插入另一条 Loc。
4. %n由效果或行动数值替换。
5. [[/col]]结束颜色范围。

嵌套标签要像括号一样从内到外关闭：

[[b]][[col:white]]文字[[/col]][[/b]]

不要写成：

[[b]][[col:white]]文字[[/b]][[/col]]

原版数据中也可能保留历史写法、闭合不一致或只适用于某个组件的特殊组合。发现原版“看起来不规范”时，不要在没有游戏验证的情况下主动替它重排；先确认这条 Loc 的实际调用位置。

少见且专用的标记

当前原版 Loc 还能看到下面这些形式：

形式	使用范围	建议
[[overridecol:...]]...[[/overridecol]]	覆盖界面默认颜色，主要见于部分旧内容。	原版存在不同闭合写法，只复制同类模板，不自行统一。
[[opacity:0]]...[[/opacity]]	在少数界面中控制文字透明度或辅助排版。	不要拿它当通用隐藏文本功能。
`[[fragment:数值	数值]]`	剧情面板等专用文本片段控制。
[[rgba:R:G:B]]...[[/rgba]]、[[rgba:R:G:B:A]]...[[/rgba]]	RPFM 翻译器能够解析的直接颜色形式。	当前中文基础 Loc 中没有常规使用；《战锤 III》优先用[[col:颜色Key]]。

此外，原版中还可能出现极少量遗留、组件专用甚至不成对的标签。它们能出现在数据里，不等于已经形成可供所有 Mod 通用的语法。除非正在复刻相同界面，否则不要仅凭标签名字猜用途。

怎样自行查找正确语法

1. 先确定文字最终出现在哪个界面，例如效果说明、任务目标、事件消息或帮助页面。
2. 在依赖项中找到该界面已有的一条原版 Loc；找不到 Key 时，使用全局搜索搜索游戏里能看到的原文或独特的技术标识。
3. 在全局搜索中只勾选文本（Loc），搜索[[col:、{{tr:、%+n等完整片段，可以批量查看原版组合方式。
4. 优先比较同一表、同一字段、同一 UI 组件或同一脚本调用的多条 Loc，不要只抄搜索结果中的第一条。
5. 对照中文和英文原版：中文用于确认游戏术语和语序，英文可帮助确认占位符数量以及每个参数大致代表什么。
6. 复制完整标签或占位符，只修改玩家可读文字；保存后运行诊断。
7. 进入游戏触发目标界面，检查文字、数值、正负号、颜色、图标、换行、链接和悬浮提示是否都正确。

常见语法错误

现象	优先检查
游戏直接显示[[col:...]]等原始标签	标签拼写、目标组件是否支持该标签、开始与结束标签是否配对。
后续整段文字颜色异常	是否漏写[[/col]]，或嵌套闭合顺序错误。
图标为空或显示异常	ui_tagged_images_tables中是否存在短标识，直接路径是否指向实际资源，目标组件是否支持图片。
游戏直接显示%n、%d或%1%	Loc 是否被正确的系统调用，占位符类型和数量是否与原版模板一致。
数字有了但正负号或百分号错误	%n、%+n、%-n是否选错，%d%%中的%%是否缺失。
{{tr:...}}没有得到目标文字	引用的是否为完整 Loc Key，目标语言中是否存在该 Key，是否产生循环引用。
事件中的#(...)没有替换	对应事件是否提供该对象或属性，名称、点号和括号是否与原版一致。
只有某个界面失效	该语法可能只受特定 UI 组件支持；换用同一界面的原版模板后再测。

诊断通过只能证明 RPFM 发现不了已知的数据问题，不能证明目标界面一定支持某段语法。动态参数、内部链接、CCO 表达式和专用标签必须通过游戏内实际触发来验收。

标点、空格和换行

• 中文正文通常使用全角标点，但技术 Key、路径和标签内部必须保留英文半角字符。
• 不要在 Loc Key 末尾留下空格。视觉上看不出来的空格也会让它变成另一条 Key。
• 文本开头或结尾的空格只有在原版模板明确需要时才保留。
• 长说明不要完全依赖手动换行。先在游戏里观察文本框宽度，再决定是否加入结构分隔或转义换行。
• 百分号、正负号和数字占位符周围的空格应参照同类原版文本，否则可能出现“+ 10%”之类不自然的结果。
• 同一名词在单位名称、技能名称和说明正文中应使用游戏内一致的译名，不要直接采用 Schema 或 Assembly Kit 字段的中文直译。

批量编辑与 TSV

Loc 表格右键菜单提供导出 TSV和导入 TSV。它适合条目很多、需要校对或交给译者处理的项目，但不要直接把整个localisation__.loc导出后全量带回 Mod。

推荐流程：

1. 只对自己的正式 Loc 执行导出 TSV。
2. 保留 RPFM 导出的列结构，把它作为导入模板。
3. 在表格软件中把Key列按文本处理，不要自动改写内容。
4. 不要改列名、删除Tooltip列或把 TSV 另存成普通 CSV。
5. 导入前备份 Pack，并先用少量条目验证。
6. 导入后检查条目数、重复 Key、空白Text、PLACEHOLDER和特殊标记。

Excel 等软件可能自动处理引号、制表符、换行或看似数字的内容。条目不多时直接在 RPFM 编辑更安全；条目很多时，也应使用同一版本 RPFM 导出的 TSV 作为模板，而不是自己猜测文件格式。

翻译器适合什么情况

RPFM 的工具 → 翻译器面向“把一个已有 Mod 翻译成另一种语言”，它与给自制 DB 记录补几条 Loc 不是同一套工作量。

翻译器的基本工作方式是：

1. 在 RPFM 中打开原始 Mod Pack。
2. 打开工具 → 翻译器并选择目标语言。
3. 逐条查看原始值，在翻译值区域填写文本。
4. 切换到另一行，或使用上移、下移操作提交当前行。
5. 已有翻译 Pack 可以通过从已翻译的 Pack 导入继续整理。
6. 保存时，RPFM 会把翻译写入打开 Pack 的 Loc，同时在 RPFM 配置目录的translations_local中保存用于跟踪更新的 JSON。

当原始 Mod 更新文本后，翻译器可以帮助标出需要重新翻译的条目。它也提供 Google、DeepL 或兼容接口的 AI 翻译入口，但这些功能依赖相应服务和配置。自动翻译只能作为初稿，必须人工核对游戏术语、占位符、颜色标签、图标标签、换行以及上下文。

如果准备发布中文翻译，通常应制作独立翻译 Pack，而不是修改原作者的 Pack。这样更容易更新、卸载和判断冲突，也不会把原 Mod 的全部资产重复打包。

多语言发布

同一个最终加载结果中，一条 Loc Key只能对应一段有效文本。不要在同一个 Loc 中重复添加相同 Key，试图用多行同时保存中文、英文和其他语言。

常见做法是：

• 主 Mod 提供一种基础语言；
• 每种额外语言使用独立翻译 Pack；
• 所有语言保持相同 Loc Key，只替换Text；
• 翻译 Pack 声明所需的主 Mod，并在主 Mod 更新后重新核对条目。

不同发布平台和 Mod 管理方式对依赖、加载顺序的处理可能不同。完成后必须在目标语言环境下实际启用对应 Pack 检查，不能只凭 RPFM 中存在 Loc 行就判定多语言发布成功。

常见故障

游戏显示原始 Key

常见原因：

• Loc Key 拼错，尤其是前缀、本地化字段名或复合主键顺序错误；
• Loc 文件没有放在text路径；
• Pack 没有启用或没有被游戏加载；
• DB 记录引用的是另一条文本 Key；
• 新 Key 改完后，Loc 仍保留旧后缀。

先复制游戏显示出的 Key，在自己的 Pack 和依赖项中全局搜索，确认它是否真的存在。

仍然显示原版文字

常见原因：

• 修改了相似但不是目标界面实际使用的 Loc Key；
• 另一个 Mod 覆盖了相同 Key；
• 修改的是名称，但当前界面显示的是隐藏名称、短说明或另一个变体的文本；
• Pack 保存失败，或者游戏仍在使用上次启动时加载的版本。

用 DB 行的转到 Loc 条目和全局搜索交叉核对，再完全退出并重新启动游戏测试。

文本为空或只有部分界面缺失

检查该系统是否拥有多条本地化字段。单位可能同时需要名称、隐藏名称、短说明和背景说明；部队技能与它的阶段、效果也可能各自拥有文本。不要因为一个界面正常，就假设所有文字都来自同一条 Loc。

数字、颜色或图标异常

把当前文本与同类原版 Loc 逐字符比较，重点检查：

• %n等占位符是否丢失或增加；
• [[...]]标签是否成对闭合；
• 图片或颜色标识是否被翻译；
• \\n、\\t与||是否被表格软件改写；
• 半角冒号、百分号和正负号是否符合该系统模板。

RPFM 报告缺失 Loc 数据文件

如果诊断指向aaa_missing_locs_*.loc或zzz_missing_locs_*.loc，说明自动生成的临时文件还留在 Pack 中。把需要的行整理进正式 Loc，删除临时文件后重新运行诊断。

中文变成乱码或方框

Loc 本身使用能够保存中文的字符串格式。乱码通常来自外部 TSV 被错误编码或内容在其他软件中被改写。重新从 RPFM 导出模板，只恢复少量条目测试；不要通过复制整份原版 Loc 来掩盖编码问题。

发布前检查

1. Loc 文件位于text下，并使用项目独立文件名。
2. 没有复制原版localisation__.loc。
3. 每条Key都与对应 DB、UI 或脚本实际需要的 Key 完全一致。
4. 自定义 Key 带稳定前缀，没有与原版或其他 Mod 冲突。
5. 没有重复 Key、空白Text或PLACEHOLDER。
6. aaa_missing_locs_*.loc和zzz_missing_locs_*.loc已经删除。
7. 颜色、图片、引用、数值和换行标记保持完整。
8. 名称、短说明、长说明、隐藏名称等不同位置分别检查。
9. RPFM 诊断没有尚未处理的本地化错误。
10. 在游戏中检查实际排版、换行、数字替换、图标和加载冲突。

RPFM 能确认文件结构、部分缺失 Key 和格式问题，但无法证明每条文字在游戏中出现的位置、上下文和排版都正确。最终验收必须回到真实游戏界面。