Saat melokalisasi layanan, penting untuk mempertimbangkan koordinasi transfer antar satu sama lain. Kepala tim pengembangan Android klien Yandex.Taxi, Alexander Bonel, berbicara tentang praktik dan alat yang menyederhanakan lokalisasi. Pada bagian kedua laporan, Sasha berbagi pengalaman mendukung RTL dalam aplikasi: apa yang baik dan apa yang tidak bekerja untuk Android di luar kotak, masalah apa yang muncul karena dukungan RTL dan bagaimana meminimalkannya di masa depan.
- Dalam laporan saya, saya ingin memberi tahu Anda gagasan dasar dan praktik apa yang kami gunakan dalam tim pengembangan Taksi aplikasi seluler untuk menyelesaikan masalah terkait pelokalan dan pemutakhiran terjemahan dalam aplikasi kami. Lalu saya akan memberi tahu Anda bagaimana kami menerapkan dukungan untuk bekerja dalam mode menggambar dari kanan ke kiri dalam aplikasi.
Saya akan mulai dengan lokalisasi. Pertama-tama, saya ingin menjelaskan terminologinya. Menurut pengamatan saya, sejumlah besar orang percaya bahwa lokalisasi hanya terbatas pada terjemahan, meskipun pada kenyataannya itu juga memecahkan masalah yang terkait dengan memformat angka, tanggal, waktu, bekerja dengan teks dan simbol, aspek hukum, mengirimkan konten kepada konsumen sedemikian rupa, bahwa ia memiliki nilai semantik untuknya dan tidak dirasakan secara mendua. Dan masih banyak lagi.
(Komunikasi dengan audiens tentang siapa yang memiliki berapa banyak bahasa yang didukung dalam aplikasi - Ed.)Saya ingin menceritakan kisah yang terjadi pada kami pada tahun 2014. Kami kemudian melakukan desain ulang utama aplikasi Taksi. Dalam salah satu rilis berikutnya, kami memberi pengguna kesempatan untuk menunjukkan nomor pintu masuk, serta melihat informasi ini di layar informasi perjalanan dan, yang paling penting, pada layar peringkat pesanan, yang kami tunjukkan kepada semua pengguna, karena kami pasti ingin mendapatkan peringkat untuk perjalanan tersebut .
Pada saat itu, kami agak sembrono tentang proses pelokalan dan terjemahan. Sebagian besar, seluruh prosesnya adalah manual. Memperbarui teks dalam file XML yang diperlukan, menambahkan terjemahan baru dilakukan secara manual. Dan faktor manusia berperan. Pengembang menentukan transfer berikutnya bukan dalam lokal default. Ini mengarah pada fakta bahwa bagi pengguna dengan sistem lokal yang berbeda dari bahasa Rusia, jika mereka bertanya pintu masuk, aplikasi macet di akhir perjalanan. Dan orang tidak bisa membuat pesanan lain.
Pada saat itu, kami memiliki dua bahasa yang didukung dalam aplikasi: Rusia dan Inggris. Dan kami hanya bekerja di Rusia di tiga kota: Moskow, Yekaterinburg, St. Petersburg.
Kami saat ini beroperasi di 16 negara dan diterjemahkan ke dalam 18 bahasa. Saya pikir Anda mengerti seluruh masalah, jika kita berada dalam keadaan itu pada saat itu. Kami sudah menyadari bahwa sesuatu perlu diubah.
Di Yandex, sebagian besar pengembang aplikasi seluler untuk memecahkan masalah terkait pelokalan menggunakan layanan yang dikembangkan secara internal. Ini memiliki antarmuka UI yang sangat nyaman, dimungkinkan untuk mendefinisikan proyek Anda, mengatur satu set kunci, satu set bahasa di mana Anda perlu menerjemahkan proyek. Dan setelah terjemahan muncul, mereka dapat diunggah dalam format apa pun yang nyaman. Dia juga memiliki integrasi yang sangat baik dengan layanan internal kami. Ada versi. Tetapi bagi saya pribadi, sebagai pengembang, yang terpenting adalah ia memiliki API, karena ini sudah menunjukkan bahwa semua pekerjaan manual yang terkait dengan terjemahan dapat diotomatisasi. Yang kami lakukan. Kami telah mengembangkan sebuah plugin untuk Gradle. Bahkan, memperbarui terjemahan dalam aplikasi sekarang datang ke kenyataan bahwa pengembang melakukan satu tugas: updateTranslations.
Dalam perkiraan pertama, dia pergi ke layanan pelokalan. Memeriksa terjemahan terbaru, mengunggahnya ke proyek, memasukkannya ke file yang diperlukan. Namun selain itu, ia juga melakukan verifikasi status terjemahan dalam layanan pelokalan sehubungan dengan apa yang sekarang dalam proyek.
Waktu berikutnya status git dieksekusi, pengembang melihat dalam direktori kerjanya file mana yang telah berubah.
Dia juga dapat melihat dalam laporan HTML yang dihasilkan tentang kunci mana yang nilai dalam bahasa mana telah berubah.
Dan dia juga bisa melihat masalah apa yang saat ini hadir dalam terjemahan proyeknya.
Plugin ini dapat dikonfigurasi. Kami dapat menentukan jumlah bahasa yang didukung aplikasi kami. Sangat penting jika pelokalan memulai bahasa baru, dan secara tidak sengaja merembes ke dalam proyek, setelah tidak melalui proofreading dan proofreading.
Ada juga fitur pemetaan ulang khusus. Saya akan membicarakannya nanti sedikit lebih rinci ketika saya berbicara tentang RTL.
Masalah apa yang dianalisis plugin ini sekarang? Masalah yang kami temui pada tahun 2014 adalah lumrah, kurangnya terjemahan. Sekarang, untuk menambahkan baris baru, terjemahan baru ke proyek, tidak cukup bagi pengembang untuk mendefinisikannya dalam file XML.
Pertama, jika dia melakukan ini bukan di lokal default, maka kunci luka yang baru akan hilang begitu saja selama sinkronisasi berikutnya, dan dia akan tahu tentang hal itu pada tahap kompilasi.
Jika ia menentukan kunci dalam file default, tetapi lupa melakukannya di layanan pelokalan, maka saat pembaruan translasi dijalankan, ia akan menerima kesalahan dari plug-in, yang akan memberitahunya: "Kunci ini ada di proyek Anda, tetapi tidak ada di layanan pelokalan, itu ada di sana. harus dimulai. "
Masalah khas kedua adalah kurangnya terjemahan. Kami mendapatkan daftar tautan ke kunci-kunci yang tidak ada terjemahannya, dan, sebagai aturan, kami menugaskan mereka untuk manajer kami sehingga mereka kemudian mengatur komunikasi dengan penerjemah. Poin ketiga sering terjadi ketika mereka memutuskan untuk mempertimbangkan kembali penggunaan argumen format dalam beberapa cara, dan, misalnya, alih-alih format integer, mereka mulai menggunakan format string.
Tetapi pada saat yang sama, dalam beberapa terjemahan mereka lupa mengubah nomor di telepon.
Dan masalah keempat juga disebabkan oleh faktor manusia, terutama dalam terjemahan. Jika terjemahan menggunakan karakter Unicode, sangat mudah untuk bingung dalam penentuan posisi karakter dan alih-alih ruang yang tidak terpisahkan untuk mendapatkan tanda hubung ke baris lain - inilah yang kami coba singkirkan.
Ini semua tentang lokalisasi.
Sekarang saya ingin berbicara tentang pengalaman menerapkan dukungan untuk rendering dari kanan ke kiri dalam aplikasi menggunakan contoh Israel. Kami diluncurkan pada 2018 dengan nama merek Yango di Israel. Ternyata, di Israel orang membaca berbeda dari Anda dan saya. Mereka membaca dari kanan ke kiri.
Di mana Anda ingin memulai? Dengan Android, pada prinsipnya, dukungan render kanan-ke-kiri diimplementasikan dengan baik.
Itu dimulai dengan fakta bahwa dalam manifes aplikasi, dalam elemen Aplikasi, Anda perlu mendeklarasikan atribut supportRtl = "true". Tapi saya ingin menyenangkan Anda: jika Anda mengintegrasikan Facebook SDK untuk otorisasi sosial dalam aplikasi Anda, pengembang Facebook yang peduli telah melakukan ini untuk Anda. Dan jika Anda tidak memvalidasi manifes saat penggabungan, maka atribut ini dengan nilai true akan cocok dengan aplikasi Anda, dan itu sudah bisa di Rtl. Ini adalah sesuatu untuk dipikirkan.
Saya pikir sebagian besar dari mereka yang duduk di audiensi mungkin memiliki dukungan minimal untuk Android 4.4. Seseorang lebih beruntung - ini adalah 5.0 dan lebih tinggi. Seseorang bisa kurang beruntung, dan mereka mendukung 4.0, atau, Allah melarang, 2.3. Dalam hal ini, Anda akan memiliki masalah besar, karena dukungan Rtl lengkap di Android telah muncul sejak versi 4.2. Karena itu, dengan minSdk 17, Anda akan menyederhanakan hidup Anda dengan urutan besarnya.
Mentransfer proyek untuk bekerja dengan Rtl dimulai dengan alat refactoring di Android Studio - Tambahkan Dukungan RTL Bila Mungkin. Kita harus membayar upeti, itu berfungsi dengan baik. Itu berjalan melalui file XML markup Anda, melihat keberadaan atribut dengan nilai kiri dan kanan untuk gravitasi, untuk paddings, margin, dan menggantinya dengan awal dan akhir. Jika Anda ingin melihat cara kerja aplikasi Anda secara default dalam mode kanan-ke-kiri, Anda tidak perlu memiliki konten dengan apa yang disebut karakter kuat RTL dalam bahasa Ibrani atau Arab. Anda hanya perlu mengaktifkan Force Layout Direction Layout di pengaturan pengembang.
Apa saja pilihan untuk menyesuaikan UI dan rendering teks yang disediakan Android untuk RTL?
Titik pertama adalah atribut layoutDirection, yang menggunakan opsi Force RTL Layout Direction yang dijelaskan. Dia hanya memiliki empat kemungkinan makna. Artinya, secara default diwarisi dari induk. Kita dapat mengatakan bahwa tata letak digambar berdasarkan lokal yang dipilih. Anda dapat dengan jelas mengatakan bahwa itu ditarik dari kanan ke kiri atau dari kiri ke kanan.
Elemen kedua yang kemungkinan besar diabaikan oleh banyak orang ketika mereka terlibat dalam penyelarasan teks adalah Penyelarasan teks. Banyak yang masih terus menggunakan gravitasi. Jangan gunakan gravitasi untuk menyelaraskan teks, tetapi gunakan Penjajaran teks.
Atribut ketiga adalah arah rendering teks, textDirection. Ini memiliki konfigurasi yang cukup fleksibel. Ini memungkinkan Anda untuk menentukan bagaimana teks ditampilkan tergantung pada karakter kuat pertama mana dalam teks, apakah itu dari set karakter LTR kuat Latin atau dari RTL kuat Ibrani. Tetapi jika Anda sepenuhnya mendukung RTL dalam aplikasi, Anda tidak perlu memotongnya, karena mengabaikan artefak lucu terjadi.
Entah ini telur paskah, atau apakah itu efek samping dalam penerapan editText: petunjuk Anda di editText mulai bubar. Karena itu, dalam hal apa pun, Anda harus menetapkan nilai untuknya.
Jika Anda perlu mengamati render tertentu dari beberapa sumber daya grafis atau markup dalam mode RTL, maka Android memberikan kemampuan untuk mengatur ldrtl kualifikasi di ayah Anda, di mana Anda dapat menempatkan sumber daya apa pun, dan itu akan ditarik dalam mode render RTL seperti yang Anda tentukan.
Kadang-kadang ada kebutuhan untuk runtime untuk menggambar teks yang datang dari backend apa adanya, bagaimana hal itu terjadi, mengabaikan mode di mana aplikasi Anda saat ini bekerja. Bahkan, dalam renderer teks ini dilakukan karena fakta bahwa teks dibingkai oleh apa yang disebut karakter kontrol Bidi Unicode. Logika untuk bekerja dengan karakter-karakter ini sendiri mengandung kelas BidiFormatter, hanya menyediakan satu metode unicodeWrap. Dibutuhkan CharSequence sebagai input, dan mengembalikan string yang dibingkai oleh karakter ini. Ada banyak dari mereka, dan, pada prinsipnya, itu harus menyelesaikan sebagian besar masalah Anda.
Tetapi jika ada sesuatu yang sangat spesifik, w3.org memiliki
artikel bagus tentang cara menggunakan simbol-simbol ini.
Masalah apa yang kami dapatkan ketika kami memulai dukungan RTL dalam aplikasi kami? Pertama-tama, ini adalah konflik standar pelokalan.
BCP47 adalah standar lokalisasi baru, yang secara khusus telah mengubah kode beberapa lokal. Dan faktanya adalah bahwa ada masalah dengan kelas Java lokal. Ini berfungsi secara default dalam mode kompatibilitas ke belakang, dan mengubah kode lokal dari BCP ke ISO. Yaitu, kami melihat ini ketika kode iw alih-alih kode he mulai masuk ke backend kami di tajuk Bahasa Terima.
Jika Anda ingat slide dengan konfigurasi plugin kami, remapping diperlukan hanya untuk ini - untuk menerjemahkan konten dari dia ke iw.
Jika Anda perlu menggunakan format BCP, ini sepenuhnya diimplementasikan dalam proyek Apache Cordova. Mereka memiliki kelas Globalisasi dan implementasi bahasa Lokal.
Poin lain yang "memberikan" dengan dukungan RTL dalam aplikasi adalah animasi. Di sini, manfaatnya, pada kenyataannya, hanya animasi di sepanjang sumbu X yang terpengaruh, dan mungkin satu-satunya solusi atau pendekatan yang akan membantu Anda menghindari lebih banyak masalah adalah kemampuan untuk merevisi absolut animasi ke arah animasi relatif.
Satu masalah yang mungkin diselesaikan hanya dengan refleksi, karena itu diterapkan secara kaku dalam komponen itu sendiri adalah penyelarasan petunjuk dari TextInputLayout. Faktanya adalah bahwa jika petunjuk ditentukan dalam karakter RTL yang kuat dalam bahasa Ibrani, itu akan secara jelas disejajarkan ke kanan, meskipun konten yang Anda masukkan dalam teks edit dapat dari karakter Latin. Begitu juga sebaliknya. Jika petunjuk Anda dalam bahasa Latin, itu akan jelas disejajarkan ke kiri. Ini hanya bisa diselesaikan dengan refleksi.
Pada akhirnya, setelah Anda menerapkan RTL dalam aplikasi Anda, masuk akal untuk mempertimbangkan kembali keparahan untuk masalah RTL yang dianalisis Lint. Hanya ada empat. Jika Anda tidak mendukung RTL dalam aplikasi Anda, tetapi secara eksplisit menggunakan atribut spesifik RTL di suatu tempat, maka ini adalah RtlEnabled (Lint akan memberi tahu Anda tentang ini).
Jika Anda mendukung RTL dalam aplikasi, tetapi minSdkVersion aplikasi Anda di bawah 17, maka Anda juga harus terus menggunakan atribut tipe kiri dan kanan, Anda tidak dapat menggunakan hanya atribut awal dan akhir dalam markup Anda. Inilah yang dipecah RtlCompat. RtlSymmetry bersumpah ketika melihat padding asimetris. Secara umum, pendapat saya adalah bahwa aapt, saat memproses sumber daya, harus macet jika menemukan pad simetris. Jika Anda memerlukan semacam akses asimetris, gunakan margin sebagai parameter tata letak penuh.
Akhirnya, masalah keempat adalah RTL hard-coded. Ini hanya bahwa dalam atribut hanya nilai kiri dan kanan yang ditunjukkan. Pada dasarnya, ini meniadakan alat refactoring. Tambah Dukungan RTL Bila Mungkin. Itu semua berasal dari Lint saat memasuki RTL. Implementasi analisis juga tersedia di AOSP di kelas RtlDetector. Yaitu, jika imajinasi memungkinkan Anda, Anda dapat membuat sesuatu sendiri dengan melihat bagaimana analisisnya sekarang.
Laporan saya hampir berakhir. Saya ingin memberikan beberapa tesis tentang membangun pelokalan yang benar dalam aplikasi kita, yang telah kita pelajari seiring waktu.
Pertama-tama, pada awal proyek, pikirkan tentang internasionalisasi. Saya tidak benar-benar menyebutkannya. Ini sama sekali tidak sama dengan lokalisasi. Faktanya, internasionalisasi memungkinkan lokalisasi dalam aplikasi, dalam produk. Ini bekerja di luar kotak di Jawa karena fakta bahwa ia memiliki dukungan Unicode penuh, dan di Android - karena sistem sumber dayanya yang kaya. Mungkin satu-satunya hal yang dapat terjadi di sini adalah fiksasi kami sebagai pengembang dengan tema bahwa "Saya menulis aplikasi hanya untuk bahasa Rusia, yang berarti saya hanya akan memeriksanya dengan bahasa Rusia." Dan ketika Anda mulai menggunakan bahasa Armenia, Georgia, Ibrani atau Arab dalam aplikasi tersebut, gambarnya terlihat sangat berbeda dan rusak karena paradigma Anda yang biasa.
Momen kedua. Pertimbangkan menanamkan lokalisasi di CI Anda. Sangat mengecewakan untuk mengetahui tentang masalah yang terkait dengan terjemahan selama fase pengujian kandidat rilis, yang dapat Anda siapkan selama beberapa minggu. Artinya, kami sekarang menjalankan tugas ini untuk setiap permintaan kumpulan sehingga kami dapat memastikan sebelumnya bahwa semuanya baik-baik saja dengan terjemahan dan bahwa kami dapat membekukan kode baru ke cabang utama proyek.
Poin ketiga. Hormati karya penerjemah dan anggaran Anda. Pertama, hapus sumber daya yang tidak digunakan karena orang dapat terus menghabiskan waktu dan uang menerjemahkan string yang pada akhirnya tidak Anda gunakan dalam proyek Anda. Kedua, ikuti terjemahan yang ada di repositori Anda di layanan pelokalan, tetapi yang tidak ada dalam kode Anda.
Idealnya, jika API layanan pelokalan Anda memberikan informasi tentang kapan kunci tertentu dibuka, dan Anda dapat menggunakan heuristik seperti "Jika kunci dibuka lebih dari sebulan yang lalu," periksa keberadaannya dalam revisi terbaru dari master brunch. Jika dia tidak ada di sana, kemungkinan besar, ini adalah kandidat yang jelas untuk menghapusnya dan agar pelokalan tidak menghabiskan waktu di sana.
Kandidat yang kurang lebih universal untuk peluru perak adalah untuk menyimpan string di backend, dan bukan pada klien. Paling tidak, ini akan memberi Anda kesempatan untuk selalu membuat mereka relevan di sisi aplikasi.
Kami memiliki audiens pengguna yang sangat beragam, semua orang memandang dunia dan konten aplikasi dengan cara mereka sendiri. Tugas kita sebagai pengembang adalah membantu menjaga persepsi ini. Laporan saya tentang ini sudah berakhir. Terima kasih banyak!