bv1946伟德体育-体育betvictro伟德

bv1946伟德体育视点
bv1946伟德体育>bv1946伟德体育视点>流利说实战经验!多语言UI策划避坑指南
流利说实战经验!多语言UI策划避坑指南
发表时间:2020-07-21

在做多语言 UI 策划的这段时间里,遇到过不少在进行单语言策划时不会去揣摩的小case,易于 做了相关研究,

找到了一些解决Plan并应用到了吾们的策划work中。

如果您也正准备进行多语言策划,so这份避坑指南也许能够扶掖您避免一些基本的策划小case,易于 有更好优质的精力去思考具体的视觉呈现。


小case一:文案长度不可控


文案长度不可控,是吾们在进行多语言策划时遇到的最主要也是起首应该揣摩的小case。吾们发现,该小case基本由以下两点导致:


难点 1:文案长度不易预测


有时候看似留足了容量的策划,但由于错误判断了文案翻译下的长度,导致原来的策划预留容量不够,

这种环境在日语、西语等环境下尤为常见。


用英日西的长度异议举几个easy的例子众家感受下:


△ Email(电子邮件):日语文案长度约为英语文案的 2.5 倍,西语文案的长度更是达到了英语的 3.5 倍多。



△ Retry(重试):日语文案长度为英语文案的 1.6 倍,西语文案的长度更是达到了英语的 3.1 倍。



△ 这句短句(为了解锁等级测试,您需要进修完一切课程并获得足够的星星)的日语与西语在占位面积上更是「碾压」英语。


类似的环境很多见,这样在 App 的实现中就会很匆子 侄糜龅轿谋疽绯龅幕肪常晏饽┪驳氖÷院呕峋3鱿郑

最可怕的是交互文案可能无法在其容器内以正确的样式完整显示,哪怕不限制字符溢出,一行变两行、

字号压缩变小、容器产生不符合预期的形变等,都可能会影响页面的整体视觉成果。


对这个小case吾们起首想到的思路,是限制文案字符数。但是这也就引出了第二个小case:


难点 2:文案字符数限制不易执行


文案在界面中噬巷助用户理解信息的,一个被迫「阉割」过的交互文案很可能无法准确表达含义,让用户无法正确解读,

易于 在使用产品时匆子 侄貌环显て诘慕峁庋奈陌妇拖质道此凳俏ケ秤没逦兜摹


吾们也屡屡由于限制文案字符数而和翻译产生许多沟通上的小case,在一些语境环境下,翻译方表示文案绝对非能够短到满足吾们的字符数限制。


易于 ,为了用户体味揣摩,再是也为了减少不需要的翻译沟通,吾们在策划时应尽量避免限制文案字符数的环境发生。


解决思路


1. 在保证可读性与层级的上提下尽可能减小字号,提高字符承载能力


那到底多小的字号是较大且能够保证可读性的字号呢。这可能还真没有一个「准则答案」,不同的字体、字重会影响同样字号下的可读性。


吾们基于一些文字可读性关键的调研,再结合 Human Interface Guidelines 和 Material Design Guidelines 对字号的要旨,

并对 Airbnb 等在包容性策划上投入较大的产品进行调研下,结合归纳和演绎,得出了吾们自己的结论:


  • 图标与图片等的说明文案(Caption)较大使用 11pt;
  • 短文案或极次要文案(Notes)较大使用 13pt;
  • 标题、正文、按钮文案较大均使用 14pt,通例 16pt




△ Human Interface Guidelines 和 Material Design Guidelines 字体规范的部分截图


2. 尽量增加文案占位的宽度


尽量增加文案占位的宽度,尤其尽量避免文案并排放置。在这个思路下进行策划,哪怕只是使用英语等拉丁语系语言进行单语言策划,

也能有效扶掖避免由文案或单词长度带来的找子 拘ase。



△ 文案占位宽度预留不够,导致一行只能放下一个单词,甚至出现一个单词被强行分行的环境


