共用方式為


如何支援雙向 UI (HTML)

[ 本文的目標對象是撰寫 Windows 執行階段 App 的 Windows 8.x 和 Windows Phone 8.x 開發人員。如果您正在開發適用於 Windows 10 的 App,請參閱 最新文件 ]

設計您的應用程式,以提供右至左書寫系統的雙向文字支援 (BiDi)。

簡介

Microsoft 為中東地區及其他使用右至左書寫系統的地區生產軟體已經行之有年。這些區域具有獨特的設計需求,因為這些區域常用的書寫系統需要雙向文字支援 (BiDi)。也就是能夠以右至左 (RTL) 或左至右 (LTR) 的順序來輸入文字與顯示文字配置。Windows 3.1 是第一個納入 BiDi 語言支援的 Windows 版本。 Windows 98 中則以鏡像的方式顯示 UI 方向,這樣可以為母語為阿拉伯文或希伯來文的人提供外觀和操作方式更自然的使用者經驗。

Windows 8 提供全功能的 BiDi 經驗。新 Windows UI 中的每個元素都經過特別設計,並加入豐富且沈浸式的從右至左使用者經驗,並以最自然的方式展現這些語言。

從 Windows 8 開始已包含總共九種 BiDi 語言:

  • 兩個完全當地語系化的語言 (阿拉伯文、希伯來文)。
  • 七種新興市場的語言介面套件 (波斯文、烏都文、達利文、中部庫德文、信德文、旁遮普文 (巴基斯坦) 和維吾爾文)。其中兩種語言是 Windows 8 才提供的新語言。

設計 BiDi 市場的 Windows 市集應用程式

以下是 Windows BiDi 的設計哲學,以及可展示 BiDi 設計考量的案例研究。

Bidi 設計元素

影響 Windows BiDi 設計決策的四個元素:

  • **UI 鏡像處理。**UI 流向可讓從右至左的內容以原始配置顯示。對 BiDi 市場而言,UI 設計完全融入當地。
  • **使用者經驗的一致性。**從右至左的方向可讓設計看起來很自然。UI 元素使用一致的配置方向,並以使用者想要的方式顯示。
  • **觸控最佳化。**類似於非鏡像 UI 的觸控 UX,元素使用更便利且在觸控互動時感覺更自然。
  • **混合文字支援。**文字方向支援可提供最佳的文字混合顯示 (BiDi 組建上的英文文字,反之亦然)。

功能設計概觀

Windows 平台支援以上所列的四個 BiDi 設計元素。我們來看看一些 Windows 的重要相關功能,並提供這些功能如何影響應用程式的相關資訊。

以最自然的方向進行瀏覽。

我們調整了格線方向,這樣介面項目就能從右至左開始放置,也就是說格線的第一個磚會放在右上角,而最後一個磚在左下角。這可以為使用者提供他們在印刷出版品 (例如書籍和雜誌) 上常見的資訊呈現模式,閱讀出版品時通常是從右上角開始,然後向左邊方向閱讀。

BiDi [開始] 功能表 含有快速鍵的 BiDi 開始功能表

為了保存 UI 流向的一致性,在格線上的磚一律保留從右至左的配置,也就是說應用程式名稱和標誌會放置在磚的右下角,無論應用程式 UI 是哪一種語言都一樣。

BiDi 磚:

BiDi 磚

英文磚:

英文磚

取得可正確閱讀的磚通知。

磚可支援混合文字。通知區域有內建的彈性可根據通知語言調整文字對齊。 當應用程式傳送阿拉伯文、希伯來文或其他 BiDi 語言通知時,文字會靠右對齊,如果收到的是英文 (或其他 LTR) 通知,文字會靠左對齊。

磚通知

一致且方便觸控的 RTL 使用者經驗。

新 Windows UI 中的每個元素都符合 RTL 方向。快速鍵和飛出視窗已經放置在螢幕的左邊,這樣就不會和搜尋結果重疊或降低最佳化的觸控功能。使用拇指就可以輕鬆觸碰快速鍵和飛出視窗。

BiDi 螢幕擷取畫面 BiDi 螢幕擷取畫面

BiDi 螢幕擷取畫面 BiDi 螢幕擷取畫面

