[ 本文适用于编写 Windows 运行时应用的 Windows 8.x 和 Windows Phone 8.x 开发人员。如果你要针对 Windows 10 进行开发,请参阅 最新文档 ]
将你的应用设计为可为从右到左书写系统提供双向文本支持 (BiDi)。
简介
Microsoft 很早就开始为使用从右到左书写系统的中东和其他地区制作软件。这些地区的设计要求非常独特,因为当地常用的书写系统要求具有双向文本支持 (BiDi)。这项功能可以按从右到左 (RTL) 或从左到右 (LTR) 的顺序输入和显示文本布局。Windows 3.1 是第一个纳入了双向语言支持的 Windows 版本。在 Windows 98 中,对 UI 方向进行了镜像,因此对于讲阿拉伯语或希伯来语的人而言,用户体验显得较为自然。
Windows 8 提供了不折不扣的双向体验。对新的 Windows UI 中的每个要素进行了设计并将其加入到丰富的沉浸式从右到左用户体验中,以最自然的状态展示这些语言。
从 Windows 8 开始,总共包括了九种双向语言:
- 两种完全本地化的语言(阿拉伯语和希伯来语)。
- 七种用于新兴市场的语言界面包(波斯语、乌尔都语、达里语、中部库尔德语、信德语、旁遮普语(巴基斯坦)和维吾尔语)。其中有两种语言是新语言,为 Windows 8 所独有。
为双向市场设计 Windows 应用商店应用
以下是 Windows 双向设计原理和案例研究,介绍了双向设计要点。
双向设计要素
在 Windows 中有四个要素会影响双向设计决策:
- **UI 镜像。**UI 流允许在其本机布局中显示从右到左顺序的内容。双向市场的本地 UI 设计感觉。
- **用户体验的一致性。**设计从右到左的方向让人感觉很自然。UI 元素共享一个一致的布局方向并按用户期望的方式显示。
- **触摸优化。**与非镜像 UI 中的触摸 UX 类似,可以轻松地触摸到元素,并且触摸交互的感觉很自然。
- **混合文本支持。**文本方向性支持可以获得更好的混合文本表现形式(双向结构中的英语文本,反之亦然)。
功能设计概述
Windows 平台支持上面列出的四种双向设计要素。我们将探讨 Windows 中的一些主要相关功能,并提供一些影响你的应用的上下文。
按感觉自然的方向导航。
我们调整了网格方向,使其流向从右到左,即网格中的第一个磁贴放在右上角,最后一个磁贴放在左下角。用户从印刷出版物(如书籍和杂志)中已经对这种信息显示方式非常熟悉,其中阅读模式始终是从右上角开始,然后向左边延续。
为了保持一致的 UI 流,网格上的磁贴始终保持从右到左的布局,即应用名称和徽标定位在磁贴的右下角,与应用 UI 语言无关。
双向磁贴:
英语磁贴:
获取行文正确的磁贴通知。
磁贴提供混合文本支持。通知区域具有内置的灵活性,可以根据通知语言来调整文本对齐方式。 当应用发送阿拉伯语、希伯来语或其他双向语言的通知时,文本将右对齐,当英语(或其他从左到右语言)通知到达时,文本将左对齐。
一种一致的便于触摸的从右到左用户体验。
新 Windows UI 中的每个元素都适合从右到左方向。超级按钮和浮出控件已定位在屏幕的左边缘,这样它们就不会覆盖搜索结果或者降低触摸优化的级别。可以方便地用拇指触摸它们。
任何方向的文本输入。
Windows 提供了一个干净整洁的屏幕触摸键盘。对于双向语言,有一个文本方向控件键,这样可以根据需要切换文本输入方向。
使用任何语言的任何应用。
安装并使用你喜欢的任何语言的应用。应用的显示和功能与它们在非双向版本的 Windows 一样。应用中的元素始终放在一个一致并且可预测的位置。
正确显示括号。
在引入双向括号算法 (BPA) 之后,将始终正确显示配对的括号,与语言或文本对齐属性无关。
错误的括号:
正确的括号:
新字体。
Windows 对所有双向语言使用新的 Segoe UI 字体。此新字体根据新的 Windows UI 改变形状和缩放。
案例研究 1:双向音乐应用
概述
多媒体应用程序往往有一个非常有趣的设计难题,因为人们通常认为媒体控件与非双向语言类似,是从左到右的布局。
建立 UI 方向性
保持从右到左的 UI 流对于双向市场中的设计一致性十分重要。在此上下文中添加具有从左到右流向的元素比较困难,这是因为一些导航元素(如“后退”按钮)可能与音频控件中“后退”按钮的方向冲突。
Microsoft 音乐应用保留了从右到左方向的网格。对于已经在新 Windows UI 间按此方向导航的用户来说,这给予应用程序非常自然的感觉。流是通过以下方式保持的:确保主要元素不但按从右到左的顺序排序而且在节标题中正确对齐,以帮助维护 UI 流。
文本处理
以上屏幕中的艺术家简历是左对齐,而其他与艺术家相关的文本段(如唱片集和曲目名称)则保留右对齐。简历字段是一个相当大的文本元素,当右对齐时可读性很差,原因很简单,在阅读较大的文本块时,很难在行与行之间跟踪。通常,对于任何文本元素,只要包含五个或五个以上字词的行超过两行或三行,就要考虑是否会出现类似的对齐异常,其中文本块对齐方式与总体应用方向布局的对齐方式相反。
操作整个应用的对齐方式看上去很简单,但对于跨双向字符串放置的中性字符而言,通常暴露出呈现引擎的一些边界和限制。例如,以下字符串可能因对齐方式的不同而有不同的显示:
英语字符串 (LTR) | 希伯来语字符串 (RTL) | |
---|---|---|
左对齐 | Hello World! | בוקר טוב! |
右对齐 | !Hello World | !בוקר טוב |
为确保艺术家信息在整个音乐应用中正确显示,开发团队将文本布局属性与对齐方式分开。也就是说,在许多情况下,艺术家信息可能以右对齐的方式显示,但字符串布局调整则是根据自定义的后台处理来设置的。后台处理会根据字符串的内容确定最佳的方向布局设置。
**示例:**如果没有自定义字符串布局处理,艺术家名称 "The Contoso Band." 将显示为 ".The Contoso Band"。
专门的字符串方向预处理
当应用通过轮询我们的服务器来查找媒体元数据时,它将预处理每个字符串,然后再将其显示给用户。在此预处理过程中,应用还会执行一次转换,使文本方向一致。为此,它将检查字符串两端是否有中性字符。此外,如果字符串的文本方向与 Windows 语言设置所设的应用方向相反,则它将附加(有时是在前面添加)Unicode 方向标记。在 JavaScript 中转换函数的形式如下:
function normalizeTextDirection(data) {
if (data) {
var lastCharacterDirection = DetectCharacterDirection(data[data.length - 1]);
// If the last character has strong directionality (direction is not null), then the text direction for the string is already consistent.
if (!lastCharacterDirection) {
// If the last character has no directionality (neutral character, direction is null), then we may need to add a direction marker to
// ensure that the last character doesn't inherit directionality from the outside context.
var appTextDirection = GetAppTextDirection(); // checks the <html> element's "dir" attribute.
var dataTextDirection = DetectStringDirection(data); // Run through the string until a non-neutral character is encountered,
// which determines the text direction.
if (appTextDirection !== dataTextDirection) {
// Add a direction marker only if the data text runs opposite to the directionality of the app as a whole,
// which would cause the neutral characters at the ends to flip.
var directionMarkerCharacter =
dataTextDirection === TextDirections.RightToLeft ?
UnicodeDirectionMarkers.RightToLeftDirectionMarker : // "\u200F"
UnicodeDirectionMarkers.LeftToRightDirectionMarker; // "\u200E"
data += directionMarkerCharacter;
// Prepend the direction marker if the data text begins with a neutral character.
var firstCharacterDirection = DetectCharacterDirection(data[0]);
if (!firstCharacterDirection) {
data = directionMarkerCharacter + data;
}
}
}
}
return data;
}
添加的 Unicode 字符是零宽度字符,因此不影响字符串的间距。 但此代码会带来潜在的性能影响,因为检测字符串的方向需要贯穿整个字符串,直至遇到非中性字符为止。要检查每个字符是否为中性,还需要首先与若干 Unicode 范围进行比较,因此这不是一项小检查。
案例研究 2:双向邮件应用
概述
对于 UI 布局要求而言,邮件客户端在设计上相当简单。Windows 附带的 Microsoft Mail 应用在默认情况下是镜像应用。从文本处理角度看,邮件应用需要有更可靠的文本显示和编写能力才能适应混合文本方案。
建立 UI 方向性
Microsoft Mail 应用的 UI 布局是镜像布局。三个窗格已重新调整方向,以便文件夹窗格定位在屏幕的右边缘,接着是邮件项目列表窗格定位在左侧,然后是电子邮件编写窗格。
已对附加项目重新定向,以匹配整个 UI 流和触摸优化。 这些包括应用栏以及编写、回复和删除图标。
文本处理
UI
UI 中的文本对齐方式通常为右对齐。其中包括文件夹窗格和项目窗格。项目窗格只有两行文本(“地址”和“标题”)。这对于保留从右到左对齐方式非常重要,而无需引入文本块,因为当内容方向与 UI 方向流相反时,文本块将难以阅读
文本编辑
文本编辑要求既能从右到左,也能从左到右进行编写。此外,必须使用某种格式(如可保存方向信息的 RTF)保留编写布局。