3. 快速试验多语言下的文案实际长度


Translator 在 Figma 众多的多语言插件中实测最为好用,吾们使用 Translator 检查页面在其他语言中的成果。

它可以快速决定倾向语言并对一切文字进行机翻。


虽然机器翻译未必准确,但吾们在实际操作中发现,当英语文案正确时,人员翻译与机器翻译在绝大部分环境下的长度是非常接近的,

在使用这样的方法进行检查下,暂时还未遇到人员翻译文案过长而导致需要重新策划的环境。



△ Translator 实操演示


小case二:上端字体实现成果不可控


越优秀的上端工程师越是能够高度还原策划稿,然则如果吾们在进行多语言策划时不揣摩以下小case,上端再优秀怕也噬袭莫能助。


难点 1:字体不可控


作为策划师,难免会对某些字体有特其余偏爱。有的集团官网会为表达产品调性购买字体,

策划师往往也更趋向于使用集团官网专门购买的字体。


可是在涉及多语言时,这些字体可能导致以下小case:


字符支持不够完整,并且当字体的性状较为明显时,遇到其不支持的语言而产生系统字体替换时,

实际找子 境晒氩呋痹て诘某晒环


拿 Gilroy 举例:




如上图,在字号 14pt,字重 Regular 下,Gilroy 比 iOS 系统默认英文字体 SF Pro Text 看起来更细更小。

so为了保证文字的可读性,吾们在使用 Gilroy 进行策划时,会偏向于使用粗一些的字重,使得在多语言下,

如果字体使用 Medium 字重,在回退至系统字体时,整体视觉成果会偏粗。


解决思路


系统字体已经对大部分语言进行了良好的适配,以是在进行多语言策划时,比较easy的做法是:


使用系统字体进行涉及多语言的界面策划。


难点在于,策划师要把握好自己想使用更偏爱字体的欲望。


易于 这般,在一些无须支持多语言的环境下,譬喻说直营向的特定词汇、阿拉伯数字、英语词典中的英文等等,

灰子 强梢源κ褂梅窍低匙痔謇刺岣卟呋恼迨泳醭晒摹


难点 2:字重不可控


这个就现实来说也是在解决 Gilroy 会出现的小case时发现的。在想要提高视觉层级时,吾们会用到 Gilroy 的 Extrabold 甚至 Black 字重,

但是一到多语言实现时,Extrabold 或 Black 在苹方下只能显示为 Semibold 字重,在视觉上的「重量」完全不能符合期望。

这使得吾们不禁开始怀疑,就当它如此吾们在策划时都使用系统字体,会不会也会有由字重导致的还原小case呢?



△ apple预装中文繁体字体



△ apple预装日文字体


基于这些疑问,吾们调研了中、日、韩、英等语言下的系统预装字体对字重的支持。


以 iOS 为例,日文字体 Hiragino Sans 对字重的支持只有 W3/W6/W7(等同于 Regular/ Bold/ Heavy),

而繁体中文 PingFang 虽然支持的字重多达 6 个,最粗却只支持到 Semibold。


这将导致:如果吾们使用 Regular、Medium、Semibold 字重进行开发,so在日文界面中,就只会有 Regular 这一个字重的文字了,

吾们将无法通过字重来达到拉开视觉层级的鹄的。



解决思路


基于系统字体支持的字重和字重回退的逻辑,吾们得出了以下Plan:


使用 Regular 与 Bold 双字重进行策划。


如果喜欢用苹方字体的话,那策划时用 Semibold 也可,只要与开发约定好开发时使用 Bold 替代 Semibold 就行。


结语


末了总结一下进行多语言界面策划时需要care的点:


  • 尽量避免限制文案字符数
  • 在保证可读性与层级的上提下尽可能减小字号,提高字符承载能力
  • 尽量增加文案占位的宽度
  • 使用系统字体进行策划
  • 使用 Regular 与 Bold 双字重进行策划













XML 地图 | Sitemap 地图