简介：围绕 Android 项目与框架中字符串资源分散、难以快速筛选和统一翻译的问题，这份 MediaTek 字符串翻译工具（STT）面向应用开发者和本地化工程师，用于简化多语言本地化流程，便于在项目内集中处理字符串资源。压缩包共 11 个文件，约 11.41MB，以可执行 jar 与依赖 jar 为主体，辅以 sh、bat 启动脚本和一份 PDF 用户手册，覆盖工具运行、命令行调用与操作说明等用途。已有 230 人学习，说明其在 MTK 平台本地化场景中具有一定参考价值。读者可借助工具完成字符串提取、筛选与翻译流程，结合手册快速理解参数与批量处理方式，减少手工整理资源文件的时间；依赖库与脚本一并提供，也便于在本地环境直接搭建运行，适合需要处理 Android 多语言资源的初中级开发者与本地化人员参考。

1. 开装前的环境盘点：TranslationTools v3.1511.01 为什么双击就能运行

上周帮一个做资料整理的 A 同学收拾机器，他把 TranslationTools 装了三次，每次双击都弹一句「计算机中丢失 MSVCP140.dll」。不是包坏了，是他把这款翻译辅助工具当成纯绿色软件——从下载目录直接双击 exe，路径里还带一层中文文件夹名。TranslationTools_exe_v3.1511.01 这个包确实是解压即用的形态，但它对系统运行库、目录写权限、取词钩子的权限级别一样都不含糊。装对了，它是看外文文档时最省事的那层辅助；装错了，划词不弹窗、热键被输入法抢走、界面全是方块字，能把人折磨到怀疑包有问题。下面按我自己装机的顺序走：解压、补运行库、配引擎和热键、排错，最后落到怎么验证它真的跑通了。

2. 解压与目录规划：exe 放哪个盘、路径里为什么不能有中文和空格

2.1 先算哈希再解压，别在 zip 里直接双击

很多人拿到压缩包的第一反应是双击进去，找到 TranslationTools.exe 双击运行。Windows 资源管理器在这种情况下会把文件解到%Temp%下的一个随机目录，程序启动时读配置、写日志、加载词典全在那个临时目录里完成。等到你重启机器，临时目录被清理，第二天打开发现热键没了、词典空了，还以为程序有毛病。这类「配置丢一半」的坑，八成就是这种双击造成的。

我一般的做法是先把包落到一个固定位置，算一遍哈希留档，再用命令行解压到目标目录：

# 1) 记录压缩包哈希，以后换机器或重下时能对一下是不是同一个包 Get-FileHash -Path "D:\Downloads\TranslationTools_exe_v3.1511.01.zip" -Algorithm SHA256 | Format-List Algorithm, Hash, Path # 2) 解压到指定目录，而不是双击进 zip 里直接运行 # -Force 表示目标目录已存在时覆盖同名文件 Expand-Archive -Path "D:\Downloads\TranslationTools_exe_v3.1511.01.zip" ` -DestinationPath "D:\Tools\TranslationTools\v3.1511.01" -Force

Get-FileHash的-Algorithm SHA256是默认值，写全是为了让输出可读；把 Hash 那一行抄进你的装机记录里，将来程序行为诡异时能先排除「包被换过」。Expand-Archive的-Force只覆盖文件，不会删掉目录里多出来的旧文件，所以升级版本时别图省事往同一个目录覆盖，宁可新开一个v3.1511.01这样的版本号目录，再改配置指过去。

如果包内层级很深或者文件名带非 ASCII 字符，Expand-Archive偶尔会解出乱码名，这种情况换成 7-Zip 的命令行7z x更稳妥，解压后再核对一遍目录里的文件数是否和压缩包内一致。

2.2 安装路径的三条硬规矩

路径这件事属于典型的玄学——同一个包，放D:\Tools\TranslationTools能跑，放C:\Users\某某\桌面\新建文件夹\就各种取词失败。三条规矩我一直在守：

第一，路径里不要有中文。取词模块在注入目标进程时要做路径转换，中间某一层用了系统默认代码页处理，中文路径就可能变问号，表现是程序能启动但词典加载为 0 条。第二，路径里不要有空格，尤其别放Program Files。第三，不要放桌面和下载目录，这两个目录经常被同步工具或清理脚本扫到。

放在C:\Program Files下的另一个麻烦是 UAC 虚拟化：程序往自己目录写配置时被系统重定向到%LOCALAPPDATA%\VirtualStore，你在安装目录里看到的配置文件永远是最初那份，改了不生效。

# 给当前用户对程序目录的完全控制权，避免写配置时被重定向 # (OI) (CI) 表示继承到子目录和文件，F 表示完全控制 icacls "D:\Tools\TranslationTools\v3.1511.01" /grant "$env:USERNAME:(OI)(CI)F" /T

