Bagikan melalui


Mendesain aplikasi Anda untuk teks dua arah

Desain aplikasi Anda untuk menyediakan dukungan teks dua arah (BiDi) sehingga Anda dapat menggabungkan skrip dari kanan ke kiri (RTL) dan sistem penulisan kiri ke kanan (LTR), yang umumnya berisi berbagai jenis alfabet.

Sistem penulisan kanan-ke-kiri, seperti yang digunakan di Timur Tengah, Asia Tengah dan Selatan, dan di Afrika, memiliki persyaratan desain yang unik. Sistem penulisan ini memerlukan dukungan teks dua arah (BiDi). Dukungan BiDi adalah kemampuan untuk memasukkan dan menampilkan tata letak teks dalam urutan kanan ke kiri (RTL) atau kiri ke kanan (LTR).

Total sembilan bahasa BiDi disertakan dengan Windows.

  • Dua bahasa yang sepenuhnya dilokalkan. Arab, dan Ibrani.
  • Tujuh Paket Antarmuka Bahasa untuk pasar negara berkembang. Persia, Urdu, Dari, Kurdi Tengah, Sindhi, Punjabi (Pakistan), dan Uyghur.

Topik ini berisi filsafat desain Windows BiDi, dan studi kasus yang menunjukkan pertimbangan desain BiDi.

Elemen desain Bidi

Empat elemen memengaruhi keputusan desain BiDi di Windows.

  • Pencerminan antarmuka pengguna (UI). Alur antarmuka pengguna (UI) memungkinkan konten kanan-ke-kiri disajikan dalam tata letak aslinya. Desain UI terasa lokal untuk pasar BiDi.
  • Konsistensi dalam pengalaman pengguna. Desainnya terasa alami dalam orientasi kanan-ke-kiri. Elemen UI berbagi arah tata letak yang konsisten dan muncul seperti yang diharapkan pengguna.
  • Pengoptimalan sentuhan. Mirip dengan antarmuka pengguna sentuh di UI yang tidak dicerminkan, elemen mudah dijangkau, dan alami untuk menyentuh interaksi.
  • Dukungan teks campuran. Dukungan arah teks memungkinkan presentasi teks campuran yang hebat (teks bahasa Inggris pada build BiDi, dan sebaliknya).

Gambaran umum desain fitur

Windows mendukung empat elemen desain BiDi. Mari kita lihat beberapa fitur utama yang relevan dari (versi sebelumnya) Windows, dan berikan beberapa konteks tentang pengaruhnya terhadap aplikasi Anda.

Windows menyesuaikan arah kisi tipografis sehingga mengalir dari kanan ke kiri, yang berarti bahwa petak peta pertama pada kisi ditempatkan di sudut kanan atas, dan petak peta terakhir di kiri bawah. Ini cocok dengan pola RTL publikasi cetak seperti buku dan majalah, di mana pola membaca selalu dimulai di sudut kanan atas dan berkembang ke kiri.

Menu mulai BiDiMenu mulai BiDi dengan pesona

Untuk mempertahankan alur UI yang konsisten, konten pada petak peta mempertahankan tata letak kanan-ke-kiri, yang berarti bahwa nama dan logo aplikasi diposisikan di sudut kanan bawah petak peta terlepas dari bahasa UI aplikasi.

Petak BiDi

Petak BiDi

Petak peta Bahasa Inggris

Petak peta Bahasa Inggris

Dapatkan pemberitahuan petak peta yang dibaca dengan benar

Petak peta memiliki dukungan teks campuran. Wilayah pemberitahuan memiliki fleksibilitas bawaan untuk menyesuaikan perataan teks berdasarkan bahasa pemberitahuan. Saat aplikasi mengirim pemberitahuan bahasa Arab, Ibrani, atau BiDi lainnya, teks diratakan ke kanan. Dan ketika pemberitahuan Bahasa Inggris (atau LTR lainnya) tiba, pemberitahuan tersebut akan selaras di sebelah kiri.

Pemberitahuan petak peta

Pengalaman pengguna RTL yang konsisten dan mudah disentuh

