做游戏出海的团队十有八九都被“多语言”折腾过。最早的项目通常是在场景里直接写死中文等版号、发行、海外代理一聊发现要加英文、日文、韩文整个人都麻了。手动去场景里一个个改Text组件几百个界面改到天亮。于是就有了这个Unity多语言转换工具它帮我把翻译表Excel/CSV一键转成游戏内的本地化数据自动替换场景里的硬编码文本运行时切换语言即时刷新。核心思路就是“文本ID 翻译映射”配合编辑器扩展把重复劳动压到最低。适合Unity开发者、独立游戏制作者、以及所有正在补课国际化的团队尤其是手上已经有存量项目、不想推倒重来的人。我在这里把整个工具的设计思路、关键代码、实操流程和踩坑记录都摊开讲。不是教科书式的“最佳实践”而是我实际用了一段时间、改了又改之后留下的东西。看完你能直接照着抄一套适合自己的版本。1. 多语言工具的定位与整体设计思路1.1 先想清楚你需要的是一把“螺丝刀”还是“数控机床”很多教程一上来就推全套本地化插件什么组件替换、自动收集、热更新、字体回退一条龙。但大而全的框架往往在小项目里变成累赘。我自己最早犯过的错就是追求“一步到位”结果工具本身比手改还费时间。做多语言工具之前先问三个问题项目规模多大是10个界面还是100个界面发布语言有多少只是简繁英还是包含阿拉伯语、泰语这种布局差异很大的语言谁在填翻译是程序自己填还是策划/外部翻译公司提供表格想清楚再去选方案。规模小直接写一个静态字典类就够了规模大才需要编辑器窗口、自动扫描、Addressables加载。我这套工具走了中间路线编辑器侧负责“转换”和“替换”运行时侧只保留一个轻量管理器。它不管美术图集、音频本地化那些重活专注解决最常见的文本翻译问题。这样代码量可控也容易维护。1.2 关键技术选型表格、资源、组件三件事一个Unity多语言转换工具说白了就是把三件事串起来表格数据翻译的源头。最常见的是Excel/CSV每行一个文本ID每一列对应一种语言。Excel方便翻译公司填写但Unity不能直接读CSV是纯文本容易解析但Excel另存为CSV时编码容易踩坑后面细说。数据存储游戏运行时能快速读取的数据。两种选择ScriptableObject或者Json/二进制。ScriptableObject的优势是Unity原生支持Inspector里可视化检查还能挂自定义Inspector做翻译统计Json则适合走热更新或者和远端表格联动。我选了ScriptableObject因为转换工具跑完之后直接在编辑器里生成asset文件打包时自动包含零额外IO。UI组件场景里到处放着的Text、TextMeshPro。多语言工具要做的是要么把Text组件替换成支持本地化的组件要么在生成阶段自动为每个Text挂上本地化脚本并绑定Key。我选择后者——写一个LocalizedText组件通过ContextMenu或者编辑器扫描自动附着不改变原有的Text层级和样式。1.3 为什么坚决不用“字符串匹配”来做翻译可能有人说我运行时把界面上的中文拿去查表查到对应的英文不就行了比如text.text是“确定”查表发现“确定OK”于是改成OK。这听起来很美但实际会崩同一个文案在不同界面可能微调比如“确定”和“确 定”带空格匹配不上。字符串重了“删除”可能是按钮上的操作也可能是提示文案里的动词翻译目标完全不同。拼写敏感一个标点不一样就漏匹配。只要翻译公司手滑改了一个字符原来的中文Key就作废了。所以我坚持“文本ID 当前语言文本”的方式。界面组件只认Key比如btn_confirm运行时根据当前语言查表得到“确定”还是“OK”。用Key代替原文有几个好处翻译更新不影响代码逻辑同一个Key多处使用改一处全部生效还方便做自动检查——没翻译的Key能统计出来。2. 核心功能拆解与实现细节2.1 翻译表的导入与导出Excel / CSV / JSON 的兼容设计工具的第一步是把翻译表吃进来。我给的模板很简单第一行是标题key, zh-CN, en-US, ja-JP btn_confirm, 确定, OK, 確認 btn_cancel, 取消, Cancel, キャンセルExcel里可以直接用这个格式。工具里我支持两种导入方式直接用File.ReadAllLines解析CSV或者用ExcelDataReader/NPOI读xlsx不依赖Office。这里有个重要细节——CSV必须按UTF-8 with BOM读取否则Windows中文环境容易乱码。在Unity里我建议自己加一个编码嗅探或者强制要求翻译表另存为UTF-8。我最开始用默认编码读CSV中文全变问号查了半天才发现是编码问题。解析之后存成一个LanguageTable对象[Serializable] public class LanguageData { public string key; public Liststring translations; // 与LanguageDef.languages顺序一致 } public class LanguageTable : ScriptableObject { public Liststring languages; // [zh-CN, en-US, ja-JP] public ListLanguageData entries; // 每行数据 }导出逻辑就是生成的ScriptableObject资产。除此之外我还留了一个“导出未翻译Key”的功能遍历所有已注册的Key再查表里是否存在对应语言的翻译缺失的汇总到CSV里方便丢回给翻译公司。2.2 自动替换场景中的硬编码文本存量项目最大的痛点就是旧场景里散落着上千个写死中文的Text。让我手动一个个改成Key那不如去死。所以工具里必须有一个“扫描替换器”。它是这样工作的用户指定一个需要处理的场景/Prefab文件夹。工具遍历所有Text组件和TextMeshPro组件。读取text.text的值把它当作“原文翻译表”的反向查找键在已有的表中搜索这个值在源语言比如zh-CN对应的Key。能找到Key就直接给这个Text挂上LocalizedText组件并设置key。找不到Key就把该文本收集为“新增待译条目”追加到翻译表中并自动生成一个新的Key比如ui_00123同时挂上组件。这个流程有一个取舍它依赖于已有的翻译表反向查找如果项目完全没有旧翻译表就需要先人工整理一遍场景文案。我在实际使用时第一次把公司的老游戏扫描完生成了三百多个Key然后花半天把重复文案去重把语义不清的Key改名。这个代价是可以接受的毕竟只做一次。扫描替换器的核心代码思路如下简化版[MenuItem(Tools/Localization/Scan And Replace Selected Scenes)] public static void ScanAndReplace() { var allTexts FindAllTextComponentsInSelection(); foreach (var text in allTexts) { string source text.text; string key LanguageTable.FindKeyByOriginal(source); if (string.IsNullOrEmpty(key)) { key AddNewKeyToTable(source); // 自动生成key记入表 } var localized text.gameObject.AddComponentLocalizedText(); localized.SetKey(key); } EditorUtility.SetDirty(table); AssetDatabase.SaveAssets(); }注意事项处理完之后一定要先做一次Prefab Apply因为自动添加的组件默认只保存在场景里如果不Apply你Prefab上其他实例不会同步。这个坑我踩过后来在工具里加了强制Apply提示。2.3 运行时切换语言与事件通知转换工具生成的资产只是数据游戏运行时还需要一个中央管理器来“翻译”和“广播”。我写了一个极简的LanguageManagerpublic class LanguageManager : MonoBehaviour { public static LanguageManager Instance { get; private set; } public LanguageTable table; public string currentLanguage zh-CN; public event System.Action OnLanguageChanged; private void Awake() { Instance this; } public void ChangeLanguage(string lang) { if (currentLanguage lang) return; currentLanguage lang; OnLanguageChanged?.Invoke(); } public string GetText(string key) { var data table.GetEntry(key); if (data null) return key; int idx table.languages.IndexOf(currentLanguage); if (idx 0 || idx data.translations.Count) return key; return data.translations[idx]; } }每个LocalizedText组件注册到OnLanguageChanged事件里切换语言时统一刷新public class LocalizedText : MonoBehaviour { public string key; private Text _text; private TextMeshProUGUI _tmp; private void Awake() { _text GetComponentText(); _tmp GetComponentTextMeshProUGUI(); if (LanguageManager.Instance ! null) { LanguageManager.Instance.OnLanguageChanged Refresh; } Refresh(); } private void OnDestroy() { if (LanguageManager.Instance ! null) LanguageManager.Instance.OnLanguageChanged - Refresh; } public void SetKey(string newKey) { key newKey; Refresh(); } public void Refresh() { string value LanguageManager.Instance.GetText(key); if (_text) _text.text value; if (_tmp) _tmp.text value; } }这个方案的关键点是不要用Update轮询一定要用事件。场景里如果有几百个Text每帧轮询会造成无谓的字符串比较尤其移动端很伤性能。事件驱动只在语言切换那一刻刷新所有界面成本极低。如果项目用了UI框架比如UGUI的Button里的Text尽量把LocalizedText挂在Text同一个物体上它自动会处理Button的显示。如果界面是通过代码动态创建的Instantiate出来的记得在生成后调用一次localized.SetKey(key)或者保证LanguageManager已经存在并且Awake里注册事件后会自动刷一遍。2.4 富文本、参数占位与动态拼接的处理实际项目里很少有用纯静态文案的地方。比如“金币不足需要再充值XX元”这种文案你不能把整句话丢给翻译表因为那个数值是动态的。翻译公司也不会喜欢一句话里有需要翻译的数字。我的处理方式文本里用{0}做占位符Key存储的是模板。运行时填充key: shop_coin_not_enough zh-CN: 金币不足还差 {0} 个 en-US: Not enough coins! Need {0} more! ja-JP: コインが足りません。あと{0}個必要です获取文本的接口重载一个带参数版本public string GetText(string key, params object[] args) { string format GetText(key); if (args.Length 0) return string.Format(format, args); return format; }这个必须注意不同语言的语序不一样。中文说“还差10个”日语说“あと10個必要です”如果你是拼接而不是占位符那日语就全乱了。所以尽量把数字、名字都作为参数。而且{0}的顺序在各个语言的翻译里可以打乱比如中文是“{0}个金币”英语可以翻译成“{0} coins”不一定保持原顺序。string.Format支持按顺序填充但如果你有多参数可以区分命名。比如{name}这种命名占位符在Unity里用string.Format不支持我用的是简单正则替换public string GetText(string key, Dictionarystring, string args) { string result GetText(key); if (args ! null) { foreach (var kv in args) { result result.Replace({ kv.Key }, kv.Value); } } return result; }这种命名占位符对翻译更友好建议大小项目都用这个。富文本也要小心。TMP里支持color#ff0000红色/color这种标签也会跟着翻译。如果原文是“开始{0}”这种很容易和占位符混淆。我遇到过一次原文本里包含b{count}/b结果在日语环境里富文本标签被翻译公司改坏了。我的方案是约定翻译表中不允许出现尖括号富文本标签全部由程序拼装不在翻译表里出现。如果确实需要一段富文本就拆成多个Text拼接或者提供纯文本的“描述字段”。3. 实操过程与完整流程演示3.1 工具目录结构与自定义编辑器窗口为了让工具用起来方便我建了独立的目录结构Assets/ Localization/ Editor/ LocalizationToolWindow.cs LocalizationScanner.cs Runtime/ LanguageManager.cs LocalizedText.cs LanguageTable.cs Data/ LanguageTable.assetLocalizationToolWindow是一个继承EditorWindow的类用MenuItem(Tools/Localization/Open Window)打开。窗口里放四个按钮导入CSV/Excel扫描当前场景/选中Prefab导出缺失翻译生成语言常量类生成语言常量类是我后面补充的功能它会把所有翻译Key生成一个静态字符串常量写代码的时候不用手敲public static class L { public const string btn_confirm btn_confirm; public const string btn_cancel btn_cancel; }这样以后在代码里写GetText(L.btn_confirm)避免Key拼写错误。而且IDE有自动补全再也不会出现Key打错导致运行时显示Key名的情况。3.2 写一个最小可用的本地化管理器除了上面贴的代码还需要完善一下LanguageManager的初始化。项目启动时一般是场景里放一个“App”物体挂上LanguageManager把LanguageTable.asset拖进去。如果不想手动拖可以在Awake里用Resources.Load加载if (table null) table Resources.LoadLanguageTable(LanguageTable);这样工具生成的asset只要放在Resources目录下就能自动找到部署起来省事。如果用了Addressables也可以改成Addressables.LoadAssetAsyncLanguageTable(LanguageTable)但要注意异步加载时序UI要在异步完成后再初始化。我建议项目初始化流程是这样的LanguageManager.Awake加载表注册事件。启动语言设置PlayerPrefs或服务器下发。调用一次ChangeLanguage(saveLang)。各场景的LocalizedText在Awake时已经订阅事件收到刷新通知后自动更新文本。这个顺序最重要的一点是LocalizedText的Awake发生什么时机如果是启动场景LanguageManager先Awake如果是动态场景可能LocalizedText先Awake此时LanguageManager可能还没加载完成。所以我在LocalizedText里加了一个容错private void Refresh() { if (LanguageManager.Instance null || LanguageManager.Instance.table null) { // 延后到下一帧再刷新 Invoke(nameof(Refresh), 0.1f); return; } // ...正常设置文本 }这个“延后重试”可能看起来笨但实际处理各种加载顺序很管用。后来我改成用协程等待一帧也比直接return好得多。3.3 从翻译表到游戏内语言的端到端测试我以一个简单的“设置界面”为例走一遍完整流程。场景里有两个按钮分别显示“确定”和“取消”另外有一个提示文本“金币不足”。我把这些中文文案整理到Excel表格里按上文格式填入Key列和zh-CN列。调用工具的“导入”生成LanguageTable.asset同时窗口显示已导入的条目数。对着“设置界面”场景执行“扫描替换”。工具自动给每个Text挂上LocalizedText组件并把key绑定到对应的翻译条目。保存Prefab进入Play模式。在运行时控制台用LanguageManager.ChangeLanguage(en-US)观察所有文本是否需要即时变为英文。这个过程如果顺利从零到跑通只需要十几分钟。前提是翻译表里已经填了英文。如果还没有外文翻译可以先用拼音或占位符测试流程确保机制没错再交给翻译团队补充。这里有个经验初期测试时只放两个语言列不要十几种语言一锅烩。因为每多一种语言审核工作量和字体资源都会翻倍。先跑通中英再逐步加日韩、德法、阿拉伯语每一步单独验证。4. 常见问题与排查技巧实录4.1 乱码问题UTF-8 BOM、Excel导出坑、CSV分隔符乱码是本地化工具的第一个拦路虎。我遇到的乱码分三种从Excel另存为CSV时默认可能是ANSI编码中文在Unity里读出来全乱。解决用Excel插件导出UTF-8或者在工具里读取时自动检测并转换。CSV用逗号分隔但英文翻译里经常含有逗号。比如Operation, please wait直接Split(,)会把一个文本切成两段。解决用成熟的CSV解析库或者规定翻译文本中不允许出现裸逗号必须用中文逗号或全角逗号。中文Excel单元格里包含换行符导出CSV时如果没加引号包裹会把一整行拆掉。解决所有文本单元格在导出CSV时都用双引号包裹内部换行符转义。在Unity里最稳的读取方式是var lines File.ReadAllLines(path, Encoding.UTF8);前提是文件必须是UTF-8并且不带BOM也一般没问题带BOM也不影响ReadAllLines。但如果用File.ReadAllText再SplitBOM会导致第一行第一个Key前面多出一个不可见字符所以用ReadAllLines可以避开这个坑。4.2 文本长度与排版溢出德语、法语比英文长很多多语言最恶心的不是翻译是界面放不下。德语比英文平均长30%法语也差不多俄罗斯语更长。按钮宽度固定的话英文是“OK”德语可能变成“In Ordnung”直接超出边界。我为此在工具里加了一个“文本长度估算”预览切换语言时在Inspector里用Font.GetCharacterInfo估算每个Key在当前字体下的像素宽度并对照UI的RectTransform宽度做警告。但更实用的做法是在UI设计阶段就预留好伸缩空间按钮不要固定宽度设置ContentSizeFitter并留padding文本区域允许折行但要注意某些语言禁止在特定位置换行泰语、缅甸语需要按词换行UGUI的horizontal overflow默认设为Wrap动态调整字号给LocalizedText加一个autoShrink选项当文本实际宽度超过Rect宽度时调用tmp.fontSize * 0.9循环降字号直到放得下。这是应急方案能覆盖80%的溢出问题对于关键UI比如商店价格标签最好做单独的本地化版面而不是指望一套布局通吃所有语言。实际上很多发行商在本地化测试时会截一堆“文字被切断”的图反馈回来提前用“最长语言模式”比如德语跑一遍UI截图对比能省去很多来回沟通。4.3 动态字体、东亚字体与回退字体非英语语言对字体要求很高。中文字体动辄几MB到十几MB日文、韩文也都有自己的字符集要求。如果项目里只打包了一款拉丁字体切到中文时全部显示成方块。处理方案简单粗暴每种语言用一套字体切换时在LocalizedText里同时换font和material。但这会导致多语言包体剧增加载卡顿。用动态字体Unity 2018支持Font.CreateDynamicFontFromOSFont或TMP_FontAsset动态字体只打包字体数据子集运行时从系统加载。但不同机型系统字体缺失显示效果不稳定。回退字体机制TMP从4.0开始有TMP_Settings.fallbackFontAssets可以设置多个回退字体。我用了一个开源字体比如思源黑体/Noto Sans作为中英日韩的共同字体再把系统字体作为回退兜底。写代码时用TMP_Settings.SetFallbackFonts把多语言字体都塞进回退列表里这样TMP会自动找到包含对应字符的字体省去手动切换。对于老式UGUI Text它不支持回退字体。所以新项目尽量全部用TMP老项目我也会在工具扫描时直接把Text替换成TMP的组件一劳永逸。不过替换组件的操作会丢失一些样式属性需要做迁移映射比如fontSize映射到fontSizecolor映射到coloralignment映射到alignment。这块工程量不小但做一次以后就清净了。4.4 特殊语言处理阿拉伯语/RTL、泰语换行、日语标点真正专业的本地化避不开这些坑阿拉伯语/希伯来语从右往左RTL。UGUI Text虽然有个RTL选项但只对基础字符有效混合数字和拉丁字母时排序会乱。我测试过最简单的支持方式是使用TMP 3.0内置的RTL支持配合阿拉伯语显示修复组件比如ArabicSupport插件。工具里我提供一个ForceRTL开关在切换语言为ar/fa/he时自动设置Text组件的alignment TextAnchor.MiddleRight并启用RTL。但如果是复杂UI建议美工直接出RTL版本的布局程序只能保证文本正确不能保证布局镜像。泰语没有空格词与词之间没有间隔换行容易断错。UGUI按字符换行泰语字符可以接受断行但要注意泰文上方有音调符号换行时可能显示错位。解决泰语使用专门字体行高要调大不然上方附加符号会被裁掉。日语标点日文逗号是“、”句号是“。”英文标点和日文标点混用会很难看。这个只能靠翻译质量工具没法自动修但可以在预览窗里高亮标点让审核容易发现。这类特殊语言在工具里加分项是“语言特性预设”。我建了一个配置表每种语言有默认字体、对齐方式、行高倍率、是否需要RTL、是否字符换行等。这样切换语言时LocalizedText除了更新文本还会自动调整这些参数。否则光靠翻译公司是搞不定显示细节的。4.5 构建时资源裁剪与语言数据裁剪很多出海游戏希望包体越小越好。多语言翻译文本本身没几个KB但字体是真的大。如果你为每种语言都打包一套字体包体直接爆炸。我的做法翻译表永远全量打包因为文本数据几十种语言也不过几百KB不值得做分包。字体在构建时按需裁剪用Addressables把每种语言的字体单独打成AssetBundle运行时按当前语言加载。中文字体虽然十几MB但每个字体打包后经过压缩可能只有几MB。如果确实太占空间可以考虑只打包常用字运行时用系统字体回退或者使用Unicode子集工具预裁剪字符集。有个取巧的办法先用翻译表里所有Key的所有翻译文本统计出需要哪些字符然后生成一个包含这些字符的字体子集。很多中文字体可以用工具自动裁剪到一两千字画质影响不大但包体从十几MB减到2MB。Unity有开源插件FontSubsetter可以实现这个。4.6 版本迭代时Key管理废弃Key、漏翻译、自动检查游戏版本更新后代码里删掉了一些旧文本Key翻译表里还留着几百条永远用不到的记录新加了一堆文案可能忘了进表。没有工具辅助的话过两三个版本翻译表就是一团乱麻。我在工具里做了三类检查漏翻译检查遍历所有LocalizedText的Key查当前语言表缺失的列到文件里。废弃Key检查遍历项目所有脚本和场景找出翻译表里有但代码里没有引用的Key标记为“未使用”人工确认后可以删除。Key命名规范强制Key用小写下划线命名禁止空格和特殊字符方便生成代码常量。检查功能做成菜单项每次发版前跑一遍。我在实际项目里跑出过一次几十个Key没翻译如果没检查就发版那批界面全是Key名玩家肯定炸了。5. 一些可以立刻用上的小技巧最后分享几个我在实际使用中总结的经验不一定在大框架里但每次都能救命。技巧一给所有语言文本预留一个“字体缩放系数”。我以前做德语适配时按钮老是放不下后来在LanguageManager里写了一个fontScale配置德语设为0.9日语设为0.95。LocalizedText在Refresh时把基础fontSize乘以这个系数问题解决一大半。这个比单独做布局容易多了。技巧二在开发阶段把LanguageManager模拟成“随机语言模式”。只要在编辑器里点击一个菜单项工具就把项目里所有文本随机切换成目标语言并截图。连续跑几次能自动收集到大量“文本溢出”的截图省人工检查。这个思路是从自动化测试那儿学来的对UI适配特别有用。技巧三翻译表入库之前先跑一遍“占位符一致性检查”。比如原文是{0} coins翻译公司给成{0}枚コイン没问题但经常有人把{0}删了或者写成[0]。工具里加一个检查所有翻译文本里的占位符集合必须和源语言一致。这个检查能拦住至少30%的低级错误。技巧四构建前自动压缩空白Key。有时翻译表里某条文本是空白LocalizedText会显示成空字符串这是合法的有些界面故意留空但更多时候是漏填。所以在构建前检查一下“空白翻译”数量如果不是故意为空直接报错。技巧五本地化测试时要切到“假长文本”模式。工具可以把所有文案自动替换成超长字符串比如每行都变成“xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”用来测试Ui布局是否足够弹性。这个模式跑一遍能发现许多隐藏的裁切问题。多语言转换工具算不上特别高级的技术但它把本地化从“体力活”变成了“流程活”。我花了大概两周把它磨到顺手之后所有项目都直接复用省下的时间早就值回票价了。如果你正在被多语言问题折磨别急着找重插件先按这篇文章的思路做一个最小可用版本用完再慢慢加功能。动手做一次比看十篇教程都管用。 
长河君 · 2026/10/14 3:32:49 · 阅读 1.2k Unity多语言转换工具：从CSV到运行时本地化切换的完整实践
做游戏出海的团队十有八九都被“多语言”折腾过。最早的项目通常是在场景里直接写死中文等版号、发行、海外代理一聊发现要加英文、日文、韩文整个人都麻了。手动去场景里一个个改Text组件几百个界面改到天亮。于是就有了这个Unity多语言转换工具它帮我把翻译表Excel/CSV一键转成游戏内的本地化数据自动替换场景里的硬编码文本运行时切换语言即时刷新。核心思路就是“文本ID 翻译映射”配合编辑器扩展把重复劳动压到最低。适合Unity开发者、独立游戏制作者、以及所有正在补课国际化的团队尤其是手上已经有存量项目、不想推倒重来的人。我在这里把整个工具的设计思路、关键代码、实操流程和踩坑记录都摊开讲。不是教科书式的“最佳实践”而是我实际用了一段时间、改了又改之后留下的东西。看完你能直接照着抄一套适合自己的版本。1. 多语言工具的定位与整体设计思路1.1 先想清楚你需要的是一把“螺丝刀”还是“数控机床”很多教程一上来就推全套本地化插件什么组件替换、自动收集、热更新、字体回退一条龙。但大而全的框架往往在小项目里变成累赘。我自己最早犯过的错就是追求“一步到位”结果工具本身比手改还费时间。做多语言工具之前先问三个问题项目规模多大是10个界面还是100个界面发布语言有多少只是简繁英还是包含阿拉伯语、泰语这种布局差异很大的语言谁在填翻译是程序自己填还是策划/外部翻译公司提供表格想清楚再去选方案。规模小直接写一个静态字典类就够了规模大才需要编辑器窗口、自动扫描、Addressables加载。我这套工具走了中间路线编辑器侧负责“转换”和“替换”运行时侧只保留一个轻量管理器。它不管美术图集、音频本地化那些重活专注解决最常见的文本翻译问题。这样代码量可控也容易维护。1.2 关键技术选型表格、资源、组件三件事一个Unity多语言转换工具说白了就是把三件事串起来表格数据翻译的源头。最常见的是Excel/CSV每行一个文本ID每一列对应一种语言。Excel方便翻译公司填写但Unity不能直接读CSV是纯文本容易解析但Excel另存为CSV时编码容易踩坑后面细说。数据存储游戏运行时能快速读取的数据。两种选择ScriptableObject或者Json/二进制。ScriptableObject的优势是Unity原生支持Inspector里可视化检查还能挂自定义Inspector做翻译统计Json则适合走热更新或者和远端表格联动。我选了ScriptableObject因为转换工具跑完之后直接在编辑器里生成asset文件打包时自动包含零额外IO。UI组件场景里到处放着的Text、TextMeshPro。多语言工具要做的是要么把Text组件替换成支持本地化的组件要么在生成阶段自动为每个Text挂上本地化脚本并绑定Key。我选择后者——写一个LocalizedText组件通过ContextMenu或者编辑器扫描自动附着不改变原有的Text层级和样式。1.3 为什么坚决不用“字符串匹配”来做翻译可能有人说我运行时把界面上的中文拿去查表查到对应的英文不就行了比如text.text是“确定”查表发现“确定OK”于是改成OK。这听起来很美但实际会崩同一个文案在不同界面可能微调比如“确定”和“确 定”带空格匹配不上。字符串重了“删除”可能是按钮上的操作也可能是提示文案里的动词翻译目标完全不同。拼写敏感一个标点不一样就漏匹配。只要翻译公司手滑改了一个字符原来的中文Key就作废了。所以我坚持“文本ID 当前语言文本”的方式。界面组件只认Key比如btn_confirm运行时根据当前语言查表得到“确定”还是“OK”。用Key代替原文有几个好处翻译更新不影响代码逻辑同一个Key多处使用改一处全部生效还方便做自动检查——没翻译的Key能统计出来。2. 核心功能拆解与实现细节2.1 翻译表的导入与导出Excel / CSV / JSON 的兼容设计工具的第一步是把翻译表吃进来。我给的模板很简单第一行是标题key, zh-CN, en-US, ja-JP btn_confirm, 确定, OK, 確認 btn_cancel, 取消, Cancel, キャンセルExcel里可以直接用这个格式。工具里我支持两种导入方式直接用File.ReadAllLines解析CSV或者用ExcelDataReader/NPOI读xlsx不依赖Office。这里有个重要细节——CSV必须按UTF-8 with BOM读取否则Windows中文环境容易乱码。在Unity里我建议自己加一个编码嗅探或者强制要求翻译表另存为UTF-8。我最开始用默认编码读CSV中文全变问号查了半天才发现是编码问题。解析之后存成一个LanguageTable对象[Serializable] public class LanguageData { public string key; public Liststring translations; // 与LanguageDef.languages顺序一致 } public class LanguageTable : ScriptableObject { public Liststring languages; // [zh-CN, en-US, ja-JP] public ListLanguageData entries; // 每行数据 }导出逻辑就是生成的ScriptableObject资产。除此之外我还留了一个“导出未翻译Key”的功能遍历所有已注册的Key再查表里是否存在对应语言的翻译缺失的汇总到CSV里方便丢回给翻译公司。2.2 自动替换场景中的硬编码文本存量项目最大的痛点就是旧场景里散落着上千个写死中文的Text。让我手动一个个改成Key那不如去死。所以工具里必须有一个“扫描替换器”。它是这样工作的用户指定一个需要处理的场景/Prefab文件夹。工具遍历所有Text组件和TextMeshPro组件。读取text.text的值把它当作“原文翻译表”的反向查找键在已有的表中搜索这个值在源语言比如zh-CN对应的Key。能找到Key就直接给这个Text挂上LocalizedText组件并设置key。找不到Key就把该文本收集为“新增待译条目”追加到翻译表中并自动生成一个新的Key比如ui_00123同时挂上组件。这个流程有一个取舍它依赖于已有的翻译表反向查找如果项目完全没有旧翻译表就需要先人工整理一遍场景文案。我在实际使用时第一次把公司的老游戏扫描完生成了三百多个Key然后花半天把重复文案去重把语义不清的Key改名。这个代价是可以接受的毕竟只做一次。扫描替换器的核心代码思路如下简化版[MenuItem(Tools/Localization/Scan And Replace Selected Scenes)] public static void ScanAndReplace() { var allTexts FindAllTextComponentsInSelection(); foreach (var text in allTexts) { string source text.text; string key LanguageTable.FindKeyByOriginal(source); if (string.IsNullOrEmpty(key)) { key AddNewKeyToTable(source); // 自动生成key记入表 } var localized text.gameObject.AddComponentLocalizedText(); localized.SetKey(key); } EditorUtility.SetDirty(table); AssetDatabase.SaveAssets(); }注意事项处理完之后一定要先做一次Prefab Apply因为自动添加的组件默认只保存在场景里如果不Apply你Prefab上其他实例不会同步。这个坑我踩过后来在工具里加了强制Apply提示。2.3 运行时切换语言与事件通知转换工具生成的资产只是数据游戏运行时还需要一个中央管理器来“翻译”和“广播”。我写了一个极简的LanguageManagerpublic class LanguageManager : MonoBehaviour { public static LanguageManager Instance { get; private set; } public LanguageTable table; public string currentLanguage zh-CN; public event System.Action OnLanguageChanged; private void Awake() { Instance this; } public void ChangeLanguage(string lang) { if (currentLanguage lang) return; currentLanguage lang; OnLanguageChanged?.Invoke(); } public string GetText(string key) { var data table.GetEntry(key); if (data null) return key; int idx table.languages.IndexOf(currentLanguage); if (idx 0 || idx data.translations.Count) return key; return data.translations[idx]; } }每个LocalizedText组件注册到OnLanguageChanged事件里切换语言时统一刷新public class LocalizedText : MonoBehaviour { public string key; private Text _text; private TextMeshProUGUI _tmp; private void Awake() { _text GetComponentText(); _tmp GetComponentTextMeshProUGUI(); if (LanguageManager.Instance ! null) { LanguageManager.Instance.OnLanguageChanged Refresh; } Refresh(); } private void OnDestroy() { if (LanguageManager.Instance ! null) LanguageManager.Instance.OnLanguageChanged - Refresh; } public void SetKey(string newKey) { key newKey; Refresh(); } public void Refresh() { string value LanguageManager.Instance.GetText(key); if (_text) _text.text value; if (_tmp) _tmp.text value; } }这个方案的关键点是不要用Update轮询一定要用事件。场景里如果有几百个Text每帧轮询会造成无谓的字符串比较尤其移动端很伤性能。事件驱动只在语言切换那一刻刷新所有界面成本极低。如果项目用了UI框架比如UGUI的Button里的Text尽量把LocalizedText挂在Text同一个物体上它自动会处理Button的显示。如果界面是通过代码动态创建的Instantiate出来的记得在生成后调用一次localized.SetKey(key)或者保证LanguageManager已经存在并且Awake里注册事件后会自动刷一遍。2.4 富文本、参数占位与动态拼接的处理实际项目里很少有用纯静态文案的地方。比如“金币不足需要再充值XX元”这种文案你不能把整句话丢给翻译表因为那个数值是动态的。翻译公司也不会喜欢一句话里有需要翻译的数字。我的处理方式文本里用{0}做占位符Key存储的是模板。运行时填充key: shop_coin_not_enough zh-CN: 金币不足还差 {0} 个 en-US: Not enough coins! Need {0} more! ja-JP: コインが足りません。あと{0}個必要です获取文本的接口重载一个带参数版本public string GetText(string key, params object[] args) { string format GetText(key); if (args.Length 0) return string.Format(format, args); return format; }这个必须注意不同语言的语序不一样。中文说“还差10个”日语说“あと10個必要です”如果你是拼接而不是占位符那日语就全乱了。所以尽量把数字、名字都作为参数。而且{0}的顺序在各个语言的翻译里可以打乱比如中文是“{0}个金币”英语可以翻译成“{0} coins”不一定保持原顺序。string.Format支持按顺序填充但如果你有多参数可以区分命名。比如{name}这种命名占位符在Unity里用string.Format不支持我用的是简单正则替换public string GetText(string key, Dictionarystring, string args) { string result GetText(key); if (args ! null) { foreach (var kv in args) { result result.Replace({ kv.Key }, kv.Value); } } return result; }这种命名占位符对翻译更友好建议大小项目都用这个。富文本也要小心。TMP里支持color#ff0000红色/color这种标签也会跟着翻译。如果原文是“开始{0}”这种很容易和占位符混淆。我遇到过一次原文本里包含b{count}/b结果在日语环境里富文本标签被翻译公司改坏了。我的方案是约定翻译表中不允许出现尖括号富文本标签全部由程序拼装不在翻译表里出现。如果确实需要一段富文本就拆成多个Text拼接或者提供纯文本的“描述字段”。3. 实操过程与完整流程演示3.1 工具目录结构与自定义编辑器窗口为了让工具用起来方便我建了独立的目录结构Assets/ Localization/ Editor/ LocalizationToolWindow.cs LocalizationScanner.cs Runtime/ LanguageManager.cs LocalizedText.cs LanguageTable.cs Data/ LanguageTable.assetLocalizationToolWindow是一个继承EditorWindow的类用MenuItem(Tools/Localization/Open Window)打开。窗口里放四个按钮导入CSV/Excel扫描当前场景/选中Prefab导出缺失翻译生成语言常量类生成语言常量类是我后面补充的功能它会把所有翻译Key生成一个静态字符串常量写代码的时候不用手敲public static class L { public const string btn_confirm btn_confirm; public const string btn_cancel btn_cancel; }这样以后在代码里写GetText(L.btn_confirm)避免Key拼写错误。而且IDE有自动补全再也不会出现Key打错导致运行时显示Key名的情况。3.2 写一个最小可用的本地化管理器除了上面贴的代码还需要完善一下LanguageManager的初始化。项目启动时一般是场景里放一个“App”物体挂上LanguageManager把LanguageTable.asset拖进去。如果不想手动拖可以在Awake里用Resources.Load加载if (table null) table Resources.LoadLanguageTable(LanguageTable);这样工具生成的asset只要放在Resources目录下就能自动找到部署起来省事。如果用了Addressables也可以改成Addressables.LoadAssetAsyncLanguageTable(LanguageTable)但要注意异步加载时序UI要在异步完成后再初始化。我建议项目初始化流程是这样的LanguageManager.Awake加载表注册事件。启动语言设置PlayerPrefs或服务器下发。调用一次ChangeLanguage(saveLang)。各场景的LocalizedText在Awake时已经订阅事件收到刷新通知后自动更新文本。这个顺序最重要的一点是LocalizedText的Awake发生什么时机如果是启动场景LanguageManager先Awake如果是动态场景可能LocalizedText先Awake此时LanguageManager可能还没加载完成。所以我在LocalizedText里加了一个容错private void Refresh() { if (LanguageManager.Instance null || LanguageManager.Instance.table null) { // 延后到下一帧再刷新 Invoke(nameof(Refresh), 0.1f); return; } // ...正常设置文本 }这个“延后重试”可能看起来笨但实际处理各种加载顺序很管用。后来我改成用协程等待一帧也比直接return好得多。3.3 从翻译表到游戏内语言的端到端测试我以一个简单的“设置界面”为例走一遍完整流程。场景里有两个按钮分别显示“确定”和“取消”另外有一个提示文本“金币不足”。我把这些中文文案整理到Excel表格里按上文格式填入Key列和zh-CN列。调用工具的“导入”生成LanguageTable.asset同时窗口显示已导入的条目数。对着“设置界面”场景执行“扫描替换”。工具自动给每个Text挂上LocalizedText组件并把key绑定到对应的翻译条目。保存Prefab进入Play模式。在运行时控制台用LanguageManager.ChangeLanguage(en-US)观察所有文本是否需要即时变为英文。这个过程如果顺利从零到跑通只需要十几分钟。前提是翻译表里已经填了英文。如果还没有外文翻译可以先用拼音或占位符测试流程确保机制没错再交给翻译团队补充。这里有个经验初期测试时只放两个语言列不要十几种语言一锅烩。因为每多一种语言审核工作量和字体资源都会翻倍。先跑通中英再逐步加日韩、德法、阿拉伯语每一步单独验证。4. 常见问题与排查技巧实录4.1 乱码问题UTF-8 BOM、Excel导出坑、CSV分隔符乱码是本地化工具的第一个拦路虎。我遇到的乱码分三种从Excel另存为CSV时默认可能是ANSI编码中文在Unity里读出来全乱。解决用Excel插件导出UTF-8或者在工具里读取时自动检测并转换。CSV用逗号分隔但英文翻译里经常含有逗号。比如Operation, please wait直接Split(,)会把一个文本切成两段。解决用成熟的CSV解析库或者规定翻译文本中不允许出现裸逗号必须用中文逗号或全角逗号。中文Excel单元格里包含换行符导出CSV时如果没加引号包裹会把一整行拆掉。解决所有文本单元格在导出CSV时都用双引号包裹内部换行符转义。在Unity里最稳的读取方式是var lines File.ReadAllLines(path, Encoding.UTF8);前提是文件必须是UTF-8并且不带BOM也一般没问题带BOM也不影响ReadAllLines。但如果用File.ReadAllText再SplitBOM会导致第一行第一个Key前面多出一个不可见字符所以用ReadAllLines可以避开这个坑。4.2 文本长度与排版溢出德语、法语比英文长很多多语言最恶心的不是翻译是界面放不下。德语比英文平均长30%法语也差不多俄罗斯语更长。按钮宽度固定的话英文是“OK”德语可能变成“In Ordnung”直接超出边界。我为此在工具里加了一个“文本长度估算”预览切换语言时在Inspector里用Font.GetCharacterInfo估算每个Key在当前字体下的像素宽度并对照UI的RectTransform宽度做警告。但更实用的做法是在UI设计阶段就预留好伸缩空间按钮不要固定宽度设置ContentSizeFitter并留padding文本区域允许折行但要注意某些语言禁止在特定位置换行泰语、缅甸语需要按词换行UGUI的horizontal overflow默认设为Wrap动态调整字号给LocalizedText加一个autoShrink选项当文本实际宽度超过Rect宽度时调用tmp.fontSize * 0.9循环降字号直到放得下。这是应急方案能覆盖80%的溢出问题对于关键UI比如商店价格标签最好做单独的本地化版面而不是指望一套布局通吃所有语言。实际上很多发行商在本地化测试时会截一堆“文字被切断”的图反馈回来提前用“最长语言模式”比如德语跑一遍UI截图对比能省去很多来回沟通。4.3 动态字体、东亚字体与回退字体非英语语言对字体要求很高。中文字体动辄几MB到十几MB日文、韩文也都有自己的字符集要求。如果项目里只打包了一款拉丁字体切到中文时全部显示成方块。处理方案简单粗暴每种语言用一套字体切换时在LocalizedText里同时换font和material。但这会导致多语言包体剧增加载卡顿。用动态字体Unity 2018支持Font.CreateDynamicFontFromOSFont或TMP_FontAsset动态字体只打包字体数据子集运行时从系统加载。但不同机型系统字体缺失显示效果不稳定。回退字体机制TMP从4.0开始有TMP_Settings.fallbackFontAssets可以设置多个回退字体。我用了一个开源字体比如思源黑体/Noto Sans作为中英日韩的共同字体再把系统字体作为回退兜底。写代码时用TMP_Settings.SetFallbackFonts把多语言字体都塞进回退列表里这样TMP会自动找到包含对应字符的字体省去手动切换。对于老式UGUI Text它不支持回退字体。所以新项目尽量全部用TMP老项目我也会在工具扫描时直接把Text替换成TMP的组件一劳永逸。不过替换组件的操作会丢失一些样式属性需要做迁移映射比如fontSize映射到fontSizecolor映射到coloralignment映射到alignment。这块工程量不小但做一次以后就清净了。4.4 特殊语言处理阿拉伯语/RTL、泰语换行、日语标点真正专业的本地化避不开这些坑阿拉伯语/希伯来语从右往左RTL。UGUI Text虽然有个RTL选项但只对基础字符有效混合数字和拉丁字母时排序会乱。我测试过最简单的支持方式是使用TMP 3.0内置的RTL支持配合阿拉伯语显示修复组件比如ArabicSupport插件。工具里我提供一个ForceRTL开关在切换语言为ar/fa/he时自动设置Text组件的alignment TextAnchor.MiddleRight并启用RTL。但如果是复杂UI建议美工直接出RTL版本的布局程序只能保证文本正确不能保证布局镜像。泰语没有空格词与词之间没有间隔换行容易断错。UGUI按字符换行泰语字符可以接受断行但要注意泰文上方有音调符号换行时可能显示错位。解决泰语使用专门字体行高要调大不然上方附加符号会被裁掉。日语标点日文逗号是“、”句号是“。”英文标点和日文标点混用会很难看。这个只能靠翻译质量工具没法自动修但可以在预览窗里高亮标点让审核容易发现。这类特殊语言在工具里加分项是“语言特性预设”。我建了一个配置表每种语言有默认字体、对齐方式、行高倍率、是否需要RTL、是否字符换行等。这样切换语言时LocalizedText除了更新文本还会自动调整这些参数。否则光靠翻译公司是搞不定显示细节的。4.5 构建时资源裁剪与语言数据裁剪很多出海游戏希望包体越小越好。多语言翻译文本本身没几个KB但字体是真的大。如果你为每种语言都打包一套字体包体直接爆炸。我的做法翻译表永远全量打包因为文本数据几十种语言也不过几百KB不值得做分包。字体在构建时按需裁剪用Addressables把每种语言的字体单独打成AssetBundle运行时按当前语言加载。中文字体虽然十几MB但每个字体打包后经过压缩可能只有几MB。如果确实太占空间可以考虑只打包常用字运行时用系统字体回退或者使用Unicode子集工具预裁剪字符集。有个取巧的办法先用翻译表里所有Key的所有翻译文本统计出需要哪些字符然后生成一个包含这些字符的字体子集。很多中文字体可以用工具自动裁剪到一两千字画质影响不大但包体从十几MB减到2MB。Unity有开源插件FontSubsetter可以实现这个。4.6 版本迭代时Key管理废弃Key、漏翻译、自动检查游戏版本更新后代码里删掉了一些旧文本Key翻译表里还留着几百条永远用不到的记录新加了一堆文案可能忘了进表。没有工具辅助的话过两三个版本翻译表就是一团乱麻。我在工具里做了三类检查漏翻译检查遍历所有LocalizedText的Key查当前语言表缺失的列到文件里。废弃Key检查遍历项目所有脚本和场景找出翻译表里有但代码里没有引用的Key标记为“未使用”人工确认后可以删除。Key命名规范强制Key用小写下划线命名禁止空格和特殊字符方便生成代码常量。检查功能做成菜单项每次发版前跑一遍。我在实际项目里跑出过一次几十个Key没翻译如果没检查就发版那批界面全是Key名玩家肯定炸了。5. 一些可以立刻用上的小技巧最后分享几个我在实际使用中总结的经验不一定在大框架里但每次都能救命。技巧一给所有语言文本预留一个“字体缩放系数”。我以前做德语适配时按钮老是放不下后来在LanguageManager里写了一个fontScale配置德语设为0.9日语设为0.95。LocalizedText在Refresh时把基础fontSize乘以这个系数问题解决一大半。这个比单独做布局容易多了。技巧二在开发阶段把LanguageManager模拟成“随机语言模式”。只要在编辑器里点击一个菜单项工具就把项目里所有文本随机切换成目标语言并截图。连续跑几次能自动收集到大量“文本溢出”的截图省人工检查。这个思路是从自动化测试那儿学来的对UI适配特别有用。技巧三翻译表入库之前先跑一遍“占位符一致性检查”。比如原文是{0} coins翻译公司给成{0}枚コイン没问题但经常有人把{0}删了或者写成[0]。工具里加一个检查所有翻译文本里的占位符集合必须和源语言一致。这个检查能拦住至少30%的低级错误。技巧四构建前自动压缩空白Key。有时翻译表里某条文本是空白LocalizedText会显示成空字符串这是合法的有些界面故意留空但更多时候是漏填。所以在构建前检查一下“空白翻译”数量如果不是故意为空直接报错。技巧五本地化测试时要切到“假长文本”模式。工具可以把所有文案自动替换成超长字符串比如每行都变成“xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”用来测试Ui布局是否足够弹性。这个模式跑一遍能发现许多隐藏的裁切问题。多语言转换工具算不上特别高级的技术但它把本地化从“体力活”变成了“流程活”。我花了大概两周把它磨到顺手之后所有项目都直接复用省下的时间早就值回票价了。如果你正在被多语言问题折磨别急着找重插件先按这篇文章的思路做一个最小可用版本用完再慢慢加功能。动手做一次比看十篇教程都管用。