/T是递归应用到已有子项。执行完输出里应该能看到「已成功处理」的文件条目。这一步不是必须的，但在 D 盘用普通用户目录时，能省掉后面「配置保存失败」的一整轮排查。

解压完成后，目录里大致是这么几类东西，动手之前先分清哪些能改哪些不能碰：

2.3 解除文件锁定，顺手给杀软加个白名单

从网络下载的 zip 带 Zone.Identifier 标记，解压后每个文件都继承这个标记。普通程序问题不大，但 TranslationTools 这类要做全局热键和屏幕取词的辅助工具，启动时会被 SmartScreen 或杀软额外关照一轮，表现是双击之后任务管理器闪一下就没了，日志里一条记录都没有——这就是典型的黑匣子现场。

# 递归清掉「来自网络」的标记，避免被 SmartScreen 拦在启动前 Get-ChildItem "D:\Tools\TranslationTools\v3.1511.01" -Recurse -File | Unblock-File

Unblock-File做的事就是删掉备用数据流里的那个标记，不修改文件内容。第二条要做的，是把整个程序目录加进杀软的排除列表——注意是排除目录，不是排除单个 exe，因为它还会加载dict\下的词典文件、cache\下的索引文件。有些杀软对「读取其他窗口文本」这类行为敏感，加白之后仍然被拦，那就先把实时防护临时关掉做一次启动测试，确认是误报再把目录加白，别一直关着防护用。

3. 运行库补齐：.NET Framework 4.8 与 VC++ 2015-2022 的版本取舍

3.1 先查系统已装的 .NET Framework，别重复装

TranslationTools v3.1511.01 这类桌面工具，界面层基本都压在 .NET Framework 4.x 上。Win10 1809 之后系统自带 4.7.2 以上，Win11 自带 4.8 或 4.8.1，所以很多人根本不用装。但如果你是从更老的镜像装起来的机器，或者是精简版系统，缺 4.8 就会在启动瞬间报「需要 .NET Framework 4.8」。

先查再装，一条命令就够：

# 读注册表里的 Release 值，比看控制面板准 $key = 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full' Get-ItemProperty -Path $key | Select-Object Version, Release

拿到的Release数字对照一下：528040 及以上是 4.8，528372 是 Win10 2004 之后的 4.8 修订版，533320 是 4.8.1。只要大于等于 528040，这一步直接跳过；如果连v4\Full这个键都不存在，说明系统只有 4.0 甚至 3.5，那就老老实实装 4.8 的离线安装包，装完必须重启，不重启的话程序仍然会读到旧的运行库缓存。

需要提醒的是 .NET Framework 4.x 是就地升级，装了 4.8 之后回不到 4.7，某些老内部系统依赖旧版本行为时会出问题。如果是共用机器，装之前先问一句有没有别的老程序在跑。

3.2 VC++ 运行库：x86 和 x64 都得装

开头那个MSVCP140.dll缺失，就是 VC++ 2015-2022 运行库没装。这里有个很容易漏的点：64 位系统上 x86 和 x64 两个版本都要装。原因是取词模块为了能挂到 32 位目标程序上，本身通常是 32 位进程，缺 x86 运行库时表现是主界面正常，一划词就静默退出。

# 两个架构都要装，顺序无所谓，装完重启 winget install --id Microsoft.VCRedist.2015+.x64 -e --accept-source-agreements winget install --id Microsoft.VCRedist.2015+.x86 -e --accept-source-agreements

-e是精确匹配包 ID，避免 winget 模糊匹配到别的 VC 版本；--accept-source-agreements只是省掉一次交互确认。没有 winget 的机器，去下载中心拿vc_redist.x64.exe和vc_redist.x86.exe两个离线包，双击装完同样要重启。

判断是不是真的缺运行库，别靠猜。拿 Dependency Walker 或者dumpbin /dependents看一眼主程序依赖，如果列出来的VCRUNTIME140.dll、MSVCP140.dll、VCRUNTIME140_1.dll在C:\Windows\System32里找不到，那基本可以确诊。VCRUNTIME140_1.dll只有 2019 之后的运行库才有，装了 2015 版的旧包仍然会报它缺失，所以务必用 2015-2022 的合并包。

3.3 依赖装完的重启顺序

运行库装完不要直接开程序。正确的顺序是：先重启系统，重启后确认C:\Windows\System32\vcruntime140.dll和msvcp140.dll存在，再启动 TranslationTools。如果不想重启整台机器，至少重启一次资源管理器，让新的 DLL 搜索路径生效，但 .NET Framework 的更新绕不过系统重启，这条没有后悔药。

