多语言素材管理
24 Mar 2022中文素材管理
国内版号日渐收紧，为了游戏能及时上线，选择海外发行是近年来国内游戏厂商不得不选择的方式。
在对发行游戏进行本地化处理时，首要处理的就是文本，尤其是带中文的 UI 素材。通常的做法，是由美术管理素材，挑选出带中文的素材，再进行本地话处理后替换。
为了能降低这一步的人力，可能在项目初期就立下规则怎么管理这种素材，一般由以下几种做法。
- 带中文的素材，美术输出后需要使用特定命名，如名字内要包含 “word”
- 为了降低素材冗余，客户端会要求把样式一致的素材切分成艺术字和背景图，本地化只需处理艺术字部分。
咋的一看好像没什么问题，但是实际上执行难度很大，如果是项目初期定下规则还好，迭代起来也不会很麻烦。如果是项目中后期开始执行，就问题多多，一来资源量上来了，手动处理耗时长，二来项目人员来来去去，美术不一定都知道这一规则，就导致返工。
其实这里面还有更要命的问题，会影响代码逻辑.
试想一下，前端需要显示一张图片，实际图片路径 = “pic/” + 配置表id + “_icon.png”。但是并不是所有图标都带中文的，那么带中文和不带中文的图片命名就会不一致，无法使用这样的路径拼接。
所以一个更好的做法是在不改资源名称的前提下，管理中文素材。
- 遍历素材，把带中文的存入 txt_pic.json 中
- 项目迭代，对变更的素材进行遍历，更新 txt_pic.json
这样一来，程序对多语言无感，美术无需心心念念资源的命名。
将数据存入 json 的方式还是要程序提供可视化工具。
不过第一次处理 txt_pic.json 量还是打，很耗时间。项目后期所有的 UI 资源大概会有 30000 个，带中文的将近 8000 个。
那么有没有办法更近一步降低这方面的压力的？
OCR
都 2022 年了，图文识别这种这么成熟的技术，为什么不用在这上面呢？Just do it
Why paddle
PaddleOCR 是我在试用 EasyOCR 后的选择，看的博客说 EasyOCR 辨识度高，然而我测的结果是中文识别上 paddle 更优，也许是因为开发组是国内的百度吧。
PaddleOCR 还有中文教程，非常 nice
初步使用
看完教程，paddle 非常容易上手，但是要想自己调整参数，调整模型，对我这种甚至才刚入坑 python 人来说，还是太难理解了。先用～
识别失败调整
调整模型
提速
CUDA
架设OCR服务器
降低项目组员的使用门槛
python 环境加上 150M 模型，每个人从头搭建，还是有点麻烦的。