Get best of the week

Internasionalisasi: Membuat Web Dapat Diakses oleh Semua Orang

Ecma International, Komite Teknis 39, atau hanya TC39, adalah sekelompok pengembang JavaScript, pelaksana teknologi, akademisi, dan pihak berkepentingan lainnya yang, bersama-sama dengan komunitas, mendukung dan mengembangkan JavaScript sebagai platform.

Peserta TC39 biasanya berbagi sesuatu yang menarik menggunakan pemahaman mendalam mereka tentang JavaScript. Tetapi beberapa orang berpikir bahwa mereka sudah terlalu jauh dari masalah pengembang biasa. Di mana pengembang bahasa, dan di mana orang yang menulis frontends setiap hari dalam praktik?

Mari berkenalan dengan laporan ini, yang menggabungkan kedalaman pemahaman dan penerapan praktis yang tinggi . Temui kisah baru Romulo Cintra tentang masalah internasionalisasi yang akan ditangani oleh API baru, yang akan segera muncul dalam JavaScript.



Delegasi Romulo Cintra - TC39, telah bekerja dalam pengembangan dan arsitektur selama lebih dari 10 tahun, yang berspesialisasi dalam web, pengembangan ponsel, dan cloud. Dalam laporan ini, Anda akan belajar langsung ketua bersama Kelompok Kerja MessageFormat , opsi mana yang sudah tersedia untuk menyelesaikan masalah yang ada, dan dalam bentuk apa mereka akan dipecahkan menggunakan API baru dalam JavaScript itu sendiri.

Di bawah potongan, transkrip teks lengkap dari laporan Romulo dan tautan ke video. Jika Anda suka membaca - artikel ini memiliki semuanya, Anda tidak akan melewatkan apa pun. Jika Anda memiliki waktu untuk memulai perekaman video, maka Anda akan memiliki sekitar satu jam perekaman video yang bagus dengan slide yang menarik dan bahasa Inggris yang dapat dimengerti.

Narasi lebih lanjut atas nama pembicara.


Ada tiga hal yang perlu Anda ketahui tentang keadaan internasionalisasi dan lokalisasi: semuanya sangat, sangat, sangat buruk. Nama saya Romulo Cintra, dan saya terlibat dalam aplikasi arsitektur keuangan. Saya banyak berbicara dengan orang-orang dari TC39 dan melihat bagaimana mereka mencoba menjadikan dunia JavaScript tempat yang lebih baik. Selain itu, saya adalah pendukung kuat open source, dan di waktu senggang saya adalah seorang guru di School of Technology di Barcelona.

Masalah internasionalisasi sangat penting. Kebetulan di Bumi kita ada banyak orang dan bahasa yang berbeda. Di dunia saat ini ada sekitar 195 negara dan 6 ribu bahasa. Ini membuat tugas kita sangat sulit. Pikirkan hal lain: Saya menulis artikel dan membaca laporan dalam bahasa Inggris, bukan dalam bahasa Rusia; kami sudah memiliki masalah internasionalisasi. Jika seseorang tidak berbicara bahasa Inggris, dia akan dikecualikan dari percakapan kami dengan Anda. Untuk mencegah hal ini terjadi, internasionalisasi diciptakan.

Internasionalisasi bahasa Inggris disingkat i18n. Angka 18 adalah jumlah karakter antara huruf i dan n dalam kata ini. Singkatnya, internasionalisasi adalah desain perangkat lunak untuk menyederhanakan lokalisasi sebanyak mungkin. Berkat internasionalisasi, perangkat lunak dapat mendukung pengaturan lokal, bahasa, mata uang, dan sebagainya. Internasionalisasi membuat web lebih mudah diakses oleh semua orang. Di sini Anda dapat menggambar paralel dengan pengembangan melalui pengujian (development-driven development): pertama-tama tes ditulis, dan kemudian kode; dengan internasionalisasi perlu untuk melakukan hal yang sama. Biasanya orang berpikir tentang internasionalisasi setelah kode ditulis, tetapi itu salah.