另外，装完依赖之后第一次启动建议用普通权限，别一上来就右键「以管理员身份运行」。取词类工具有一个特性：它只能取到权限级别不高于自己的程序的文本。你以管理员身份启动它，普通程序里的文字照样取不到，反过来普通权限启动，任务管理器这类管理员程序取不到。所以先用普通权限跑一遍，把常用场景覆盖到，遇到特定程序取不到再单独用管理员启动。

4. 首次启动与参数配置：词典路径、热键、取词方式的四组设置

4.1 第一次启动要做的事

首次启动会生成配置文件和词典索引，这个过程别打断。窗口出来后先不要急着划词，按顺序做三件事：确认界面语言是不是中文（有些包默认英文）、确认「本地词典」列表里至少有一条、确认日志目录下生成了当天的日志文件。这三件事对应三个子系统，任意一个没起来，后面的取词一定不顺。

配置文件的格式各版本略有差异，v3.1511.01 这类版本一般是 ini 形态，初次启动自动生成在程序目录下。如果你拿到的是自带配置的包，先备份再改：

; TranslationTools v3.1511.01 用户配置 ; 保存时用 ANSI 或 UTF-8 无 BOM，别存成 UTF-16，否则程序读到的第一个字符是 BOM，整段解析失败 [General] ; 工作目录，装完不要随便挪；挪了必须同步改这里，否则词典和缓存全找不到 WorkDir=D:\Tools\TranslationTools\v3.1511.01 ; 日志级别：0 关闭 1 只记错误 2 常规 3 调试；排查取词问题临时开到 3，查完调回 2 LogLevel=2 [Dictionary] ; 本地词典根目录，下面一层子目录就是一个词典 DictPath=D:\Tools\TranslationTools\v3.1511.01\dict ; 加载顺序，靠前的优先命中；术语表放最后但优先级最高，具体看程序里的设置 LoadOrder=basic,en2zh,tech [Hotkey] ; 划词/取词翻译热键，避开 Ctrl+Alt+字母，输入法和显卡驱动抢得厉害 Translate=Alt+Shift+T ; 截屏取词热键，做图片文档时用 Capture=Alt+Shift+S

WorkDir是整份配置里最关键的一项，写相对路径在某些版本上会被解析成当前工作目录，从快捷方式启动和从命令行启动结果不一样，所以一律写绝对路径。LogLevel平时保持 2，出问题临时改 3，改完必须重启程序才生效，日志文件在logs\下按日期分文件。

4.2 词典与离线包的导入顺序

词典导入是有顺序的，顺序错了表现是「明明装了专业词库，翻译结果还是通用词」。我一般按这个层次来：先让程序自带的 basic 词典就位，再导入通用英汉/汉英词典，最后导专业词库和自定义术语表。术语表放最后，因为它的作用是把特定译法强制覆盖掉，比如某个产品名固定译成某个词，这类条目必须优先级最高。

导入完要重建一次索引，程序里一般有「重建索引」按钮，没有的话就手动清cache\目录再启动。索引文件是二进制，跨版本不兼容，所以升级版本时cache\一定要清，留着旧索引会出现「词典列表显示 5 个，实际只加载 2 个」这种诡异现象。术语表文件建议用 UTF-8 无 BOM 保存，用 Excel 导出 CSV 时选 UTF-8，别用默认的 GBK，否则生僻字会变成问号。

4.3 热键与取词方式的取舍

热键冲突是安装后最常见的「装了但用不了」。Ctrl+Alt+字母这一类组合被输入法切换、显卡录屏、截图工具占用的概率极高，注册失败时程序通常不报错，只是按下去没反应。选热键的原则是：用Alt+Shift+字母或者三键组合，避开Ctrl+Shift、Ctrl+Alt、Win+开头的段位。改完热键先在一个记事本窗口里试，能弹出来再去浏览器里试，浏览器有自己的快捷键拦截。

取词方式一般有三种：鼠标划词、热键取当前光标处文本、截屏 OCR。划词最省事但对目标程序有要求，UWP 应用、部分 Electron 应用和游戏窗口取不到；热键取词兼容性好一些；截屏 OCR 完全不依赖目标程序，代价是慢一点。我的习惯是划词作主力、截屏作兜底，两个热键分开设置，别共用一个组合。

4.4 显示效果的两项调整

界面出现方块字，通常是系统「非 Unicode 程序的语言」和程序编码不匹配造成的，把系统区域设置改成中文（简体）并重启能解决大部分。另一种情况是个别生僻字显示成方框，那是字体缺字，换一套覆盖范围大的字体即可。翻译结果里的乱码则完全是另一回事，那是词典文件本身的编码问题，跟系统设置无关，用文本编辑器打开词典源文件看一眼前几个字节就能判断，是 UTF-8 还是 GBK 一看便知。

