多语言UI不匹配问题（日）

前言

最近在做日文版的UI问题，美术那边很快啊，将语言换成日语后的UI不匹配问题直接截图朝程序这里一扔就没动静了。我一边改一边看，没多久，40条问题变60条，60条变80条，我相信，还有很多，只是他们没有发现，或者已经放弃治疗了。

多语言问题已经是游戏界老生常谈的话题了，但没人提醒的情况下我们都不容易注意到这方面，我在改完美术提出来的那些问题后总结了一些多语言UI需要注意的事项，希望之后在做UI的时候考虑到这方面，可以减少很多多语言相关的工作量

美术篇

我认为做事情方向最重要，而美术就正好是给出了做一个UI界面的方向，所以我排在最前面。
在设计UI之初应该预先考虑多语言支持，以留出足够的空间和灵活性来处理不同的文本长度差异。

案例：
这里是个人信息设置界面，是一个典型的排版问题
修改前：

修改后

上面这些还好，虚空几乎全是类似的排版问题，UI文字和文字，图片和文字等分布太过密集，程序想改都无从下手

程序篇

美术也是要追求美观的嘛，如果有一些灵感就是需要这样排版布局UI才好看，多语言什么的才不想考虑呢，那这时候就轮到程序出场了，毕竟惯着美术和策划就是程序的工作嘛

问题一：文本超出预期界面

那程序这边遇到的最多的问题就是文本超出预期界面的问题了，贴一张图想必你就知道是什么问题了

很明显，文本超出了界面，遇到这种情况，一般会采取字体字号自适应的方式来根据文本框长度调整字体大小
需要知道的是，不是所有的地方都无脑做自适应，而是要满足以下基本原则：

1.附近没有类似的工整的排版，而是独立的一个UI
比如说上图的几个选项，选项内的内容字体大小高度统一，这个时候就不能做自适应。因为做了自适应之后，如果有一个选项的内容过长，就会出现下面的情况

2.如果不满足第一点的条件，但确实需要调整字体，那么字体的变化范围应该在2-4号之内
以科研界面为例：
修改前：

修改后：

这里的字号其实是不一样的，但是没办法，稍微大一点就又越界了，但是在最大字号20的情况下，最小字号设置为18，那么1~2号的字号差其实也不是那么影响美观了。

3.如果是标题，那么该字体的最小字号应该比内容的最大还要大至少5号
标题虽然字更多需要缩小字号，但最小字号不应该比副标题小
这种情况下应该拉长主标题的文本框，使得文本不会过早变小

问题二：未设置文本和图片的相对位置

这个问题遇到的频率也是数二数三的，不多说，上图：
封印物镶嵌界面：

台下的美术得发话了：欸欸欸，这可不关我的事呀，我设计的这么好。
那我只能说：完全正确！这个和接下来的那个问题就是纯纯程序的锅，我也没想到，这种设置相对位置的问题居然会有这么多。只能说还是缺少应对变化文本的意识吧，就不说多语言了，后期策划想把这个界面换个超长的名字，那也得出问题。

最终的效果是这样的，无论文字长度怎么变化，帮助图标始终在文字右侧固定距离：

我相信大家都会设置相对位置，所以我这里就不提解决方法了，唯一需要注意的是如果在修改预制体的时候改变了object的父子关系，那么一定要去查看对应界面的代码是否是通过transform.Find来找这个object的，如果是，请修改该代码。

自然而然的，如果你不幸修改的是一个通用的预制体（就是不止这一个界面在用，其他地方可能也用到了） 那么恭喜你，接下来你要先查看这个通用的预制体被哪些地方用到了，然后去对应地方修改代码，然后找到对应界面进行测试。这一串跑下来，我相信你对项目的熟悉程度会更进一步！

问题三：文本超出背景框

这个问题和问题一有着异曲同工之处，只不过这里涉及到Relation脚本的使用，所以单独拿出来讲。
先上图，直观的感受是什么问题：

很明显，这是一个背景没有做自适应的问题，所以这里需要强调的是，所有有背景图的文字都要考虑到做自适应的问题。

做背景自适应有很多方法，但我发现咱们时光早就有前辈写了工具来高速做自适应。
这就是Relation脚本
这里直接上如何使用该工具做背景自适应

1.确保你的文本框是背景图的子节点
2.在文本框的object下挂两个组件：ContentSizeFitter和Relation
3.如果你想背景横向自适应，那么设置ContentSizeFitter的HorizontalFit为PreferredSize
4.添加Relation脚本的Transform和Types节点各一个（需要注意的是这两个是一一对应的关系，每添加一个transform必须有一个type）
5.将你的背景图的object拖动到Transform处，Types为你想要背景图变化的方向，这里选择Width，表示子物体的横向大小变化会同时改变父物体的Width
6.这样在文本长度变化的时候ContentSizeFitter就会动态改变文本框长度，同时父类的Width会根据子类的长度变化而变化，达到了自适应的效果
7.值得一提的是因为代码实现是根据父类初始长度加上子类运行时长度来决定父类运行时长度，所以需要调整父类初始长度来保证UI的美观

不知道纯文字能不能传达我想表达的意思，不过这个脚本也不复杂，研究一下都能看懂。
这个脚本的牛逼之处在于它不只是做背景图自适应，甚至能用来做UI界面的长度自适应，科研界面就是用的这个脚本做的，我之前在做摇摇乐的界面长度自适应的时候困扰了好久，最后用的DynamicListView配合Dynamic才做好的，而且会有一些小bug，用这个来做又快又好，何乐而不为

翻译篇

其实我一开始也去网上查了一下其他游戏公司都是怎么做多语言工作的，得到最多的回答居然是：找个好翻译！
晴天霹雳！
真特么有道理，如果我翻译出来和原本长度差不多，那美术还考虑个屁，程序还做个鬼的自适应，怎么轻松怎么来。
不过也就想想了，日语出了名的长，还是别为难翻译大哥了，只能说在某些地方只能翻译上面做文章的时候找找就好了

不过找翻译的地方应该挺多的，看看下面这个图，这翻译出来名字要是稍微长一点，你不找翻译那程序一点办法都没有，美术看了也摇头（不想重做啊啊啊啊）