Vol*_*kur 2 user-interface localization ellipsis web
假设我们在网页上有一个覆盖DHTML面板,其中包含顶部占据对话框整个宽度的两个按钮,如下所示:

按钮1和按钮2的文本应该是本地化的.复选框组的内容是静态的,不应本地化.
不同语言的按钮文字宽度之间可能存在很大差异(与英文版相比,大约100%的额外空间).
问题是根据文本内容的长度应用哪种策略来调整Button 1和Button 2的大小:
我倾向于根据找到的几个UI本地化最佳实践使用第三个或第四个选项:
我们仍然在讨论最佳选择的团队中进行一些辩论,听到社区有声的外部声音会很有趣.
我对此特定案例的最佳方法以及解决本地化方面的Web UI大小调整问题的一般准则感兴趣.
谢谢!
您可能知道,使用省略号(或使用单个点)缩短的文本可能是不可理解的:
怎么比较 是吗?
你应该在移动领域(手机,平板电脑等)看到很多这样的工作人员,这样的翻译看起来很难看.好的,屏幕分辨率较低,实际上最终没有选择(除非您可以创建一些自动滚动文本).但是对于Web界面,您当然可以选择.
通常,有两种解决方案对应于您的第3点和第4点.就个人而言,我倾向于#4 - 使按钮自动调整大小.这当然会导致按钮尺寸不一致,但我们无能为力.
如果您不能使用解决方案#4(即UI Designer是此技术的强烈反对者),您可以稍微修改解决方案#3.基本上,我在过去的项目中使用的是,我有固定大小的按钮,默认大小能够适合大多数语言(当然除了波兰语和俄语),但我也有几个定义更宽按钮的CSS类.当本地化为"太长"的语言时,我只使用了最宽的按钮类.如果文本仍然不适合,那么我请翻译人员缩短它(通常重新措辞并缩短文本,用一个点作为最后的手段).
但请记住,这会增加本地化成本.这就是我不推荐这种方法的原因.
至于解决方案#2,你最终会看到丑陋的UI.您根本无法控制浏览器如何包装文本,并且您将有许多文本超出按钮剪切矩形(重叠它).
对于解决方案#1,使用省略号是一个坏主意,原因有两个.首先,省略号在许多语言中无效(特别是亚洲语言).第二个是,据我所知,你想自动做到这一点.在这种情况下,您将无法测量字符串 - 它们的实际屏幕尺寸,使用后备字体编写.在Web UI的情况下,您不知道用户是否安装了特定字体,因此您将猜测大小(好的,使用Dojo,理论上可以在客户端测量它).这当然会导致文本重叠(如果您决定对所选字体进行动态缩短)或完全难以理解的文本(如果您决定在说出8个字符后缩短).我有一个项目开始使用静态缩短,这是一个混乱.然后我们切换到动态,它仍然不够好.
为了对抗"我们没有字符串扩展空间"的潜在UI Designer参数,我只能说这意味着你为它设计错误的界面太拥挤了.这是I18n与UI设计最佳实践密切相关的一点:力求简单(在UI设计中).结果易于使用且易于本地化应用程序.
| 归档时间: |
|
| 查看次数: |
1177 次 |
| 最近记录: |