Mirip dengan i18n, l10n adalah singkatan untuk lokalisasi, dan 10 adalah jumlah karakter antara l pertama dan terakhir n. Lokalisasi adalah adaptasi suatu produk dengan bahasa dan lingkungan budaya di mana ia didistribusikan. Artinya, Anda tidak hanya perlu menerjemahkan "Halo" menjadi "Halo", tetapi juga menggunakan mata uang lokal, pemisah desimal, dan sebagainya, yaitu, membuat perangkat lunak lebih akrab bagi pengguna. Ini lebih dari sekedar terjemahan.

Berapa banyak bahasa yang didukung proyek web Anda? Banyak yang memiliki lebih dari dua. Adakah yang memiliki lebih dari lima? Bagaimana dengan 15? Kami mendukung sekitar 25 bahasa. Kami tidak memiliki dukungan yang sangat baik, karena internasionalisasi tidak diorganisir dengan cara terbaik. Dalam perjalanan laporan, saya akan menjelaskan cara meningkatkan internasionalisasi, dan berbicara tentang langkah-langkah yang kami ambil.

Jadi, saya ulangi sekali lagi: internasionalisasi berarti menyederhanakan pelokalan, memberikan dukungan untuk itu pada tingkat arsitektur. Dan lokalisasi adalah adaptasi perangkat lunak dengan realitas lokal. Terjemahan sangat sering tidak cocok dengan aslinya - mari kita ambil contoh dari industri film, di mana nama film "Pain and Gain" diterjemahkan sebagai "Blood and Sweat: Anabolics".



Atau contoh lain: sebuah iklan untuk pemandian Rusia, di mana terjemahan bahasa Inggris mengatakan "Rusia krematorium" (krematorium Rusia).



Saya ragu bahwa ini akan menarik pelanggan, setidaknya hidup. Internasionalisasi dan lokalisasi sangat penting justru karena memungkinkan kita untuk menyampaikan apa yang ingin kita katakan kepada pengguna. Intinya, internasionalisasi adalah penyediaan aksesibilitas, karena jika Anda tidak dapat memahami perangkat lunak yang bekerja dengan Anda, maka pada kenyataannya pilihan Anda terbatas. Hal ini bermanfaat bagi semua orang bahwa perangkat lunak lebih mudah diakses, karena memberikan jangkauan pengguna yang lebih luas, dan karenanya, penghasilan yang lebih tinggi; itu juga membuat web lebih baik.

Format pesan


Perhatikan contoh kode:

'es-ES': { 
    HELLO_WORLD: '¡Hola mundo!' 
}, 
'en-GB': { 
    HELLO_WORLD: 'Hello world!'

Kita perlu menerjemahkan objek string kita. Kami memiliki variabel HELLO_WORLDdengan baris yang sesuai di setiap bahasa. Untuk terjemahan seperti itu dalam banyak bahasa (misalnya, Java), ada format MessageFormat . Mari kita coba mencari tahu apa itu. Pertama, sedikit tentang beberapa teknologi dasar - mari kita mulai dengan Unicode. Ini adalah standar yang menciptakan ruang tunggal untuk karakter dari berbagai bahasa. Mari kita menggambar analogi dengan catur: setiap jenis karya dapat memiliki bentuk yang berbeda, tetapi kita selalu tahu di mana tepatnya mereka seharusnya berada di papan tulis. Yah, tentu saja, ada berbagai format Unicode dengan jumlah byte yang berbeda: UTF-8, UTF-16 dan UTF-32. Sekarang meta tag yang paling umum digunakan adalah UTF-8. Dengan Unicode, browser dapat menampilkan karakter khusus, jika tag ini`metalupa, tidak ada yang akan mengerti simbol apa yang kita miliki di halaman.

Selain Unicode, dua teknologi penting lainnya adalah CLDR dan ICU. CLDR adalah sejenis basis data huruf, negara, mata uang, zona waktu, dll., Disimpan dalam berbagai bahasa di dunia. Tidak semua 6 ribu bahasa di dunia hadir di dalamnya, pekerjaan masih berlangsung pada database ini. Pembaruan terakhir adalah Oktober lalu. Proyek penting lainnya adalah ICU. Ini adalah basis data kata, angka, dan simbol yang sangat besar dari berbagai bahasa, yang disediakan dalam bentuk metode untuk menyortir, menormalkan, memformat, dll. Perpustakaan ini digunakan dalam banyak bahasa pemrograman. Dalam JavaScript, ICU adalah inti dari API Intl. Tetapi ada begitu banyak materi yang beragam dalam bahasa-bahasa di dunia yang perlu ditampilkan di browser sehingga pekerjaan memasukkan mereka dalam standar ini masih jauh dari selesai.

MessageFormat adalah format yang memungkinkan Anda untuk mengaitkan kunci tertentu dengan pesan tertentu dalam bahasa tertentu. Dalam beberapa kasus, variabel dapat dikirimkan ke MessageFormat , itu mendefinisikan mereka dan memasukkannya di baris terakhir. Masalah yang sama diselesaikan dengan cara yang sedikit berbeda dalam bahasa lain. Di Android, MessageFormat diimplementasikan di Jawa. Di sana, untuk bekerja dengan format ini, perpustakaan khusus tidak diperlukan, Android dapat berinteraksi dengannya. Di iOS, ada API yang sangat mirip dengan yang ada di JavaScript. Itu dibangun ke dalam sistem, tidak perlu mengunduh apa pun di sana, cukup lewati baris yang diperlukan untuk metode API ini.

Bagaimana masalah ini diselesaikan dalam JavaScript? Belum. Tetapi kami memiliki banyak perpustakaan yang menawarkan solusi.



Ini menunjukkan jumlah unduhan yang paling populer di antara mereka (dan dua yang kurang populer, fasih dari Mozilla dan fbt dari Facebook). Hampir dua juta unduhan dilakukan setiap minggu, sehingga ada kebutuhan untuk perpustakaan untuk internasionalisasi.

Perpustakaan


Kami akan memperkenalkan secara singkat beberapa perpustakaan ini, dan mulai dengan i18next. Pengembangnya telah membuat banyak perubahan pada MessageFormat , dan tidak sepenuhnya mengikuti ICU. Namun, itu adalah perpustakaan yang sangat bagus. Implementasi MessageFormat memiliki banyak keuntungan, misalnya, kemampuan untuk menggunakan interpolasi string (yang tidak tersedia dalam format ICU). Namun, ada juga kerugiannya, misalnya, pesan jamak tidak dapat ditempatkan pada baris yang sama dengan satu-satunya, seperti yang dapat dilakukan di ICU.

Salah satu perpustakaan internasionalisasi yang paling terkenal adalah intl-messageformat. Setiap minggu itu diunduh lebih dari 700 ribu kali. Dukungannya ditangani oleh rekan saya, Long Hu. Popularitasnya dijelaskan oleh fakta bahwa react-intl dibuat di atasnya. Jadi jika Anda menggunakan Bereaksi, maka kemungkinan besar Anda memiliki perpustakaan ini. Pengembangnya juga berpartisipasi dalam ECMA-402, dan karena itu ia mencoba mematuhi standar ICU.

var MESSAGES = { 
    'en-US': { 
        NUM_PHOTOS: 'You have {numPhotos, plural, ' +
            '=0 {no photos.}' +
            '=1 {one photo.}' +
            'other {# photos.}}'
}, 
    'es-MX': {
        NUM_PHOTOS: 'Usted {numPhotos, plural, ' +
            '=0 {no tiene fotos.}' + 
            '=1 {tiene una foto.}' 
            +'other {tiene # fotos.}}' 
    } 
};

Implementasinya sangat mirip dengan MessageFormat . Di sini Anda dapat melewatkan variabel dan menunjukkan perlunya jamak.

Sebelum beralih ke contoh kode, saya akan berbicara tentang dua perpustakaan baru yang sekarang dalam mode, mereka diciptakan oleh Facebook dan Mozilla.



Seluruh API tidak dapat ditampilkan secara keseluruhan, tetapi ambil kata saya untuk itu: para pengembang perpustakaan ini melakukan yang terbaik, ada persis apa yang kami lewatkan saat ini. Benar, Facebook membuatnya dengan gayanya sendiri: markupnya sendiri, kemampuan untuk berjalan selama tata letak, ekstraksi peta hash dari string yang dapat diterjemahkan secara otomatis. Masalahnya adalah bahwa semua ini difokuskan pada skala di mana programmer rata-rata jarang bekerja. Proyek ini sangat muda, dan mereka ingin mengintegrasikannya dengan perpustakaan terkenal lainnya, misalnya, dengan React. Di masa depan, ia kemungkinan akan mendapatkan popularitas.

Semua di atas adalah perpustakaan yang perlu diunduh tambahan, mereka tidak dibangun ke dalam browser. Dengan hanya satu browser, kami tidak akan melangkah jauh, jadi semuanya buruk dengan lokalisasi. MessageFormat dapat membantu kami mengubah keadaan ini . Meskipun kita tidak bisa menggunakannya, tapi percayalah: masa depan ada padanya. Sekarang kami secara aktif mengerjakannya, membangun pemangku kepentingan, mencari ide-ide segar untuk MessageFormat baru . Dalam versi aslinya, format ini sudah usang, kebutuhan pengembang telah berevolusi secara signifikan sejak awal. Format baru harus dibuat dengan kualitas tinggi dan mudah digunakan.

Intl.DateTimeFormat


Browser sudah memiliki banyak mekanisme internal untuk internasionalisasi dan lokalisasi, kebanyakan dari mereka tidak tahu tentang mereka dan tidak menggunakannya. Pernahkah Anda mendengar tentang Intl.DateTimeFormat? Dalam proyek ini, kami terus-menerus membuat API baru. Kemungkinan tidak diperlukan lagi untuk Moment.js , Day.js , date-fns .

const myDate = new Date(); 
new Intl.DateTimeFormat('ru', { timeStyle : 'short'}).format(myDate); 
// short → 19:49 
// medium → 19:49:17 
// long → 19:49:17 GMT+2
// full → 19:49:17  ,

Ada timeStyle, ini dibuat beberapa bulan yang lalu dan memungkinkan Anda untuk memformat tanggal dan waktu tanpa menggunakan Moment.js. Selain itu, ada metode formatRange . Tugas apa pun yang terkait dengan memilih rentang tanggal (seperti di situs dengan fungsi reservasi) selalu sulit. Tetapi metode untuk ini sudah ada di browser. Dan, yang paling penting, metode ini mendukung internasionalisasi, sambil menghilangkan kebutuhan untuk mengunduh pustaka tambahan.

Intl.RelativeTimeFormat


Saya mengerjakan dokumentasi untuk bagian kedua dari proyek ini, dan jika Anda juga ingin berpartisipasi, kami memerlukan bantuan untuk menerjemahkan ke dalam bahasa Rusia dan memenuhi standar. RelativeTimeFormat diperlukan ketika Anda perlu melakukan hitung mundur.

const myTime = new Intl.RelativeTimeFormat('ru', { style: 'narrow' }); 
myTime.format(2 , 'quarter'); 
//Style Narrow : +2 . → in 2 qtrs. → dentro de 2 trim. 
//Style Long :  2  → in 2 quarters → dentro de 2 trimestres

Sekarang cukup mudah untuk melakukan ini, Anda dapat menentukan waktu dalam dua hari, dua minggu, dalam seperempat, dll. Sebelumnya, format seperti itu di web tidak ada.

const myTime = new Intl.RelativeTimeFormat('ru', { style: 'narrow' }); 
myTime.format(2 , 'day'); 
//Style Narrow : +2 . → in 2 days → dentro de 2 días 
//Style Long :  2  → dentro de 2 días myTime.format(-1 , 'day');
//Style Narrow : -1 . → 1 day ago → hace 1 día 
//Style Long : 1   → 1 day ago → hace 1 día //Numeric(auto) :  → yesterday → ayer

Ini adalah contoh dalam bahasa Rusia. Anda sendiri dapat menguji operasi kode ini, karena sudah ada di browser Anda.

const myTime = new Intl.RelativeTimeFormat('ru', { style: 'narrow' }); 
myTime.format(20 , 'seconds'); 
//Style Narrow : +20  → in 20 sec. → dentro de 20 s 
//Style Long :  20  → in 20 seconds → dentro de 20 segundos

Metode ini sangat berguna, dapat memberikan waktu dalam format singkat yang Anda lihat di atas. Saya menekankan bahwa untuk semua ini Anda tidak perlu menggunakan perpustakaan pihak ketiga.

Intl.NumberFormat


Hal berikutnya yang ingin saya bagikan adalah Intl.NumberFormat . Saya akan berbicara tentang tahap ketiga, tetapi hanya yang kedua disajikan dalam contoh, karena beberapa perubahan masih dibahas. Intl.NumberFormat bekerja dengan unit dan formulir catatan. Perlu memperhatikan apa yang dia lakukan dengan unit: dia memungkinkan Anda untuk bekerja dengan gaya yang berbeda.

new Intl.NumberFormat("ru", { 
style: "unit", 
unit: "liter", unitDisplay: "long" 
}).format(16); 
// → 16  → 16 liters → 16 litros

Semua unit diambil dari UTC 35, dan ada banyak dari mereka. Secara total, sekitar 140 unit untuk pemformatan disajikan di sini. Jadi sekarang internasionalisasi lebih mudah dari sebelumnya. Anda hanya perlu menerjemahkan baris Anda, dan semua dinamika yang diperlukan sudah terkandung di browser.

const nbr = 987654321; 
new Intl.NumberFormat('ru', { notation: 'scientific' }).format(nbr); 
// → 9,877E8 → 9.877E8 (en-US) 
new Intl.NumberFormat('ru', { notation: 'engineering' }).format(nbr); 
// → 987,654E6 → 987.654E6 (en-US) 
new Intl.NumberFormat('ru', { notation: 'compact' }).format(nbr); 
// → 988  → 988M (en-US) → 9.9亿 (zn-CN) 
new Intl.NumberFormat('ru', { notation: 'compact', compactDisplay: 'long' }).format(nbr); 
// → 988  → 988 millions (fr)

Sekarang untuk formulir rekaman. Sejujurnya, saya tidak terlalu sering menggunakannya, karena saya tidak menggunakan bentuk rekaman dengan eksponen (catatan ilmiah), dan saya tidak perlu menunjukkan jumlah yang besar. Tetapi jika Anda membutuhkannya, maka ada API yang sesuai khusus untuk Anda.

Intl.ListFormat


API lain yang bermanfaat adalah Intl.ListFormat , yang sudah berada di tahap ketiga dan memungkinkan Anda untuk memformat daftar dengan dua cara berbeda. Misalkan saya perlu mengatakan kalimat "Saya akan pergi ke HolyJS." Kita dapat membuat daftar yang menyertakan garis "Moskow" dan "St. Petersburg ", tentukan parameter" konjungsi ", dan garis-garis akan digabungkan dengan penyatuan bahasa Rusia" dan ". Ini adalah fitur yang sama sekali baru, dan sangat berguna.



Jika Anda menentukan "disjungsi", maka kami mendapatkan gabungan "atau".



Akhirnya, fungsi dapat secara otomatis menentukan bahasa dan alfabet yang digunakan dan mengurutkan item daftar sesuai.

Peraturan Internasional


API penting lainnya adalah Intl.PluralRules . API ini adalah yang tertua, tetapi karena alasan tertentu tidak ada yang menggunakannya.



Ketika saya melihat daftar finalis dalam balapan atau sepak bola, angka-angka selalu ditunjukkan di sebelah nama: "1", "2", "3", dll. Tapi ini tidak sesuai dengan cara kita mengatakan akan jauh lebih dekat untuk pidato, tulis "1", "2", "3". Dan untuk ini ada API khusus, yang tidak begitu sulit digunakan.



Misalnya, kita dapat menulis frasa “1 kucing”, “0 kucing”, “0,5 kucing”, “1,5 kucing”, dan API akan secara otomatis memilih akhiran jamak yang benar.

Intl.DisplayNames


Ini adalah salah satu API paling populer, karena kita sering harus menampilkan daftar negara. Misalkan kita memiliki daftar negara - misalnya, dalam database atau di JSON. Lalu, setiap kali Anda mengganti bahasa, kami perlu memuat JSON terpisah dengan daftar negara, mata uang, dan sebagainya yang baru. Ada terlalu banyak JSON ini, dan bagaimana akhirnya? Kami membuat layanan mikro di mana basis data dengan berbagai bahasa sudah terpasang, dan kami mengekstrak semua data darinya. Tentu saja, dalam contoh dengan daftar negara kami beruntung dan kami perlu memperbarui data jarang - tetapi tidak akan selalu seperti itu, kan? Kami tidak dapat menyelesaikan semua masalah sekaligus, tetapi DisplayNames menyelesaikan sebagian dari masalah tersebut. Anda memiliki API seperti pada contoh di bawah ini, dan Anda hanya dapat meminta daftar mata uang atau hanya daftar negara:

const currencyNames = new Intl.DisplayNames(['en'], {type: 'currency'}); currencyNames.of('USD'); // "US Dollar" 
currencyNames.of('EUR'); // "Euro" 
currencyNames.of('TWD'); // "New Taiwan Dollar" 
currencyNames.of('CNY'); // "Chinese Yuan"


const languageNames = new Intl.DisplayNames(['en'], {type: 'language'}); languageNames.of('fr'); // "French" 
languageNames.of('de'); // "German" 
languageNames.of('fr-CA'); // "Canadian French" 
languageNames.of('zh-Hant'); // "Traditional Chinese"

Ini adalah hal yang sangat berguna. Ini bekerja tidak hanya dengan negara dan mata uang: dengan cara yang sama, Anda dapat bekerja dengan bulan, hari dalam seminggu dan banyak hal lain yang Anda butuhkan sebagai pengembang.

Hasil dan rencana untuk masa depan


Sejauh ini, kami telah berbicara tentang API yang ada. Mari kita beralih ke rencana kita untuk masa depan. Bahasa ibu saya adalah portugis. Jadi di situs saya, saya perlu mendukung setidaknya Portugis dan Inggris. Dan karena kita sangat dekat dengan Spanyol, bahasa Spanyol juga berguna. Portugal adalah negara yang sangat kecil, dan Prancis juga tidak begitu jauh, jadi akan menyenangkan untuk menambahkan bahasa Prancis ke daftar ini.

Bagi kami MessageFormatsangat relevan, dan akan segera muncul. Ada perpustakaan, dan ada pengembang yang mengerjakannya. Semua pengembang ini sedang mengerjakan masalah terkait. Sebagian besar pembuat perpustakaan paling populer dan perusahaan besar (Netflix, Amazon, Facebook) menyetujui setidaknya satu hal: sekarang ada kebutuhan mendesak untuk internasionalisasi. Ini juga ditunjukkan oleh dua juta unduhan per minggu. Jadi sekarang kita dapat menulis MessageFormat lagi, dan melakukannya dengan cara yang berkualitas.

Siapa yang akan mendapat manfaat dari internasionalisasi yang tepat? Seluruh web: semua perusahaan, semua proyek, semua perpustakaan. Perpustakaan seperti Intl.MessageFormattidak akan hilang di mana pun, tetapi akan mulai bekerja dengan cara baru. Anda tidak perlu mengunduh data, karena semua data sudah ada di browser. Kemungkinan besar, Anda tidak perlu beralih ke perpustakaan baru. Beberapa perpustakaan ini sudah berfungsi sebagai polyfill untuk beberapa implementasi. Beberapa implementasi yang saya sebutkan berada di tahap ketiga dan tidak diimplementasikan di semua browser. Tetapi pustaka seperti Intl.MessageFormat menyediakan polyfillings untuk fungsi ini. Secara umum, bab baru dalam sejarah web akan datang - sebuah revolusi nyata. Web akan menjadi dapat diakses dan dimengerti oleh semua orang. Ini sangat penting.

Saya percaya bahwa sangat penting untuk memastikan keunikan proyek kami. Jika ada satu format yang dapat digunakan dalam C ++, Java, dan JavaScript, lalu mengapa tidak menggunakan format ini di mana-mana? Ketika kita menulis halaman web, kita sering perlu membuat versi mobile mereka, dalam hal ini kita harus melakukan banyak pekerjaan dua kali. Jika kami memiliki satu format untuk semuanya, maka kami bisa menggunakan sumber daya dan API yang ada. Kami membutuhkan tingkat integrasi baru dengan alat. Internasionalisasi disediakan tidak hanya oleh karya pengembang yang terlibat langsung di dalamnya. Baginya, modularitas sangat penting, karena sering kali nyaman menggunakan alat pemformatan Anda sendiri, kode Anda sendiri. Karena itu, Anda tidak boleh menutup API, mereka harus terbuka sehingga mereka dapat menghubungkan apa yang dibutuhkan oleh situasi.Poin penting lainnya: API ini harus asli. CLDRs menyediakan data yang dibutuhkan API internasionalisasi. Jika Anda menjalankan Windows atau MacOS, maka Anda sudah mengunduh data dari CLDR. CLDR adalah repositori unik, tidak ada yang menduplikasi fungsinya. Ini berarti bahwa data hanya dapat diunduh satu kali dan dibuat umum untuk seluruh sistem operasi. Jika semua data untuk API Intl sudah dimuat dalam sistem operasi, lalu mengapa tidak menyediakannya untuk semua perangkat lunak pada sistem ini?Jika semua data untuk API Intl sudah dimuat dalam sistem operasi, lalu mengapa tidak menyediakannya untuk semua perangkat lunak pada sistem ini?Jika semua data untuk API Intl sudah dimuat dalam sistem operasi, lalu mengapa tidak menyediakannya untuk semua perangkat lunak pada sistem ini?

Pengalaman kami mengajari kami untuk mengingat bahwa kami tidak sendirian, bahwa tidak hanya programmer yang bekerja dalam internasionalisasi. Kami adalah pengembang, bukan penerjemah. Misalkan kita perlu melakukan umpan garis di antarmuka kita, kita mengirimkannya ke perusahaan terjemahan. Tetapi penerjemah sering tidak memiliki konteks untuk baris-baris ini. Ini juga tidak ada di MessageFormat . Kadang-kadang ini menyebabkan kesalahan, seperti yang telah kita lihat dalam contoh yang disebutkan dengan krematorium Rusia.

Akhirnya, saya percaya bahwa API untuk internasionalisasi harus mudah digunakan, dan semua orang harus dapat melakukan internasionalisasi - ini seharusnya tidak memerlukan terlalu banyak waktu dan upaya. Saat menulis kode untuk internasionalisasi, Anda harus dipandu sejak awal. Lagi pula, dengan TDD, mereka pertama kali menulis tes, dan kemudian kode; mari kita mulai proyek web kami pada prinsip ini dengan internasionalisasi dan pelokalan yang tepat. Ini akan memungkinkan kami untuk membuat situs yang nyaman dan dapat diakses oleh semua orang.
HolyJS 2020 Piter «Speak my language %app%». , , : . HolyJS 2020 Piter . , .

More articles:


All Articles