Setiap elemen dalam UI Windows cocok dengan orientasi RTL. Pesona dan flyout telah diposisikan di tepi kiri layar sehingga tidak tumpang tindih dengan hasil pencarian atau menurunkan pengoptimalan sentuhan. Mereka dapat dengan mudah dijangkau dengan jempol.

Cuplikan layar BiDi memperlihatkan mengubah ukuran flyout pencarianCuplikan layar BiDi memperlihatkan mengubah ukuran flyout cetak

Cuplikan layar BiDi memperlihatkan ukuran flyout pengaturanCuplikan layar BiDi memperlihatkan bilah aplikasi yang diubah ukurannya

Input teks ke segala arah

Windows menawarkan keyboard sentuh di layar yang bersih dan bebas kekacauan. Untuk bahasa BiDi, ada kunci kontrol arah teks sehingga arah input teks dapat dialihkan sesuai kebutuhan.

Keyboard sentuh untuk bahasa BiDi

Menggunakan aplikasi apa pun dalam bahasa apa pun

Instal dan gunakan aplikasi favorit Anda dalam bahasa apa pun. Aplikasi muncul dan berfungsi seperti yang mereka lakukan pada versi Windows non-BiDi. Elemen dalam aplikasi selalu ditempatkan dalam posisi yang konsisten dan dapat diprediksi.

Aplikasi bahasa Inggris memperlihatkan konten BiDi

Tampilkan tanda kurung dengan benar

Dengan pengenalan BiDi Parenthesis Algorithm (BPA), tanda kurung yang dipasangkan selalu ditampilkan dengan benar terlepas dari properti perataan bahasa atau teks.

Tanda kurung salah

Aplikasi BiDi dengan tanda kurung yang salah

Kurung yang benar

Aplikasi BiDi dengan tanda kurung yang benar

Tipografi

Windows menggunakan font UI Segoe untuk semua bahasa BiDi. Font ini dibentuk dan diskalakan untuk UI Windows.

Cuplikan layar memperlihatkan font Segoe UI di layar mulaiCuplikan layar memperlihatkan font Arab Segoe di layar mulai

Studi kasus #1: Aplikasi musik BiDi

Gambaran Umum

Aplikasi multimedia membuat tantangan desain yang sangat menarik, karena kontrol media umumnya diharapkan memiliki tata letak kiri ke kanan yang mirip dengan bahasa non-BiDi.

Kontrol media kiri-ke-kanan

Kontrol media kanan-ke-kiri

Menetapkan arahan UI

Mempertahankan alur UI kanan-ke-kiri penting untuk desain yang konsisten untuk pasar BiDi. Menambahkan elemen yang memiliki alur kiri-ke-kanan dalam konteks ini sulit, karena beberapa elemen navigasi seperti tombol belakang dapat bertentangan dengan orientasi terarah tombol belakang dalam kontrol audio.

Halaman trek aplikasi musik

Aplikasi musik ini mempertahankan kisi berorientasi kanan ke kiri. Ini memberi aplikasi nuansa yang sangat alami bagi pengguna yang sudah menavigasi ke arah ini di seluruh UI Windows. Alur dipertahankan dengan memastikan bahwa elemen utama tidak hanya diurutkan dari kanan ke kiri, tetapi juga selaras dengan benar di header bagian untuk membantu mempertahankan alur UI.

Halaman album aplikasi musik

Penanganan teks

Bio artis dalam cuplikan layar di atas selaras kiri, sementara potongan teks terkait artis lainnya seperti album dan nama trek mempertahankan perataan kanan. Bidang bio adalah elemen teks yang cukup besar, yang membaca dengan buruk ketika diselaraskan ke kanan hanya karena sulit untuk melacak antara baris saat membaca blok teks yang lebih luas. Secara umum, elemen teks apa pun dengan lebih dari dua atau tiga baris yang berisi lima kata atau lebih harus dipertimbangkan untuk pengecualian perataan serupa, di mana perataan blok teks berlawanan dengan tata letak arah aplikasi secara keseluruhan.

