赞
踩
市面上有很多现成的多语言组件,就比如前两年我有使用过的一个叫做i2 localize的组件。i2 localize至今都可以说是本地化组件里面功能算是齐全而且小型团队比较推荐的一个了,但是使用这个组件一年了,说实话槽点不断,原因主要是有以下几点:
1.i2 localize采用的是中间文件管理器,对于团队来说,这是个会被忽略但是非常容易导致协作效率问题的原因之一
i2 localize的本质是,在预设中挂一个localize component,我们需要在这个component里输入一个key值,然后在terms里面根据不同的语言,赋不同的value值,然后中心文件管理器(就是一个配置文件),就会把这个key值,和各个language对应的value值写进去。而原preab只保留这个term的key。在runtime环境下,它会自动在配置文件中寻找对应的key值和current language并且将对应的value值赋值进目标组件(案例的目标组件为text)中。
(具体使用规则可以参考其他博文,其实还是写的非常好的,上方图片就取自这篇)
因为每次新建一个key和一对value,都会在配置文件里新增一个条目,导致了一个很严重的问题,就是应该如何解决冲突。团队之间难免会处理各个需求里的多语言任务,各个预设都要对text做处理,于是每次上传至svn等版本管理软件,都需要小心谨慎地解决这个配置文件的冲突,如果自己的修改覆盖了别人的修改,而且别人的修改是个很细微的翻译的地方,在测试环境没有测试到就上线了直到玩家投诉,很可能得不偿失。所以对于团队而言实在不是最优解方案。
2.i2 localize对于image相关的资源引用支持并不是很好
上述说到i2 localize对text的多语言处理是怎样的,其实image的本地化与其类似,只不过写进配置文件里的value是这个图片的名称,这个预设里面会保留对各个语言的图片asset的引用,这意味着两点:1.如果其中一些语言的图片名称一致,那么这些语言环境下显示的图片只会是顺序中的第一张此名字的图片。举个例子,现在是中英文两个语言,要引用两个不同登录图,中文登录图片是asset/CN/a.png,英文登录图片是asset/EN/a.png。虽然路径不同,但是名字都是a,那么在运行英文环境的时候,只会找到引用库里的第一张图片,也就是中文登录图片“a”。
其实改掉这点很简单,有两种方式,一种是配置文件里面记录的是图片的guid,这个在unity里面很少冲突。另一种是记录路径。但是runtime环境下的资源路径实际上是和editor环境下路径有比较大出入的,而且还要考虑加密问题,自然更不一样了,所以不太推荐记录路径作为value值。
3.i2 localize并不能在打AssetBundle包的时候分语言包处理
换言之,就是预设里面要保留对各个语言的图片资源的引用关系,导致预设资源、语言A的资源、语言B的资源之间没办法分module打包。它会被unity自动打在同一个bundle里。
github传送门
解决不同语言情景下,text、image、rawimage的属性变化
解决不同语言情景下,gameObject的是否显示、rectTransform的属性变化
text-textLanguage、image-imageLanguage、rawimage-rawimageLanguage的无损转换
符合AssetBundle分语言包打包的方式,组件采用弱引用的方式,不会将资源打进同一个moudle包中
这个方案带来的痛点显而易见,在需要拓展一个新语言的时候,就需要动到每一个预设文件,如果是已上线的项目,代表着这一次拓展新语言带来的热更资源量巨大,或许会影响到非目标用户的更新体感。
后续优化方向:
1.将代码中固定的path改成配置文件供大家自由配置
2.bugfix
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。