任何方向的文字輸入。

Windows 提供簡潔的螢幕觸控小鍵盤。使用 BiDi 語言時,有一個文字方向控制鍵,可以視需要切換文字輸入方向。

BiDi 語言的觸控式鍵盤

使用任何語言的任何應用程式。

使用任何語言來安裝和使用我的最愛應用程式。應用程式會使用與在非 BIDi Windows 版本一樣的方式顯示和運作。應用程式內的元素一律放在一致且可預期的位置。

顯示 BiDi 內容的英文應用程式

正確顯示括號。

引進 BiDi 括號演算法 (BPA) 之後,無論語言或文字對齊屬性為何,成對的括號都會正確顯示。

錯誤的括號:

含有錯誤括號的 BiDi 應用程式

正確的括號:

含有正確括號的 BiDi 應用程式

新字型。

Windows 在所有 BiDi 語言都使用新的 Segoe UI 字型。這個新字型是為新 Windows UI 量身打造和調整。

BiDi 語言的 Segoe UI 字型 BiDi 語言的 Segoe UI 字型

案例研究 #1:BiDi 音樂應用程式

概觀

設計多媒體應用程式雖然有趣,但也是個很大的挑戰,因為媒體控制項通常需要使用與非 BiDi 語言類似的從左至右配置。

媒體控制項左至右 媒體控制項右至左

建立 UI 方向性

保留從右至左 UI 流向是在 BiDi 市場中保持一致設計的關鍵。要在這樣的介面中新增從左至右流向的元素並不容易,因為部分瀏覽元素,例如上一首按鈕,可能會和音訊控制項的倒帶按鈕,在方向上有所抵觸。

音樂應用程式曲目頁面

Microsoft 音樂應用程式仍保留右至左的格線方向。這可為已經使用這個方向瀏覽新 Windows UI 的使用者提供自然的應用程式瀏覽觀感。為了保留這個流向,要確定主要元素不只是以從右至左的順序排列,同時還要在區段標頭正確對齊,以協助維持 UI 流向。

音樂應用程式專輯頁面

文字處理

上方畫面的演出者生平是靠左對齊,但其他與演出者相關的文字 (例如專輯和曲目名稱) 則保留靠右對齊。生平欄位是一個相當大的文字元素,靠右對齊時很難閱讀,因為閱讀大型文字區塊時很難追蹤每一行。一般而言,超過兩行或三行、且每行五個字以上的任何文字元素都需考量類似的對齊例外,這個例外的文字區塊對齊與應用程式整體的方向配置相反。

操控應用程式對齊方向看起來很簡單,但通常會洩漏呈現引擎在放置 BiDi 字串中性字元的一些界限和限制。例如,下列字串會因對齊方式而有不同的顯示方式:

英文字串 (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:BiDi 郵件應用程式

概觀

就 UI 配置需求而言,郵件應用程式很容易設計。Windows 隨附的 Microsoft 郵件應用程式預設為鏡像處理。從文字處理的角度來看,郵件應用程式需要有更穩固的文字顯示和撰寫功能,才能處理混合文字案例。

建立 UI 方向性

Microsoft 郵件應用程式的 UI 配置是用鏡像處理。三個窗格都已重新排列,資料夾窗格放置在畫面的右邊,左邊則依序放置郵件項目清單窗格和電子郵件撰寫窗格。

鏡像處理的郵件應用程式

其他項目也已重新排列,以符合整體的 UI 流向與觸控最佳化。 這些項目包含應用程式列與撰寫、回覆及刪除圖示。

鏡像處理的郵件應用程式與應用程式列

文字處理

UI

整個 UI 的文字對齊方式通常是靠右對齊。這包含資料夾窗格與項目窗格。項目窗格有兩行的文字限制 (位址與標題)。保留右至左對齊是很重要的,這樣當內容方向與 UI 方向流向相反時,才不會產生難以閱讀的文字區塊。

文字編輯

文字編輯需要有可以從右至左和從左至右格式撰寫的能力。此外,撰寫配置必須使用可儲存方向資訊的格式來保留 (例如 RTF 格式)。

郵件應用程式從左至右

郵件應用程式從右至左