Memanipulasi keselarasan di seluruh aplikasi dapat terlihat sederhana, tetapi sering mengekspos beberapa batasan dan batasan mesin penyajian dalam hal penempatan karakter netral di seluruh string BiDi. Misalnya, string berikut dapat ditampilkan secara berbeda berdasarkan perataan.

String Bahasa Inggris (LTR) String Ibrani (RTL)
Perataan kiri Hello, World! בוקר טוב!
Perataan kanan Hello, World! !בוקר טוב

Untuk memastikan bahwa informasi artis ditampilkan dengan benar di seluruh aplikasi musik, tim pengembangan memisahkan properti tata letak teks dari perataan. Dengan kata lain, info artis mungkin ditampilkan sejajar kanan dalam banyak kasus, tetapi penyesuaian tata letak string diatur berdasarkan pemrosesan latar belakang yang disesuaikan. Pemrosesan latar belakang menentukan pengaturan tata letak arah terbaik berdasarkan konten string.

Halaman artis aplikasi musik

Misalnya, tanpa pemrosesan tata letak string kustom, nama artis "The Contoso Band." akan muncul sebagai ". Band Contoso".

Pra-pemrosesan arah string khusus

Saat aplikasi menghubungi server untuk metadata media, aplikasi melakukan praproses setiap string sebelum menampilkannya kepada pengguna. Selama pra-pemrosesan ini, aplikasi juga melakukan transformasi untuk membuat arah teks konsisten. Untuk melakukan ini, ia memeriksa apakah ada karakter netral di akhir string. Selain itu, jika arah teks string berlawanan dengan arah aplikasi yang diatur oleh pengaturan bahasa Windows, maka ia menambahkan penanda arah Unicode (dan kadang-kadang prepends). Fungsi transformasi terlihat seperti ini.

string NormalizeTextDirection(string data) 
{
    if (data.Length > 0) {
        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;
}

Karakter Unicode yang ditambahkan adalah lebar nol, sehingga tidak memengaruhi penspasian string. Kode ini membawa potensi penalti performa, karena mendeteksi arah string memerlukan berjalan melalui string hingga karakter non-netral ditemui. Setiap karakter yang diperiksa netralitasnya pertama kali dibandingkan dengan beberapa rentang Unicode juga, sehingga bukan pemeriksaan sepele.

Studi kasus #2: Aplikasi email BiDi

Gambaran Umum

Dalam hal persyaratan tata letak UI, klien email cukup sederhana untuk didesain. Aplikasi Mail di Windows dicerminkan secara default. Dari perspektif penanganan teks, aplikasi email diperlukan untuk memiliki kemampuan tampilan teks dan komposisi yang lebih kuat untuk mengakomodasi skenario teks campuran.

Menetapkan arahan UI

Tata letak UI untuk aplikasi Mail dicerminkan. Tiga panel telah diorientasikan ulang sehingga panel folder diposisikan di tepi kanan layar, diikuti oleh panel daftar item email di sebelah kiri, lalu panel komposisi email.

Aplikasi email cermin

Item tambahan telah diorientasikan ulang agar sesuai dengan alur UI keseluruhan, dan pengoptimalan sentuh. Ini termasuk bilah aplikasi dan ikon buat, balas, dan hapus.

Aplikasi email cermin dengan bilah aplikasi

Penanganan Teks

UI

Perataan teks di seluruh UI biasanya rata kanan. Ini termasuk panel folder dan panel item. Panel item dibatasi hingga dua baris teks (Alamat, dan Judul). Ini penting untuk mempertahankan perataan kanan-ke-kiri, tanpa memperkenalkan blok teks yang akan sulit dibaca ketika arah konten berlawanan dengan alur arah UI.

Pengeditan Teks

Pengeditan teks memerlukan kemampuan untuk menyusun dalam bentuk kanan-ke-kiri dan kiri-ke-kanan. Selain itu, tata letak komposisi harus dipertahankan dengan menggunakan format —seperti teks kaya—yang memiliki kemampuan untuk menyimpan informasi terarah.

Aplikasi email kiri ke kanan

Aplikasi email kanan ke kiri