5. 避坑与排查：装完打不开、取词不弹窗的五条血泪记录

5.1 启动阶段的两条

现象一：双击 exe，鼠标转一圈，什么都没发生，任务管理器里进程闪一下就消失。

原因：三种可能，缺 VC++ 运行库、路径含中文或空格、被杀软静默隔离。日志一条都没有的时候，优先怀疑运行库和杀软，因为程序还没走到写日志那一步就挂了。

解决：按 3.2 的命令补齐 x86 和 x64 两个运行库；把程序挪到D:\Tools\TranslationTools\v3.1511.01这种纯英文无空格路径；到杀软的隔离区看有没有记录，有就恢复并加目录白名单。三条都做完还不行，用cd进程序目录，从命令行启动一次：

# 从命令行启动，能把加载失败的错误直接打到控制台 Set-Location "D:\Tools\TranslationTools\v3.1511.01" .\TranslationTools.exe

控制台里如果出现「无法加载文件或程序集」字样，就是依赖缺失，比看日志快得多。

现象二：弹窗提示「应用程序的并行配置不正确」。

原因：系统里存在多个版本的 VC++ 运行库，SxS 清单对不上，常见于装过一堆老软件的机器。

解决：先在「应用和功能」里把 2015、2017、2019、2022 各版本运行库全部卸掉，只保留 2015-2022 的合并包，重装后重启。这个操作会影响到其他依赖 VC++ 的程序，卸载前记一下清单，出问题好回滚。

5.2 取词与显示的三条

现象三：主界面正常，鼠标划词不弹窗，热键按下去也没反应。

原因：权限级别不一致，或者热键注册失败。取词工具只能读权限不高于自己的进程，在管理员程序窗口里划词取不到属于正常现象；热键则常被输入法抢先注册。

解决：换到记事本、浏览器这类普通程序里再试；把LogLevel调到 3 重启，日志里会明确写出热键注册成功还是失败；失败的换一组Alt+Shift+字母组合再试。如果是特定程序取不到，先用截屏 OCR 顶一阵，别在一个取词方式上死磕。

现象四：翻译结果出来一堆问号或者繁体乱码。

原因：词典文件的编码和程序读取时用的编码不一致。压缩包在不同系统之间转存过，或者中途用文本编辑器改过术语表，都会破坏原有编码。

解决：用文本编辑器打开对应的词典或术语表文件，另存为 UTF-8 无 BOM，清空cache\后重启程序重建索引。术语表从 Excel 导出的，导出时明确选 UTF-8，别用默认编码。

现象五：装好能用，重启机器后热键全部失效、词典列表变空。

原因：十有八九是当初在 zip 里双击运行的，配置写进了临时目录，重启后被清理。另一个可能是程序目录被清理脚本扫过。

解决：把程序重新解压到固定目录，确认config.ini就在 exe 同级生成，把目录从任何自动清理的白名单里排除。改完跑一次第 6 章的检查表，确认配置写的是绝对路径。

6. 装完怎么验证跑通：三组自检用例和一张交付前的检查表

装完不验证，等于没装。我交付一台机器之前固定跑三组用例，覆盖三个不同的子系统：本地词典检索、划词取词、截屏取词。

第一组，打开程序，在搜索框里输入一个常见英文单词查词，能返回释义说明词典索引正常。第二组，打开一个记事本，敲一段英文，选中后按划词热键，能弹出翻译窗口说明全局钩子注册成功。第三组，打开一张带英文的图片，按截屏取词热键框选，能识别出文字说明 OCR 模块和字体环境都没问题。三组全过，基本可以判定这套环境跑通了。

再补两条命令级的检查，比肉眼可靠：

# 1) 进程是不是从正确路径启动的（排除临时目录里那份） Get-Process TranslationTools -ErrorAction SilentlyContinue | Select-Object Id, Path # 2) 最近日志里有没有 ERROR 或异常堆栈 Get-Content "D:\Tools\TranslationTools\v3.1511.01\logs\app.log" -Tail 80 | Select-String -Pattern "ERROR|Exception|失败"

第一条命令如果输出的 Path 是%Temp%下的路径，说明你还在用错误的方式启动，回去看第 2 章。第二条命令输出为空是最理想的状态；有内容就先看时间戳，只关注本次启动之后的记录，历史日志里的旧报错不用管。

交付前的检查表我一般就照这张走：

最后提醒一句，验证阶段把LogLevel临时开到 3 排查完，记得改回 2。开着调试日志跑一天，日志文件能涨到几百兆，磁盘吃紧的机器上又是另一轮排查。从那以后我每装一台机器，都是先按这张表走一遍再交出去，省下来的时间远比填表多。希望帮到你。

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