Saya ingin melihat kemampuan untuk melakukan binding dinamis dalam mode aot. Ada dua kasus penggunaan khususnya untuk mendukung mengapa ini harus ditambahkan ke peta jalan.

Yang pertama adalah kasus penggunaan dasar di mana Anda tidak ingin aplikasi terpisah untuk setiap bahasa. Ini memerlukan semacam logika pengalihan di luar aplikasi dan tidak mengizinkan perubahan dinamis bahasa tanpa memuat ulang situs secara lengkap.

Yang kedua adalah kasus di mana Anda menyematkan aplikasi di ponsel menggunakan cordova. Sejauh yang saya tahu pilihan Anda adalah jit, sehingga memperlambat situs, membuat aplikasi terpisah untuk setiap bahasa, atau memasukkan setiap bahasa dalam aplikasi (yang tentu saja membuatnya membengkak). Tak satu pun dari ini adalah pilihan yang baik. Sepertinya Ionic tidak menggunakan i18n, dan saya bertanya-tanya apakah ini alasannya.

@ jlutz777 itu adalah 2 kasus penggunaan yang valid, subjek ini telah dibahas secara internal akhir-akhir ini dan saya juga menganjurkan itu. Ini tidak mudah dilakukan mengingat bagaimana i18n dan AoT bekerja di Angular, tetapi mungkin di masa depan setelah kami mendapatkan proses kompilasi baru untuk AoT di v5.
Saya akan menambahkannya ke peta jalan sekali/jika kami memiliki sesuatu yang resmi dan konkret tentangnya.

Saya sedang mengerjakan aplikasi Electron + Angular 2 dan sekarang mencoba menambahkan dukungan untuk Lokalisasi untuk beberapa bahasa menggunakan fitur i18n dengan Angular. Sebenarnya ekstraksi string-template dan mengonversinya dalam format file bahasa yang berbeda didokumentasikan dengan jelas, meskipun saya masih belum dapat memahami dan mencari:

• Bisakah saya beralih bahasa secara dinamis? atau apakah saya perlu membuat aplikasi secara terpisah untuk bahasa yang berbeda.
• Bisakah saya mengelola/menggabungkan semua string di satu tempat (dalam bentuk pasangan kunci/nilai), sehingga saya dapat mengubah
  string di satu tempat yang akan dilakukan di beberapa tempat?
• Bisakah saya mengakses file yang dilokalkan dari mana saja selain templat untuk mendapatkan string bahasa tertentu dengan
  kunci yang disediakan? (sama seperti yang saya tanyakan di atas).

Poin 2 dan 3 akan diselesaikan dengan fitur "Gunakan string terjemahan di luar template - #11405".
Untuk poin 1 lihat jawaban yang saya berikan kepada @jlutz777 di atas. Untuk saat ini Anda masih harus membuat aplikasi dalam berbagai bahasa, atau menggunakan JIT yang dapat memuat terjemahan secara dinamis saat bootstrap (tidak beralih saat runtime, tetapi masih lebih baik daripada harus memaketkannya x kali).

bahasa UI yang digunakan dalam aplikasi harus sesuatu yang tidak memerlukan pembuatan beberapa versi dari aplikasi yang sama. ini seharusnya tidak menjadi masalah "kompiler". jika ya maka kompilernya cacat. masalahnya harus salah satu membuat desain aplikasi sedemikian rupa sehingga teks dapat dimuat dari file data pada saat dijalankan. yang harus dilakukan dengan modul / perpustakaan yang dapat dimuat dan digunakan seperti yang lain. jangan jadikan itu sebagai fungsi kompiler sama sekali.

@figuerres itu adalah sesuatu yang akan diubah di masa depan, belum ada janji tetapi kami menyadari masalah ini dan kami sedang mencari solusi yang mungkin, menggunakan file eksternal adalah salah satunya

Hai @ocombe - Sepertinya kita mungkin akan menggunakan i18n di Angular untuk aplikasi kita. Apakah ada fitur dalam dokumen yang menurut Anda mungkin tidak digunakan lagi atau akan mengalami perubahan besar dalam beberapa bulan mendatang? Setiap info akan sangat dihargai. Dan sekali lagi terima kasih untuk DVDnya!

Hai @rjsteinert! Senang mengetahui itu!
Hanya ada satu perubahan besar yang direncanakan untuk saat ini, yaitu pembuatan ID otomatis. Metode akan berubah dan ID tidak akan cocok lagi, tetapi akan ada alat migrasi cli untuk memperbarui file terjemahan Anda (dan parameter yang hanya dapat Anda gunakan untuk bermigrasi jika Anda sudah siap).

Saya banyak mencari di Google tentang topik ini hari ini dan saya bertanya-tanya apakah mungkin ada solusi "sederhana" seperti mengganti tag i18n dengan panggilan ke layanan alih-alih terjemahan?

Saat ini:
<span i18n>Hello world</span> => dirender menjadi <span>Hello world</span>

Ide saya:
<span i18n>Hello world</span> => dirender menjadi <span>{{i18nservice.translate('pass-in-the-generated-message-id')}}</span>

Dengan cara ini, terjemahan sebenarnya dapat dilakukan secara dinamis di AOT karena layanan dapat diisi dari API, file, dll. dan bahkan berpindah lokal tidak akan lebih dari i18nservice.setLocale('de-DE') dengan memuat sumber baru.
Ekstraksi teks dengan xi18n-tool akan tetap berfungsi seperti sebelumnya dan kami dapat memanfaatkan id pesan yang dihasilkan untuk digunakan sebagai indeks untuk layanan terjemahan.
Implementasi saat ini juga akan tetap bekerja dengan sempurna karena ngc hanya dapat mencari tanda "--use-i18nservice" dan jika tidak, kompilasi seperti sampai sekarang.

Satu masalah yang saat ini dapat saya identifikasi adalah injeksi layanan i18n ke setiap komponen karena harus ada dalam konteks komponen agar dapat dipanggil, tetapi itu harus dapat dipecahkan dengan satu atau lain cara.

Ada pemikiran tentang ini?

Ini adalah salah satu hal yang kami pertimbangkan ya, masih ada masalah bagaimana memperlakukan blok kode di dalam terjemahan tersebut ketika kompiler tidak tersedia saat runtime (AOT). Ini berarti bahwa kita tidak dapat menggunakan komponen/arahan/pipa sudut di dalam terjemahan...

Ya, tidak memikirkan itu.
Saat ini saya sedang mengembangkan POC/solusi yang menyelaraskan semua terjemahan ke dalam HTML pada langkah pembuatan (webpack), membungkusnya menjadi ng-container dengan ng-switch.
Untuk i18n-atribut itu menggunakan arahan yang mengaturnya di nativeElement.
Terjemahan itu sendiri juga "dirender" kemudian menggantikan semua placeholder <x id=".. "/> itu.

Ini jelek tetapi berfungsi ... tidak sabar menunggu ng untuk mendukungnya secara asli.
Akan publish POC akhir minggu ini, mungkin bisa berguna untuk konsepsi selanjutnya.

Saya datang dengan "solusi" yang sesuai dengan kebutuhan saya sampai ada implementasi.
Pra-pemuat sekarang membuat HTML untuk semua lokal sebelum diserahkan ke kompiler, sejauh ini berfungsi seperti pesona.

Repo: https://github.com/actra-development-oss/ng-i18n-aot-loader
NPM: https://www.npmjs.com/package/@actra-development-oss/ng -i18n-aot-loader

mungkin suatu komponen dapat memiliki atribut yang memberi tahu sistem/kompiler bahwa ia membutuhkan layanan.
layanan itu kemudian mengambil dan id dan lokal dan mengembalikan teks/markup yang dilokalkan.
semua teks yang dilokalkan disimpan di server sebagai sumber daya yang dapat dibaca oleh layanan.

jika suatu komponen tidak memiliki atribut tidak ada run-time lokal.
jika komponen memilikinya maka ia memanggil dapatkan data yang dilokalkan saat run-time.
kompiler hanya membangun file data dan menghubungkan layanan.

ini menurut saya cara yang baik untuk menangani kebutuhan paling umum untuk sebagian besar aplikasi dan tidak mengharuskan situs untuk membangun dan memelihara banyak salinan dari aplikasi yang sama.

Aku juga punya ide itu.
Masalahnya adalah terjemahan dapat berisi binding dan dengan demikian akan membuka sistem untuk injeksi kode saat memuat file terjemahan dari sumber eksternal.
Selain itu, kompiler akan diperlukan untuk menyelesaikan ikatan tersebut secara dinamis tergantung pada terjemahannya.

IMHO solusi yang valid bisa menjadi cara saya mengimplementasikan sebagai POC (lihat komentar di atas) ke terjemahan sebaris pada waktu kompilasi, hanya dengan cara yang lebih elegan dan terintegrasi.
Kedua masalah yang disebutkan di atas akan dihilangkan, satu-satunya downside yang dapat saya bayangkan adalah mungkin ukuran bundel, itu akan tumbuh menjadi "bundel biasa" + (diterjemahkan ukuran html * lokal).
Itu dapat diturunkan hanya dengan ng-switch menggunakan i18n -tag html alih-alih seluruh dokumen tetapi masih ada masalah untuk i18n-* -tag.

baik di sini adalah hal; kadang ada batasnya....

dari sudut pandang praktis mungkin lebih baik untuk tidak memilikinya, Anda dapat memiliki sepotong teks yang dapat diberikan dalam berbagai bahasa. akhir cerita.

Anda perlu memiliki data yang terikat chunk ? ok tapi itu tidak ada di dalam teks internasional, itu harus terpisah. Anda masih dapat menggunakan html dan css untuk menata dan memformat hasilnya. tetapi Anda tidak dapat menyematkan atau menggabungkannya dengan segala cara yang dapat Anda pikirkan.
seperti katakanlah tag div atau ap dapat memiliki jumlah rentang satu rentang adalah teks dan rentang lainnya adalah tanggal terikat rentang teks terikat ke layanan lokal i18n, tanggal terikat ke beberapa layanan tanggal kedua rentang berada dalam a tag paragraf yang memformatnya.

Tetap sederhana, buat itu berfungsi untuk 95% dari semua pengguna terlebih dahulu, lalu cari tahu kasus tepi.

Saya tidak melihatnya sebagai kasus tepi, ini bisnis seperti biasa.
Angular adalah kerangka kerja tingkat bisnis sehingga banyak, jika tidak semua, pengguna i18n akan memerlukan pengikatan, atau setidaknya pluralisasi dan pemilihan, di dalam teks.

<span i18n>Hello, {user.gender, select, m {Mr.}, f {Ms.}} {{user.name}}</span>
Bagaimana Anda menyelesaikannya dengan string yang terpisah?
Jawaban sederhana: Anda tidak bisa, karena Anda tidak dapat mengetahui aturan bahasa target, tidak semua bahasa mengikuti format 'sapaan', 'jenis kelamin', 'nama'.

Memisahkan potongan-potongan itu akan:

• membunuh konteks, penerjemah tidak akan mendapatkan arti dari kalimat lengkap
• menggabungkan potongan dalam urutan yang benar dengan CSS tidak mungkin, Anda harus menentukan aturan untuk setiap terjemahan, jadi pria CSS perlu mengetahui bahasa target atau pria penerjemah perlu tahu CSS, keduanya bisa diterima.

Core i18n bekerja dalam sudut seperti yang diharapkan dan dapat digunakan untuk aplikasi kelas bisnis, satu-satunya hal yang hilang tampaknya adalah kompatibilitas AOT, jadi saya tidak mengerti sudut pandang Anda mengapa sistem kerja yang kuat harus diganti dengan sesuatu yang tidak setengahnya mampu membutuhkan beberapa kali pekerjaan untuk menyelesaikannya.

Kami memiliki pertemuan besok untuk menemukan solusi untuk masalah ini.

@ocombe senang mendengar ini, saya harap ini mengarah pada beberapa hal bagus untuk rilis Angular di masa mendatang, di sini di tempat kerja kami sangat menyukai cara kerjanya sebagian besar untuk kebutuhan pengembangan kami!

@ocombe , apakah mungkin untuk mengubah bahasa tanpa memuat ulang seluruh dokumen ? Aku jelaskan :
Saya berada di halaman bernama "tentang" tetapi ketika saya mengubah bahasa, saya diarahkan ke halaman entri utama aplikasi saya.

Saat mengerjakan aplikasi i18n saya, saya juga menemukan "bug" yang diketahui bahwa stylesheet eksternal dari misalnya @angular/material (berada di node_modules) tidak dapat diselesaikan dan dengan demikian ng-xi18n -tool gagal.
Saya menerapkan "abaikan file yang hilang" -HostContext untuk alat ekstraksi, juga sebagai POC tetapi ditambahkan sebagai PR #17845 agar ditautkan ke repo utama.

@ocombe karena Anda tampaknya sangat aktif dalam topik ini, maukah Anda melihat PR dan memberikan umpan balik?

Terima kasih, saya akan melihatnya.

Sudah beberapa hari mencari cara untuk menerapkan internalisasi di seluruh proyek termasuk data dinamis, tetapi tidak menemukan yang konkret. Bisakah Anda menyarankan saya sesuatu yang lain yang setidaknya membantu saya untuk saat ini. Terima kasih.

Halo @ocombe! Bisakah kita menindaklanjuti poin yang diangkat oleh @jlutz777 (tentang ikatan dinamis, sehingga tidak memiliki satu aplikasi per bahasa)?

Terima kasih banyak atas pekerjaan Anda!

@vicb sedang mengerjakannya sekarang, itu akan berada di 5.x (bukan 5.0 tetapi kemungkinan besar 5.1)

@ocombe Haruskah daftar periksa diperbarui? Saya dapat melihat beberapa dari mereka sudah digabungkan dalam versi yang lebih baru. Dan itu akan lebih mencerminkan kerja keras Anda. 😃.

ya, ide bagus, saya akan memperbaruinya
edit: diperbarui

Runtime i18n (satu bundel untuk semua lokal dengan AOT) - [mengerjakannya]

Dimana isu / PR / diskusi terkait?

Akan keren untuk memiliki api untuk memperluas format tanggal bernama (misalnya ultraLongDate ) sehingga pipa tanggal asli akan mengetahuinya dan pipa tanggal khusus tidak diperlukan.

Hanya ingin tahu tentang kemajuan pada "Runtime i18n (satu bundel untuk semua lokal dengan AOT)."

Tim saya memiliki beberapa aplikasi besar dengan 60+ bahasa. Saat ini kami menjalankan N build secara paralel sehingga N adalah jumlah bahasa. Ini adalah sumber daya yang intensif, seperti yang dapat Anda bayangkan, terutama mengingat aplikasinya cukup besar dan digunakan berkali-kali dalam sehari ke berbagai lingkungan.

Yang saya harapkan adalah:

1. Beberapa ETA kasar saat runtime i18n
2. Konfirmasi bahwa runtime i18n akan melakukan satu build untuk semua bahasa
3. Apakah setiap bahasa yang dihasilkan akan lambat dimuat atau berada dalam satu bundel besar

@chcaru sambil menunggu ng memberikan solusi "asli" lihat https://github.com/actra-development-oss/ng-i18n-aot-loader/
Ini memberikan persis apa yang Anda minta, satu build AOT dengan banyak lokal.

@chcaru :
1/ ETA kasar adalah Angular v6 (beta pertama seharusnya pada akhir Januari saya percaya? tidak yakin), kabar baiknya adalah bahwa terjemahan kode harus segera diikuti setelah terjemahan runtime karena hampir semua pekerjaan akan selesai
2/ ya
3/ terjemahan harus dipisahkan dari bundel, Anda akan dapat memuat lambat yang Anda butuhkan sebelum bootstrap, atau hanya menggabungkan semuanya menjadi satu, kami juga ingin mendukung terjemahan pemuatan malas untuk modul, tetapi tidak yakin kapan akan tersedia

@ocombe hingga angularv6 dirilis, opsi paling serius untuk memuat terjemahan secara dinamis dan/atau membuat aplikasi multi-bahasa dengan satu paket adalah ngx-translate.

Apakah Anda memiliki beberapa tip untuk membantu orang yang mulai menggunakan ngx-translate agar mudah bermigrasi saat angularv6 keluar?
Adakah jembatan antara kedua aplikasi?

Tidak juga, kodenya sangat berbeda... kita akan lihat ketika v6 keluar dengan fitur-fitur itu jika saya termotivasi untuk bekerja pada alat migrasi

Hai, terima kasih atas transparansi fitur yang akan datang.

Akan sangat membantu untuk mengetahui jawaban untuk pertanyaan-pertanyaan berikut:

1. Adakah yang tahu betapa berbedanya alur kerja i18n baru dari yang sekarang dijelaskan di https://angular.io/guide/i18n ?

2. Akankah atribut i18n dan i18n-* mis. i18n-title dengan id kustom opsional masih tersedia di template?

3. Apakah perintah berikut masih berfungsi?

ng serve --aot --locale fr

ng xi18n  --i18nFormat=xlf
ng xi18n  --i18nFormat=xlf2
ng xi18n  --i18nFormat=xmb

1. bagaimana trans-unit messages.xlf yang diekstrak dari template akan digabungkan dengan yang digunakan dalam kode?

1. Kami akan membuat pengalaman pembaruan semulus mungkin, kemungkinan besar apa yang berhasil sebelumnya akan tetap berfungsi setelah setidaknya hingga v7.
2. Atribut i18n akan tetap sama
3. ekstraksinya juga harus sama
4. itu mungkin satu-satunya bagian yang akan berubah, saya belum yakin bagaimana jadi saya memilih untuk tidak memberi tahu Anda hal-hal yang mungkin berubah, tetapi pesan akan digabungkan saat runtime ketika tampilan dibuat (jadi antara bootstrap dan tampilan muncul di layar)

Mengikuti komentar @Toub , untuk masa transisi ini, kami akan tertarik untuk mendapatkan masukan untuk pendekatan berikut (mencampur atribut i18n dan ngx-translate) yang ingin kami terapkan. Tujuan kami adalah meminimalkan lebih banyak pembaruan yang harus dilakukan dalam kode ketika dukungan i18n baru akan siap.

(Perhatikan kami ingin lokal dinamis, yaitu tidak satu aplikasi yang dihasilkan per lokal)

• Kami akan menggunakan atribut i18n sehingga kami dapat memanfaatkan alat ekstraktor sudut.
• Berdasarkan alat yang diekstrak, kita dapat mengonversi file xliff (atau dengan format lain) menjadi konten dengan format yang dapat digunakan oleh ngx-translate (json atau po)
• Kami akan memanfaatkan atribut translate pada elemen menggunakan i18n untuk menerapkan terjemahan (diekstrak sebelumnya)

Berikut adalah contoh:

<!-- Without parameters -->
<div i18n="hello-id" translate>HELLO</div>

<!-- With parameters -->
<div i18n="hello-id" translate [translateParams]="{value: 'world'}">HELLO</div>

Terima kasih atas masukan Anda!

Bisakah Anda membuka masalah di ngx-translate untuk itu? Saya pikir hal terbaik mungkin adalah memperbarui lib untuk mendukung atribut "i18n" sebagai alternatif untuk "menerjemahkan"

@ocombe terima kasih atas sarannya! Baru saja menambahkan masalah untuk ini di ngx-translate...

@ocombe masalah yang saya lihat adalah bahwa atribut i18n / i18n-* dihapus saat runtime (https://github.com/angular/angular/issues/11042). Apakah ada cara untuk menjaga mereka?

Saya memeriksa dan kecuali saya salah mereka hanya dihapus jika Anda menggunakan Angular i18n (artinya Anda memuat terjemahan saat Anda melakukan kompilasi).

@ocombe Saya mengerti tetapi saya tidak memuat terjemahan karena saya menggunakan Angular CLI dan memulai aplikasi dengan ng serve ...

@ocombe , perusahaan kami akan segera sebelum upaya untuk mendukung i18n menggunakan beberapa aplikasi per strategi lokal yang saat ini ditentukan. Kami juga berencana untuk menyertakan lokal di url dan mengatur href dasar di aplikasi. Setelah fitur runtime i18n selesai, perubahan apa yang perlu kita buat dengan strategi lokal url kita? Apakah ada cara yang lebih baik bagi kita untuk mulai menghindari refactor besar setelah runtime i18n dirilis? Terima kasih atas kerja kerasmu untuk semua ini.

️ harus mengatakan "akan segera dimulai"

satu aplikasi/lokal harus tetap berfungsi seperti sekarang (dikurangi perubahan kecil untuk memuat file lokal di bootstrap jika Anda tidak menggunakan cli)

Bisakah seseorang menargetkan saya di file mana atribut i18n dihapus dari templat selama bundel?

cc @ocombe

Itu diubah di 4.2.6 (PR https://github.com/angular/angular/issues/17999)

Hai! ane udah lama ngikutin thread ini. Saya melihat bahwa beta pertama untuk v6 sudah keluar. Saya membaca changelog tetapi tidak melihat apa pun yang terkait dengan masalah lama ini. Ada berita di depan ini? Atau setidaknya, apakah ada jaminan bahwa antarmuka akan mirip dengan polyfill Anda?

Terima kasih atas pekerjaan Anda!

Ini akan berada di salah satu beta terakhir, atau mungkin RC (saya tahu saya tahu ...).
Antarmuka akan mirip dengan goog.getMsg dari penutupan karena itulah yang digunakan google secara internal untuk terjemahan kode: https://developer.pubref.org/static/apidoc/global/closure/goog/getMsg.html
Tapi kami mungkin menggunakan pembungkus, jadi mungkin itu akan mengubah antarmuka untuk Angular, belum yakin.
Dalam polyfill saya, saya menggunakan antarmuka yang serupa, tetapi dengan kemungkinan untuk mendefinisikan id, deskripsi & makna jika perlu, dan saya percaya bahwa kita akan membutuhkannya dengan satu atau lain cara (baik melalui parameter, atau melalui dekorator)

Terima kasih untuk semua kerja keras Anda! Kami sedang mempersiapkan penulisan ulang seluruh aplikasi 1.x kami mulai bulan April. Adakah yang bisa/harus kita lakukan untuk mempersiapkan perubahan ini? Saat ini kami berencana menggunakan 6.x. Terima kasih lagi!

@ocombe Hanya ingin tahu kapan "Abaikan spasi awal dan akhir" akan mendarat?

Saya perlu memperbarui peta jalan tetapi agak bingung sekarang (bahkan untuk saya). Fitur ini khususnya jelas bukan prioritas, jangan harap kami akan mengerjakannya dalam waktu dekat

@ocombe Ya ini akan sangat bagus. Kami juga sangat tertarik dengan runtime i18n, sebagai satu-satunya titik pemblokiran bagi kami. Bisakah Anda menebak tentang penyelesaiannya dalam %?

Terima kasih banyak atas kerja keras Anda!

@ocombe

Fitur ini khususnya jelas bukan prioritas, jangan harap kami akan mengerjakannya dalam waktu dekat

Bisakah Anda menjelaskan fitur apa yang Anda bicarakan di sini? Saya tidak ingin membuat asumsi apapun.

@ofuangka fitur "Abaikan spasi awal dan akhir" bukan prioritas.
@Karamuto sulit ditebak untuk saat ini, kami sedang mengerjakannya sekarang

@ocombe
Bisakah Anda membagikan pencapaian Anda tentang Runtime i18n (satu bundel untuk semua lokal dengan AOT)

Sekarang kami memutuskan untuk menggunakan alat xi18n atau menggunakan perpustakaan pihak ketiga untuk proyek multibahasa yang besar.
Kami berharap dapat menggunakan perkakas kanonik, tetapi, menyadari bahwa itu terlalu mentah.

Kami juga ingin dapat membagi file xlf (satu file per modul), apakah mungkin?

naik naik
akankah runtime i18n dirilis di Angular 6?

terima kasih dan selamat coding!

Kehilangan harapan di sini, bahwa ini akan selesai tepat waktu, karena tidak banyak waktu yang tersisa dan sejauh ini belum ada realisasi mengenai fitur ini.

Rilis versi 7 akan sangat terlambat bagi kami.

@Karamuto #22654
Saya pikir itu akan dirilis di v6, tetapi mereka harus menyelesaikan Ivy terlebih dahulu.

Kita seharusnya memiliki hello world yang berfungsi minggu ini, tetapi dengan fitur minimal (tidak ada dukungan ICU misalnya).
Tapi karena dirilis dengan ivy yang berada di belakang bendera, kami akan terus mengerjakannya dan merilisnya segera setelah kami menyelesaikan fitur baru, tidak perlu menunggu v7

@ocombe
Kedengarannya bagus! Tidak perlu lengkap dengan ICU sejak awal. Jika itu akan maju di realese terakhir dari v6 ini sepenuhnya baik-baik saja oleh kami.

Terima kasih atas kerja bagusnya lagi!

@Karamuto lihat #22654 untuk bocoran!

Pertanyaan bodoh: Apakah ada cara untuk memiliki arahan i18n untuk input berbasis string ke komponen khusus. Contoh saat meneruskan aria-labels:

Saya membungkus tombol khusus yang melakukan hal-hal keren:

Templat tombol khusus hanya berfungsi:

Apakah sudah ada cara untuk melakukan ini?

@kekraft Saya pikir dengan input statis Anda dapat menggunakan sintaks atribut i18n:

<custom-button ariaLabel="your label" i18n-ariaLabel></custom-button>

Dalam komponen:

<button [attr.aria-label]="ariaLabel">Some button</button>

@ocombe apakah Anda memerlukan kontributor untuk menyelesaikan pekerjaan runtime i18n ?

Ya ! v6 diterbitkan ~~~
ada update disini?

contoh i18n angular 6 ada di sini
https://github.com/angular/angular/pull/23660

@sandangel maksud Anda hanya "semuanya" atau "semua yang diperiksa", dari rencana di awal utas ini?
Sangat menantikan untuk memiliki satu aplikasi, saya pikir itu salah satu hal yang paling penting. Pergi ke #23660 yang Anda tautkan dan kemudian mencapai https://pr23660-e12f469.ngbuilds.io/guide/i18n
Tapi disana masih tertulis:

Saat Anda menginternasionalkan dengan kompiler AOT, Anda harus membuat terlebih dahulu paket aplikasi terpisah untuk setiap bahasa dan menyajikan paket yang sesuai berdasarkan deteksi bahasa sisi server atau parameter url.

Apakah mungkin untuk memiliki satu aplikasi untuk beberapa bahasa atau belum?

@MrCroft sepertinya runtime i18n masih dalam proses. Saya membacanya seperti Anda beberapa opsi lagi tetapi tidak satu bundel untuk semua pelokalan :(

Kami memiliki hello world yang berfungsi tetapi ini hanya untuk penyaji baru (ivy) dan karena ivy belum siap untuk prime time, sayangnya Anda harus menunggu :(

@ocombe jadi, kecuali kami tidak memiliki Ivy dalam produksi (mungkin sekitar v7) kami tidak akan memiliki terjemahan runtime. Apakah ini benar?

@ocombe apakah halo dunia dan ivy tersedia untuk umum? Akan sangat keren untuk mencoba dan memahami implementasi i18next yang baru ini😃

@fetis https://github.com/actra-development-oss/ng-i18n-aot-loader/

@fetis ya :(
@feloy ya, hello world yang sederhana ada di sini: https://github.com/angular/angular/tree/master/packages/core/test/bundling/hello_world_i18n tapi sangat minim
anda dapat menemukan tes di sini: https://github.com/angular/angular/blob/master/packages/compiler/test/render3/r3_view_compiler_i18n_spec.ts
dan beberapa refactoring + ekstraksi di sini: https://github.com/angular/angular/pull/22931

@ocombe kami mencoba menerapkan i18n di aplikasi kami, tetapi di mana pun saya membacanya, saya melihat bahwa kami memerlukan satu file messages.xlf per bahasa. Bukankah itu menjadi biaya tambahan untuk mempertahankan mengingat aplikasi yang kompleks dengan berbagai layar yang menghadap pelanggan dll. Saya ingin melihat apakah kita dapat memecah file pesan per komponen atau per modul? Apakah itu sudah didukung?

@stickler-v file ini hanya mengangkut string Anda ke perangkat lunak terjemahan Anda. jangan pertimbangkan untuk menerjemahkannya secara manual.

Saya mengerti, di mana kami memiliki teks aktual dalam bahasa yang berbeda? Kita perlu mengelola teks ini secara manual dibandingkan dengan meminta penerjemah melakukannya.

Maaf, tapi saya sedikit tersesat. Berdasarkan dokumentasi asli di sini https://angular.io/guide/i18n. src/app/app.component.html hanya akan memiliki teks bahasa Inggris. message.fr.xlf adalah file yang memiliki teks Prancis tetapi dibuat secara otomatis dan tidak disarankan untuk menyentuhnya.

Jika saya ingin app.component.html dirender menggunakan teks Prancis alih-alih bahasa Inggris, di mana saya akan menentukan pesan Prancis "Bonjour" dll.?

@stickler-v benar-benar di luar topik, silakan buat pertanyaan di StackOverflow. Saya akan dengan senang hati menjawab di sana.

Bisakah Anda tidak membahas ini di sini, itu bukan topik di sini, terima kasih
Adapun pertanyaan Anda @ stickler-v, satu file per modul / komponen tidak dimungkinkan saat ini, mungkin di masa depan tetapi tidak ada dalam daftar hal-hal yang sedang kami kerjakan saat ini

Adakah rencana untuk mendukung terjemahan rute?

Maaf jika ini sudah dijawab tetapi apakah terjemahan dalam JS dimungkinkan dengan versi ini atau masih hanya templat?

@santhony7 Masih tidak mungkin karena Ivy belum siap.

Satu pertanyaan yang saya miliki tentang maksud/fungsi dari runtime i18n di sini adalah apakah itu berarti kita pada dasarnya dapat memilih bahasa saat runtime dan "membaliknya" tanpa memuat ulang aplikasi seperti fungsionalitas di ng-translate yang lama untuk AngularJS dan dalam ngx-translate ? Atau apakah ini berarti sesuatu yang lain sama sekali?

Tidak, Anda harus memuat ulang aplikasi untuk mengubah bahasa.

Dengan i18n saat ini, saat Anda membuat dan menyediakan terjemahan, kami mengganti string dalam kode bundel, artinya bundel dilokalkan.
Runtime i18n berarti bahwa file terjemahan dimuat saat aplikasi dimulai dan tidak pada waktu pembuatan seperti sekarang.
Karena itu, Anda akan dapat memuat file terjemahan dengan lambat sebelum aplikasi dimulai yang berarti bundel terpisah dari bahasa, Anda hanya mendapatkan satu bundel untuk aplikasi Anda.
Anda juga dapat memilih untuk memiliki satu bundel per bahasa, dan menggabungkan file bahasa dengan aplikasi Anda (seperti yang kami lakukan sekarang), Anda akan menghindari penundaan yang diperlukan untuk memuat file terjemahan dengan lambat.
Dalam satu kasus Anda melakukan permintaan http tambahan, dan dalam kasus lain tidak, tetapi saya tidak berpikir akan ada perbedaan yang cukup besar untuk membenarkan memiliki satu bundel per bahasa.

Keuntungan dari runtime i18n:

• mendeteksi sisi klien bahasa, dan malas memuat file terjemahan yang Anda inginkan
• karena kodenya tidak bergantung pada bahasa, Anda mendapatkan satu bundel untuk semua bahasa
• perpustakaan dapat kompatibel dengan "i18n" juga
• karena kami memuat terjemahan saat runtime, kami memiliki semua yang kami butuhkan untuk menyediakan layanan yang dapat melakukan terjemahan dalam kode Anda juga (bukan hanya template)
• kami dapat membagi terjemahan per modul (mungkin tidak tersedia pada awalnya)

Kekurangan:

• menerjemahkan saat runtime memiliki biaya kecil ketika terjemahan diekstraksi dan diubah menjadi node html, tetapi mudah-mudahan Anda tidak akan menyadarinya karena ivy akan jauh lebih cepat daripada penyaji saat ini
• bootstrap aplikasi tertunda oleh waktu yang diperlukan untuk memuat terjemahan dengan lambat, atau bundel Anda sedikit lebih besar (jika Anda menggabungkan terjemahan)
• kami harus menambahkan pembuat serial ke bundel aplikasi Anda untuk dapat membaca terjemahan, dan itu banyak kode (kami mungkin dapat "mengkompilasi sebelumnya" terjemahan menjadi semacam json untuk menghindarinya, kami belum memutuskan )

Secara teoritis Anda dapat mengubah bahasa tanpa memuat ulang seluruh aplikasi, tetapi Anda harus membuat ulang komponen yang ada karena template dibuat saat komponen dibuat, atau Anda dapat mengikat layanan di template Anda (alih-alih menggunakan i18n atribut) dan itu akan diperbarui ketika Anda mengubah bahasa. Dimungkinkan untuk menulis pustaka yang berfungsi seperti ngx-translate tetapi menggunakan Angular i18n secara internal dan memungkinkan Anda mengubah bahasa saat runtime. Itu akan menggunakan lebih banyak memori untuk menjaga templat tetap sinkron dengan bahasa, seperti halnya dengan ngx-translate. Saya mungkin akan menulis perpustakaan seperti ini.

juga untuk dipikirkan orang-orang adalah bahwa beberapa perubahan dari satu bahasa ke bahasa lain mungkin kecil lainnya mungkin besar, katakanlah dari bahasa Inggris ke bahasa Spanyol mungkin "kecil" tetapi dari bahasa Inggris untuk mengatakan Cina atau Arab akan menjadi besar.
untuk memperjelas beberapa bahasa, ini bukan hanya teks, Anda mungkin juga perlu mendesain tata letak yang berbeda untuk mengakomodasi bahasa itu dan aturannya untuk perataan, kiri ke kanan atau kanan ke kiri, dan detail lainnya.

jadi untuk sebagian besar penggunaan di dunia nyata, saya berharap aplikasi memiliki langkah deteksi bahasa di aplikasi yang akan mengarah pada pemuatan sumber daya yang tepat dan beberapa tata letak.

@ocombe Terima kasih banyak untuk mengklarifikasi! Saya telah mengimplementasikan Angular i18n saat ini dalam aplikasi kami dan mengalami hambatan karena perubahan/persyaratan yang tidak diketahui. Saya juga menggunakan perpustakaan https://github.com/ngx-translate/i18n-polyfill untuk membantu menjembatani kesenjangan saat ini.

Meskipun beberapa bundel sedikit mengganggu, Anda dapat mengatasinya dengan cukup mudah saat ini. Hambatan khususnya adalah potensi untuk memiliki satu komponen (dan semua komponen turunannya) untuk ditampilkan dalam bahasa yang berbeda dari bahasa yang digunakan saat ini.

Terus terang saya belum yakin apakah ngx-translate dapat membantu mencapai ini untuk saya, tetapi saya ingin memberi tahu Anda tentang perubahan yang akan datang hanya untuk memastikan saya memiliki informasi sebanyak mungkin sebelum membuat pivot.

Kami tidak memiliki rencana untuk mendukung aplikasi yang diterjemahkan dalam beberapa bahasa secara bersamaan, mungkin di masa depan jika kami dapat memuat terjemahan / modul, tetapi itu akan menjadi efek samping dari arsitektur, bukan sesuatu yang kami khususkan. mencoba untuk mencapai.

Apakah ada ETA untuk Ivy + runtime i18n ?
Saya sangat mengerti jika bukan itu masalahnya, tetapi saya perlu tahu apakah (mengingat jangka waktu proyek saya saat ini) saya dapat menunggu atau perlu mulai menggunakan salah satu solusi saat ini dan menunda migrasi ke runtime i18n untuk versi yang akan datang .

Saya tidak akan mencoba memberikan kerangka waktu yang tepat, setiap kali saya mencoba itu salah :D
Itu tidak akan sebelum v7 sekarang (akan tersedia sebelumnya sebagai beta)

Tidak masalah, kita semua tahu bagaimana perkiraan selalu salah. :D
Apakah menurut Anda akan lebih mudah untuk bermigrasi dari i18n saat ini (+ i18n-polyfill) ke runtime 18n atau dari ngx-translate ?

mungkin dari i18n saat ini, tetapi saya akan menulis versi ngx-translate yang menggunakan internal Angular i18n, jika memungkinkan (belum yakin)

Hai, saya sudah mencoba melintasi utas ini untuk memahami keadaan saat ini. Apakah kode terjemahan ngx saat ini merupakan "solusi" yang paling layak untuk satu aplikasi dengan lokalisasi dinamis?

Hai, Apakah mungkin untuk mengubah pelokalan saat dijalankan menggunakan ngx-translate/i18n-polyfill?

@suchg Tidak saat runtime. Anda dapat melakukan terjemahan saat runtime tetapi Anda tidak dapat mengubah lokal yang digunakan.

@mjschranz terima kasih atas balasan cepatnya
bahkan terjemahan run time baik-baik saja untuk saat ini. dapatkah Anda membagikan contoh apa pun untuk hal yang sama.
Saya mencoba contoh yang dibagikan di https://github.com/ngx-translate/i18n-polyfill , dan memang mengubah bahasa browser chrome tetapi tidak berhasil.
apakah ada metode khusus untuk terjemahan ??

Tolong, simpan diskusi di sini tentang Angular, bukan perpustakaan eksternal. Jika Anda memerlukan bantuan dengan itu, posting pesan di repositori github mereka

Hai, apakah ada masalah pelacakan lain atau dokumen desain tentang seperti apa tampilan fitur di masa mendatang? Mungkin kami dapat membantu implementasi atau mempersiapkan diri untuk memastikan transisi di v7 akan semulus mungkin.

Hai, saya saat ini menjalankan Angular 5 dan kami perlu menambahkan multi bahasa ke proyek kami.
Saya telah menambahkan solusi yang bekerja untuk saya sekarang, yang hampir elegan. https://github.com/angular/angular/issues/24549.

Idealnya, saya ingin malas memuat file bahasa berdasarkan layanan sniffer negara (berdasarkan pencarian peta nama host).
Jika itu mungkin di Angular 6, itu akan bagus.

@mattiLeBlanc Bagaimana Anda menyelesaikan pesan dinamis, misalnya pesan dari komponen atau layanan?

@zverbeta Mohon maafkan saya karena tidak sepenuhnya memahami Inti Sudut atau konteks untuk diskusi ini. Saya hanya bisa mendekatinya dari konteks saya sebagai permulaan.

Sebagai jawaban atas pertanyaan Anda, saya akan berasumsi bahwa kami hanya tertarik untuk malas memuat file terjemahan (xlf) dengan cara yang bagus, berdasarkan lokal yang dapat disimpulkan dari URL atau queryparam bahasa. (Saat ini saya menggunakan peta URL untuk memutuskan apa itu lokal).

Pesan dari komponen atau layanan tidak ditandai seperti kita menandai markup dengan i18n. Saya memiliki beberapa pengalaman dengan i18n untuk Wordpress dan PHP. Di sana kami menggunakan pendekatan __( 'text' to translate, 'text domain' ) untuk mendapatkan terjemahan yang benar. __() ini juga dapat dipindai dengan perintah CLI yang membuat file pesan.

Apakah ini salah satu masalah yang Anda maksud?

Satu hal yang saya perhatikan dengan blok markup ini misalnya (karena saya malas dan tidak ingin menambahkan i18n pada setiap subelemen):

<div class="eligibility-banner" i18n="@@eligbilityBanner" fxLayout="column" fxLayout.gt-xs="row" fxLayoutAlign.gt-xs="center center" fxLayoutAlign="center start">
        <div class="requirement-text" fxFlex="20">To be eligible, you:</div>

        <div fxLayout="column" fxFlex="80" fxLayout.gt-xs="row" fxLayoutAlign="center start">
          <div fxLayout="row" fxLayoutAlign="center center" class="requirement" fxFlex="33">
              <pro-svg icon="icon-check-circle" className="icon-check" width="44" height="44"></pro-svg>
              <div class="text">own an Australian business (with a valid ABN/ACN)</div>
          </div>
          <div fxLayout="row" fxLayoutAlign="center center" class="requirement" fxFlex="33">
              <pro-svg icon="icon-check-circle" className="icon-check" width="44" height="44"></pro-svg>
              <div class="text">are over 18 years old</div>
          </div>
          <div fxLayout="row" fxLayoutAlign="center center" class="requirement" fxFlex="33">
              <pro-svg icon="icon-check-circle" className="icon-check" width="44" height="44"></pro-svg>
              <div class="text">are an Australian Citizen or Permanent Resident</div>
          </div>
        </div>
      </div>

yaitu menyalin seluruh blok div ke message.xlf saya.
Itu banyak polusi markup. (Tentu saja saya bisa menggunakan i18n pada setiap tag yang menyimpan teks.)

Untuk contoh ini, saya pikir menggunakan perintah _e() akan bekerja dengan cukup baik. Anda akan membungkus teks Anda dengan perintah echo dan semua teks yang dibungkus itu akan dikumpulkan. Anda bisa menyingkirkan semua salinan markup di xml.
Jika Anda perlu menambahkan sesuatu yang dinamis ke string itu, Anda bisa menyalurkannya dengan placeholder di string (seperti yang akan Anda lakukan dengan sprintf . Sesuatu seperti

<p>{{ __( 'I would like a nice %s, please', fruit ) }}</p> 

di mana fruit adalah variabel dengan nilai __( 'apple') atau __( 'pear) .
3 buah teks akan berakhir dalam XML dan dapat diterjemahkan secara terpisah.

Apakah itu ada gunanya? Ini sangat mirip dengan menambahkan atribut i18n, saya menyadari setelah membaca lagi :)

Akhirnya, melihat beberapa format. XLIFF 2 terlihat cukup bagus, sedikit lebih bersih dari 1.2. XMB terlihat membingungkan, dokumentasi mengerikan yang terlihat seperti ditata pada tahun 1995.
Saya memang memperhatikan ketika menggunakan XLIFF 2 bahwa teks TARGET tidak dirender seperti pada versi 1.2.

Pernahkah kalian melihat file .pot dan .mo? Format yang cukup sederhana dan juga digunakan dengan diterjemahkan dengan alat POEdit.

saya perlu mengonversi aplikasi saya dalam bahasa Inggris dan Spanyol menggunakan tombol sakelar. Melakukan semua perubahan, file yang berfungsi secara terpisah. saya telah membuat dua build di bawah .dist/en dan dist/es. Adakah yang bisa memberi tahu saya, apa yang harus saya lakukan untuk penerapan dan bagaimana cara beralih di antara kedua build?

Apa yang harus saya lakukan dengan mengklik tombol sakelar

@shobhit12345 silakan kirim permintaan bantuan Anda di https://stackoverflow.com

@zverbeta solusi yang saya posting di #24549 tidak berfungsi ketika saya membangun dengan --prod . Agak jelas karena saya menggunakan require yang mungkin tidak tersedia?
Tanpa flag --prod solusinya tidak berfungsi karena menyertakan kode terkait webpack?

@mattiLeBlanc saya menemukan lib ini https://github.com/ngx-translate/i18n-polyfill dan itu menyelesaikan masalah saya dengan teks dinamis

Hai , bagaimana kami dapat menerjemahkan nilai dinamis (interpolasi) menggunakan i 18 n .

    <source>This amount is for <x id="INTERPOLATION" equiv-text="{{policyName}}"/> policy #<x id="INTERPOLATION_1" equiv-text="{{policyGroupId}}"/></source>
    <target>Esta cantidad es para <x id="INTERPOLATION" equiv-text="{{**policyName**}}"/> política #<x id="INTERPOLATION_1" equiv-text="{{policyGroupId}}"/></target>

Hai! Adakah tempat di mana kami dapat melacak dan/atau membantu tugas-tugas yang sedang dikerjakan? (yang dengan tag mengerjakannya )

Adakah pembaruan pada kerangka waktu untuk merilis versi beta runtime i18n?

@marcelnem saya tidak dapat menemukan komentar tetapi iirc ocombe menyebutkan bahwa runtime i18n digabungkan untuk ivy sehingga Anda mungkin dapat mengujinya di v7 beta dengan bendera ivy

Bagian runtime selesai tetapi bukan bagian kompiler, yang berarti Anda belum dapat mengujinya dengan ivy

Hai, saya bekerja dengan Angular 6 i18n. Saya bekerja dengan multi-bahasa, artinya saya mengikuti buku masak:
https://v2.angular.io/docs/ts/latest/cookbook/i18n.html#!

Implementasi saya saat ini menggunakan AOT, jadi saya membuat file messages.xlf dan pesan.pt.xlf. Semuanya bekerja dengan baik, ketika saya menjalankan

ng melayani --configuration=pt

Saya mendapatkan teks yang diterjemahkan seperti yang diharapkan. Tapi saya merasa ada yang salah dengan cara kerjanya. Saya mungkin kehilangan sesuatu. Sejauh yang saya pahami, setiap kali saya menambahkan string baru untuk diterjemahkan dan menandainya dengan atribut i18n, saya perlu membuat ulang file messages.xlf yang menjalankan "ng xi18n" dan kemudian memperbarui secara manual pesan.pt.xlf. File xlf juga menyimpan nomor baris di mana sumbernya, jadi sepertinya jika saya mengubah baris, saya juga perlu membuat ulang file dan memperbarui file pt saya secara manual.

<context context-type="linenumber">16</context>

Itu tidak terlihat cerdas, itu akan memberi saya banyak pekerjaan ekstra untuk membuatnya tetap bekerja. Apakah Anda mengerti kekhawatiran saya? Apakah saya melewatkan sesuatu?
Saya tahu Angular 7 i18n akan memiliki pembaruan besar dengan Ivy dimasukkan, haruskah saya menunggu?

Salam Hormat,
fabio

ps Saya sangat berharap ini tidak keluar dari topik, tetapi jika Anda merasa demikian, tolong beri saya setidaknya petunjuk. Di mana saya harus menanyakan ini misalnya? Atau jika ada link yang mungkin bisa menjawab keraguan saya.

@fabiopcarvalho Satu hal yang saya sadari adalah bijaksana untuk menggunakan ID khusus untuk setiap terjemahan agar lebih mudah melacak perubahan dalam tata letak HTML.

Tapi ya, Anda perlu memperbarui file terjemahan secara rutin.

@fabiopcarvalho Saya menggunakan xliffmerge untuk membantu saya menggabungkan terjemahan

Sempurna, saya menggunakan alat itu dan itu bekerja dengan baik. Saya juga menggunakan id dan
mereka membantu.
Terima kasih balasannya !!

Pada hari Kamis, 30 Agustus 2018, Pedro Romero [email protected] menulis:

@fabiopcarvalho https://github.com/fabiopcarvalho Saya menggunakan xliffmerge
https://github.com/martinroob/ngx-i18ndukungan untuk membantu saya dengan penggabungan
dari terjemahan

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/angular/angular/issues/16477#issuecomment-417407822 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AWOWQ6vpjOb0Ntgpv7TUngRrBBsUIkVjks5uWCV7gaJpZM4NOSBk
.

Mengizinkan pesan ICU dalam atribut sangat penting untuk aksesibilitas karena atribut aria-label banyak digunakan dalam aksesibilitas. Apakah ada masalah untuk ditindaklanjuti?

Saya tidak berpikir ada masalah untuk itu, bisakah Anda membukanya? Saya sedang mengerjakan ekspresi ICU untuk ivy sekarang, jadi saya menambahkan TODO, tetapi permintaan fitur akan lebih baik

@ocombe , https://github.com/angular/angular/issues/21615

Terima kasih sempurna (pencarian Github benar-benar buruk!)!

Apakah kami dapat dengan malas memuat file terjemahan dari sumber eksternal misalnya melalui HTTP dengan versi baru i18n?

@ocombe seperti yang Anda katakan Anda sedang mengerjakan Runtime i18n (satu bundel untuk semua lokal dengan AOT). sudah lebih dari setahun kami menunggu. kapan kita bisa mengharapkan fitur itu datang dalam rilis angular 7?

@Sef1995 itu salah satu hal yang ingin kami aktifkan
@AhmadShahid itu akan membutuhkan ivy yang akan dirilis secara independen dari v7 dan ivy tidak akan siap untuk rilis v7. Beberapa bagian dari ivy sudah berada di v6 di belakang bendera, tetapi fiturnya tidak lengkap dan Anda tidak boleh menggunakannya dalam aplikasi dunia nyata. Kami belum memiliki tanggal rilis untuk ivy.

@ocombe pertanyaan singkat, jika kita mengimplementasikan i18n mulai hari ini (angular6), yang akan membutuhkan build berbeda (satu untuk setiap bahasa), apakah upaya hilang ketika ivy keluar dan i18n runtime? Maksud saya cara i18n akan diterapkan sekarang akan berbeda dari apa yang akan datang? Mencoba merencanakan beberapa sprint sebelumnya dan memprioritaskan pekerjaan. Terima kasih

Kami tidak ingin membuat perubahan yang melanggar jika kami dapat menghindarinya. Id terjemahan yang diekstraksi mungkin berubah saat kami memperbaiki bug yang sudah lama kami miliki, tetapi kami akan menawarkan alat migrasi. Saya tidak dapat mengatakan dengan pasti bahwa itu akan 100% kompatibel, tetapi berharap sebagian besar hal berfungsi sama, dengan opsi baru tersedia untuk digunakan jika Anda mau.

@ocombe pertanyaan singkat, jika kita mengimplementasikan i18n mulai hari ini (angular6), yang akan membutuhkan build berbeda (satu untuk setiap bahasa), apakah upaya hilang ketika ivy keluar dan i18n runtime? Maksud saya cara i18n akan diterapkan sekarang akan berbeda dari apa yang akan datang? Mencoba merencanakan beberapa sprint sebelumnya dan memprioritaskan pekerjaan. Terima kasih

Hai, Anda dapat menggunakan kebutuhan webpack untuk memuat file secara dinamis (sebagai solusi sementara) dengan satu build:
Contoh dapat ditemukan di sini: https://github.com/angular/angular/issues/24549#issuecomment -402013622

Anda harus membangun dengan --prod --aot=false, karena AOT=true akan menghapus hal-hal webpack.

@ocombe Hai,

Kandidat rilis A7 keluar, Seperti yang dijanjikan, apakah kami akan menguji terjemahan runtime?. Runtime i18n (one bundle for all locales with AOT) . Bagaimana saya bisa menguji ini. Tolong bantu

Terima kasih

Saya kedua pertanyaan dari @sheikalthaf meskipun v7 telah dirilis.

@sheikalthaf @Shuyinsama Seperti yang dijelaskan beberapa komentar di atas dan di pesan pertama:
Runtime i18n membutuhkan ivy yang akan dirilis secara independen dari v7. Beberapa bagian dari ivy sudah berada di v7 di belakang bendera, tetapi fiturnya tidak lengkap dan Anda tidak boleh menggunakannya dalam aplikasi dunia nyata. Kami belum memiliki tanggal rilis untuk ivy.

@ocombe : Bagaimana dengan meneruskan kunci i18n dinamis dari komponen induk ke anak.

Komponen anak:
<div i18n="{{labelTextKey}}">{{labelText}}</div>

Komponen induk:
<app-input [labelText]="'Second name'" [labelTextKey]="'@<strong i="13">@LabelSecondName</strong>'" ..></app-input>

Saya dapat meneruskannya, tetapi karena terjemahan i18n terjadi pada waktu pembuatan, variabel pada status itu masih kosong. Jadi, oleh karena itu tidak ada terjemahan yang terjadi.

Adakah pembaruan untuk kasus seperti itu?

@bobKasbi

anda tidak memerlukan tag i18n di komponen anak, Anda bisa menggunakannya di induk seperti ini:

<app-input i18n-labelText="@@LabelSecondName" labelText="Second name"></app-input>

@cjsase : bekerja dengan baik. Terimakasih banyak! Berjuang dengan hampir 2 Hari.

Berdasarkan ini: https://github.com/angular/angular/issues/21706#issuecomment -430435254

• Kita seharusnya tidak mengharapkan ivy di v7. v8 direncanakan untuk Maret/April 2019 . Jika kita tidak mengharapkan ivy di v7, apakah ada rekomendasi/konsensus tentang apa yang akan digunakan untuk internasionalisasi (i18n) hingga ivy dirilis pada April 2019?

Ini adalah informasi yang tidak benar. Tim inti tidak pernah mengatakan IVy akan dirilis pada 2019. Sebaliknya tim inti mengatakan (penekanan milik saya):

itu harus dirilis dalam versi kecil apa pun, kapan pun itu telah diuji dan divalidasi

Katakanlah saya memiliki aplikasi sudut 7.1.0-beta.0 dengan ivy diaktifkan, apakah mungkin bagi saya untuk memiliki pengaturan dengan perubahan bahasa dinamis yang dikeluarkan dari depan tanpa penyegaran halaman?

jika ya bagaimana? dokumen ini: https://github.com/angular/angular/blob/master/aio/content/guide/i18n.md
dan dokumen ini: https://angular.io/guide/i18n

tidak menampilkan ini?

di mana saya bisa belajar cara membuat aplikasi i18n-angular modern/masa depan?

@tatsujb tidak itu tidak mungkin, dan itu tidak akan mungkin bahkan dengan ivy & runtime i18n. Anda harus memuat ulang aplikasi Angular Anda jika Anda ingin mengubah bahasa, untuk saat ini

ok tapi dokumen agak berlaku untuk versi chimeric dari sudut seperti 4 minus.

Saya tidak merasa mereka berlaku untuk pengaturan saya juga tidak mencakup bagaimana tepatnya Anda membuat perubahan diterapkan.

Saya menerimanya, perubahan harus ditegakkan oleh backend.

Dalam kasus saya, sudut saya disajikan dalam mode produksi oleh backend Java-spring. apa garis besar dari apa yang akan terjadi ketika saya menekan ikon bendera untuk mengubah bahasa?

Anda membawa pengguna ke www.yourdomain.com/cn/ di mana seluruh aplikasi Angular Anda dikompilasi dalam bahasa Cina. Anda berakhir dengan seluruh aplikasi Angular yang dikompilasi untuk setiap bahasa yang ingin Anda dukung.

@ocombe @santhony7 bagaimana dengan ini: https://github.com/actra-development-oss/ng-i18n-aot-loader ?

bisakah saya mencoba ini?

apakah ini sangat kompatibel dengan 7.1.0-beta.0 atau kompatibel dengan baik?

@ocombe @santhony7 bagaimana dengan ini: https://github.com/actra-development-oss/ng-i18n-aot-loader ?

bisakah saya mencoba ini?

apakah ini sangat kompatibel dengan 7.1.0-beta.0 atau kompatibel dengan baik?

Saya sarankan menggunakan ngx-translate sebagai gantinya. Saya telah menggunakan keduanya dan ngx-translate jauh lebih mudah dirawat.

@digismack perbedaan lain antara keduanya, yang agak menakutkan adalah bahwa ngx-translate menjatuhkan semua barang resmi angular-i18n dan tidak menggunakannya sama sekali. itu seluruh sirkuit independennya sendiri dan file json kurang spesifik tentang sumber terjemahan.

juga dari dua demo ngx-translate tampaknya jauh lebih lambat , apa maksud Anda ketika Anda mengatakan lebih mudah untuk mempertahankannya?

@tatsujb sebagai pengembang th ng-i18n-aot-loader Saya tahu ini agak sulit untuk diterapkan, setidaknya mengintegrasikan pemuat.
Segala sesuatu yang lain adalah sepotong kue karena mengikuti paradigma i18n sudut asli.

Ini harus bekerja dengan v7 selama tidak ada perubahan yang melanggar dalam struktur tag atau sejenisnya.

mencoba menerapkan ngx-translate Saya harus pergi ke tempat yang dapat diterjemahkan dengan tempat yang dapat diterjemahkan. ada ratusan agak konyol bagi saya bahwa saya tidak dapat menggunakan tag i18n saya yang telah saya rencanakan sebelumnya.

Aku mulai berpikir mempercayaimu adalah pilihan yang salah, @digismack

@tatsujb Ada 58 orang yang mengikuti masalah ini. Secara pribadi, saya mengikutinya untuk pembaruan dari tim Angular mengenai i18n. Saya akan menghargai jika Anda menghentikan obrolan kecuali jika itu terkait dengan apa yang dinyatakan OP:

Jika Anda ingin fitur i18n baru ditambahkan ke Angular, jangan ragu untuk bertanya di bawah dan saya akan memberi tahu Anda jika itu layak dan jika Anda harus membuka masalah untuk itu.
Jika Anda memiliki bug, buka masalah (tidak perlu membahasnya di sini).

Jika Anda memiliki masalah dengan perpustakaan lain, saya sarankan mengajukan pertanyaan di StackOverflow.

Bukan kebiasaan saya untuk menulis/berkomentar... tapi saya akan melakukannya!
Mempertimbangkan :
@gtbuchanan dan CO adalah tipe orang A.
@tatsujb dan orang lain yang mengeluh/berkomentar/mengharapkan sesuatu adalah orang tipe B

Tipe A Anda tidak lelah mengulangi hal yang selalu sama?!?! Bagi saya Anda lebih menyebalkan daripada tipe B.

karena fitur i18n hilang di sudut Tipe B, orang lebih frustrasi daripada Anda yang hanya "berlangganan" untuk suatu masalah (jika itu untuk membuat Anda berteman, dapatkan beberapa suka, buka facebook saya tidak tahu, ini bukan tempat untuk itu , Anda tidak akan mengubah kata atau menciptakan sesuatu yang mengatakan itu!...)

Saya pikir tipe A dapat berhenti berlangganan, menunggu pembaruan, memeriksa changelog dengan cepat atau membaca blog/berita, pastikan tim sudut akan memasukkannya ke dalam font besar ARIAL 72piksel yang mereka perkenalkan i18n terjemahan dinamis dari ts+runtime i18n: fitur besar hilang di sudut! mereka tidak terlalu mempertimbangkannya sehingga kami tidak memiliki i18n yang benar hari ini, ini adalah strategi google atau lebih dan ini tidak dapat diubah!

Orang B menunggu fitur ini 2 tahun yang lalu, https://github.com/angular/angular/issues/9104#issue -159302131 ya sejak angular 2.X !

Saya hanya ingin mengatakan tolong hormati tipe B yang frustrasi dan jangan jahat. Jika tidak ada yang banyak mengeluh tentang i18n, saya pikir peningkatan i18n tidak akan dipertimbangkan untuk tahun-tahun mendatang, ini juga merupakan open source! mengeluh kritik! strategi bisa berubah! jadi biarkan orang mengeluh, berhenti berlangganan, Anda lebih baik dari yang lain, Anda dapat menemukan informasi Anda tanpa berlangganan masalah ini!

Ketik B silahkan lanjutkan komplain/komentar sampai bisa! itu adalah satu-satunya cara terbaik untuk memahami kebutuhan orang!

Mogok Mogok lol

@tatsujb Semuanya bermuara pada preferensi pribadi. Ketika saya terakhir mengimplementasikan ng-i18n-aot-loader saya harus menjalankan ejected build dan menyesuaikan konfigurasi webpack untuk membuatnya berfungsi. Mungkin itu sudah tidak berlaku lagi. Namun, menjalankan ejected build berarti alat Angular CLI tidak lagi dapat digunakan. Jadi, saya merasa lebih mudah dalam jangka panjang untuk mengimplementasikan ngx-translate dan menghadapi kenyataan bahwa ia bekerja sedikit berbeda.

@gtbuchanan Saya merasakan sakit Anda, tetapi "obrolan" ini terkait langsung dengan ruang lingkup fitur yang disebutkan dalam posting OP. Sejak jangka waktu untuk Runtime i18n (one bundle for all locales with AOT) terus tergelincir, orang masih datang ke utas ini untuk mencari solusi saat ini.

@ocombe , kami akan memulai proyek baru sekarang, di mana kami akan mendapatkan terjemahan dari database.
Modul Angular kami akan dimuat dengan malas dan kami juga ingin tetap sedekat mungkin dengan apa yang ditawarkan Angular tentang I18N.

Karena dukungan Angular I18N tidak membuatnya menjadi rilis terbaru seperti yang direncanakan - apakah Anda memiliki rekomendasi untuk kami dan orang lain yang akan membuat proyek baru sekarang?

Misalnya, sampai I18N siap, kita dapat menggunakan ngx-translate, tetapi kemudian saya membaca di suatu tempat di masalah github proyek itu, bahwa itu tidak akan mendukung pemuatan malas, yang akan menjadi penghenti acara bagi kita.

Kemudian di sisi lain, dukungan I18N Angular belum siap untuk prime time.

Saya benar-benar akan menghargai beberapa petunjuk yang mengarahkan kita ke arah yang benar tentang apa yang harus digunakan untuk proyek mendatang - ngx-translate vs ?

Harus punya:

• pemuatan lambat

Senang memiliki:

• ekspresi ICU

Merci

Untuk pengikut masalah ini, @ocombe akan berbicara tentang runtime i18n di angularconnect dalam beberapa jam. Saya berasumsi setidaknya beberapa pertanyaan terbuka akan dijawab di sana. ada streaming langsung yang tersedia

@ctaepper - terima kasih banyak atas infonya!

@guygit ini mungkin ngx-translate atau angular-l10n . inilah tabel perbandingan yang saya buat https://medium.com/@sergeyfetiskin/tools -to-translate-your-angular-app-c021e25ff26a

untuk aplikasi kami, kami memutuskan untuk menggunakan cara Angular meskipun memiliki beberapa batasan.

@fetis Terima kasih banyak - saya akan memeriksanya :-)

Ingin tahu tentang pilihan file XLIFF untuk file terjemahan - Google Translate Toolkit serta Flutter/Dart i18n keduanya mendukung file ARB dan tidak mendukung XLIFF. Saya pernah mendengar bahwa dukungan file ARB tidak direncanakan, tetapi bertanya-tanya apakah ini sesuatu yang dapat dipertimbangkan lagi. Atau jika seseorang ( @ocombe ?) dapat menunjukkan di mana Angular berinteraksi dengan file XLIFF sehingga saya dapat melihat betapa sulitnya mengintegrasikan dukungan ARB.

(Untuk beberapa konteks, kami akan menggunakan Flutter/Dart untuk aplikasi seluler kami dan Angular untuk aplikasi web kami, dan sangat ingin membagikan file terjemahan kami antara seluler dan web jika memungkinkan. Saya sedang mempertimbangkan untuk menulis sebuah ARB -> konverter XLIFF jika tidak ada keinginan untuk mempertimbangkan penyertaannya dalam Angular.)

@localpcguy jika Anda akhirnya menulis semacam konverter, Anda mungkin tertarik untuk menyumbangkannya ke https://github.com/translate/translate yang sudah menawarkan konversi dari/ke banyak format.

Sebagai tambahan, ocombe mengatakan beberapa bulan yang lalu bahwa dia akan berusaha keras untuk mendukung file PO (dan JSON?). Mudah-mudahan itu akan terjadi di beberapa titik, karena kami mengalami kesulitan untuk menemukan alat ockay-ish untuk bekerja dengan XLIFF.

karena kami kesulitan menemukan alat ockay-ish untuk bekerja dengan XLIFF.

@PowerKiKi itu tidak benar. Hampir semua alat manajemen terjemahan online mendukung format XLIFF. Dan bahkan ada program terjemahan desktop gratis jika Anda tidak ingin mengedit .xliff secara manual

@fetis Saya benci untuk keluar dari topik tetapi telah menemukan cukup banyak rasa sakit dalam hal menggunakan XLIFF dengan alat. Lihat komentar saya di sini: https://github.com/angular/angular/issues/20193#issuecomment -345755889

Harap berikan referensi untuk alat tersebut, karena kami masih belum menemukan sesuatu yang baik dan masih belum menemukan sesuatu yang mendukung XLIFF 2. Smart Cat terlihat cantik tetapi memperbarui string di dalamnya membuat saya ingin mengukur mata saya.

Sepertinya Anda tahu sesuatu yang tidak kami ketahui :)

Pootle menggunakan https://github.com/translate/translate dan sangat hebat dengan Gettext (file po) tetapi tidak mendukung placeholder/tag dan mereka sedang menunggu kontribusi dari seseorang untuk menambahkannya

Saya telah berlangganan masalah ini selama satu tahun atau lebih. Tampaknya kemajuan dalam hal ini bukanlah prioritas untuk tim Angular, dan harus mengkompilasi aplikasi sekali untuk setiap bahasa dan melewati rintangan untuk melakukan terjemahan dinamis tidak dapat diterima. Saya merekomendasikan, jika Anda dapat melakukannya, untuk membuat pipa khusus yang menggunakan perpustakaan i18n mana pun yang Anda suka. Menjadi murni, pipa ini akan sama-sama efisien untuk mengkompilasi aplikasi beberapa kali. Juga, dengan menggunakan i18n yang tidak bergantung pada Angular, Anda akan dapat melakukan terjemahan dinamis dari kode dengan mudah. Keuntungan lainnya adalah terjemahan Anda tidak akan lagi bergantung pada Angular, sehingga Anda dapat mulai memigrasikan beberapa komponen ke kerangka kerja lain jika diinginkan, atau Anda bahkan dapat memilih format dan alat terjemahan yang Anda inginkan dengan kebebasan penuh. Saya menggunakan https://airbnb.io/polyglot.js/ dan sangat senang dengan itu, dan bahkan ketika migrasi aplikasi saya dari Angular i18n ke polyglot masih berlangsung, saya sangat senang dengan hasil dan penghapusannya ketergantungan dengan Angular i18n.

Maaf untuk yang akan menerima ini sebagai pemberitahuan di surat Anda dan tidak peduli dengan pendapat saya, tetapi karena sudah lama membaca pemberitahuan Anda, saya merasa harus mengucapkan selamat tinggal sebelum berhenti berlangganan :)

Bersulang!

Tampaknya kemajuan dalam hal ini bukanlah prioritas untuk tim Angular, dan harus mengkompilasi aplikasi sekali untuk setiap bahasa dan melewati rintangan untuk melakukan terjemahan dinamis tidak dapat diterima.

Runtime i18n adalah prioritas besar untuk Tim Angular. Namun, masalah pemblokiran itu adalah penyaji Ivy baru. Kemajuan proyek sejauh ini baik dan kita mungkin dapat mengharapkan Ivy untuk Angular 8. Saya mengerti bahwa ini adalah situasi yang sulit bagi semua orang yang terlibat. Ada rencana tapi tidak bisa dilaksanakan selama Ivy belum selesai.

Silakan lihat pembicaraan dari konferensi AngularConnect baru-baru ini (2018) di London, terutama "Runtime i18n" oleh Olivier Combe dan keynote Hari 2 oleh Alex Rickabaugh.

Memang pengalaman saya mirip dengan @intellix.

XLIFF 1.2 berumur 10 tahun , namun dukungan untuk itu dalam proyek sumber terbuka tampaknya sangat buruk. Pootle tidak mendukung pemegang palce menurut https://github.com/translate/pootle/issues/4762 dan https://github.com/translate/pootle/issues/1811. Weblate juga tidak mendukung mereka , meskipun PR mungkin akan segera menambahkan dukungan .

Di desktop, Virtaal _does_ mendukung placeholder XLIFF, tetapi rilis terbaru 0.7.1 berusia 6 tahun dan tidak berfungsi lagi pada macOS terbaru dari apa yang saya dengar. Sayangnya, ini tidak memberikan kesan proyek yang terpelihara dengan baik, dengan beberapa PR yang sangat tua yang masih menunggu untuk digabungkan meskipun terlihat sederhana. Dan aktivitas komitmen yang sangat rendah dalam beberapa tahun terakhir .

Saya baru tahu bahwa Poedit 2.2 yang dirilis beberapa hari lalu mendukung XLIFF 1.2 dan 2.0. Sayangnya saya tidak dapat mengujinya karena saya mendapatkan kesalahan dari snapcraft.io CDN saat menginstal saat ini. Tapi ini mungkin solusi terbaik untuk pengguna desktop.

@fetis jika Anda menemukan beberapa proyek open source (atau setidaknya gratis untuk digunakan) untuk mengedit XLIFF 1.2, atau lebih baik lagi XLIFF 2.0, dengan dukungan untuk placeholder, harap cantumkan di sini. Semua hal lain yang saya uji tidak berfungsi sama sekali, atau sangat rumit untuk digunakan.

@intellix @PowerKiKi inilah daftar yang saya ketahui. Target kami adalah platform terjemahan online, di mana kami dapat berkolaborasi dengan penerjemah/rekan dari berbagai negara. Melalui proses menginstal perangkat lunak desktop untuk setiap kolaborator dan mengelola sinkronisasi file XLIFF bukanlah pilihan bagi kami. Jadi, saya tidak menguji alat desktop, platform yang saya lakukan.

Aplikasi
OmegaT
https://omegat.org/

Dihosting sendiri
https://weblate.org/en/ +hosting berbayar
https://pootle.translatehouse.org/
https://pontoon.mozilla.org/

Platform
kerumunan
https://crowdin.com/
dukungan CLI

WebTerjemahkanItu
https://webtranslateit.com/
dukungan CLI

Transifex
https://www.transifex.com/

Aplikasi Frase
https://phraseapp.com/

bahasa lokal
https://lokalise.co/
dukungan CLI

_Saya pikir kami akan menyelesaikan dengan Lokalise untuk proyek kami karena menyediakan fungsionalitas yang cukup dengan harga terjangkau._

~POEditor~
https://poeditor.com/pricing/
Dukungan XLIFF yang dideklarasikan tidak berfungsi dengan format Angular

Jika Anda mencari solusi open-source, daftar ini mungkin berguna bagi saya https://opensource.com/article/17/6/open-source-localization-tools

Node samping
Saya tidak melihat platform online yang mendukung XLIFF 2.0 dan itu adalah kejutan besar bagi saya. XLIFF 1.2 secara resmi ditandai sebagai usang dan tidak ada seorang pun di industri yang mendukung v2.

Senang mendengar bahwa POEdit menyatakan dukungan XLIFF, saya menggunakannya untuk file .po dan itu bagus.

PS Saya sangat menyesal membuat offtopic di sini, tetapi pada saat yang sama mendapatkan file XLIFF dari aplikasi Anda hanya bagian dari perjalanan, Anda perlu menerjemahkan dan memeliharanya melalui siklus hidup aplikasi Anda. Jadi diskusi penting. Saya akan menyarankan untuk pindah ke suatu tempat, saya dapat menempatkan daftar ini sebagai artikel Medium dan kami dapat terus berdiskusi di sana.

@localpcguy ada banyak format, tetapi semuanya tergantung pada berapa banyak yang dapat kami dukung. Menulis dan memelihara serializer membutuhkan waktu. Xliff 2 ditambahkan sebagai PR oleh orang lain, itu sebabnya kami menambahkan dukungan (jika tidak, kami tidak akan meluangkan waktu untuk mendukungnya).
Kami membutuhkan serializer untuk dua hal: ekstraksi, dan penggabungan.
Saya belum membicarakan ini di Angular Connect, tetapi harapan saya adalah kita harus dapat menggunakan serializer eksternal. Seharusnya sangat mudah untuk melakukan itu untuk runtime (penggabungan) dengan ivy, tetapi ekstraksi masih rumit karena serializer perlu diperbarui ketika kami melakukan perubahan pada kompiler.
Saya punya beberapa ide tentang cara melakukannya, tetapi saya harus membicarakannya dengan tim setelah ivy mendarat. Apa yang benar-benar ingin saya lakukan adalah setidaknya menambahkan dukungan JSON sehingga saya dapat menulis ulang ngx-translate menggunakan Angular i18n (dan karena begitu banyak orang menginginkannya).

Terima kasih @ocombe (dan semua masukan lainnya, saya suka melihat berbagai tampilan). Sepertinya #14185 adalah PR yang Anda sebutkan, apakah itu masih merupakan tempat awal yang baik jika saya ingin menambahkan dukungan ARB? Apakah itu sesuatu yang berpotensi digabungkan jika dikirimkan?

@localpcguy kami mengadakan pertemuan besok di mana kami akan membahas itu (dan hal-hal lain), saya akan memberi tahu Anda bagaimana kelanjutannya

ok jadi inilah yang menurut kami akan berhasil: untuk ekstraksi, kami akan mengekstrak string dalam beberapa jenis format json (bahkan mungkin ARB karena ini adalah format json resmi untuk terjemahan) yang dapat diambil dan diproses oleh siapa pun ke format apa pun yang ingin Anda gunakan (json sangat mudah digunakan), dan untuk runtime kami akan menyediakan beberapa jenis antarmuka yang dapat Anda gunakan untuk menulis loader Anda sendiri yang memahami format Anda.

Jadi ini cukup berarti, bahwa kami bebas menggunakan format apa pun untuk terjemahan selama kami dapat menyediakan pemuat untuk aplikasi?

Nah ini akan luar biasa :+1:

ya, Anda tidak akan memiliki akses ke pengoptimalan mendalam (ganti string pada waktu pembuatan untuk membuat satu bundel per bahasa, artinya terjemahan akan dipecah kode dengan komponen Anda), tetapi Anda dapat menggunakan solusi pemuatan lambat apa pun yang Anda inginkan, selama Anda memuat semua terjemahan saat aplikasi dimulai (mereka harus dimuat secara sinkron sebelum komponen dibuat)
Anda juga pada akhirnya dapat membagi kode secara manual dan memuatnya dengan router secara tidak sinkron ketika Anda memuat komponen baru, itu terserah Anda, menggunakan fungsionalitas pemuatan malas baru yang disediakan ivy (Jason melakukan demo di Angular Connect)

dapatkah kita mengharapkan demo beta (bukan file hanya video atau streaming langsung) dari peralihan bahasa dengan cepat di Ivy? mencoba mengumpulkan ivy pra-final POC mungkin merupakan cara yang bagus untuk mendeteksi rentetan garis.

bukannya saya tidak setuju dengan pendekatan menunggu lebih banyak set-in stone ivy sebelum menggali keringat pengembang ke live-i18n, saya pikir POC skala kecil satu orang adalah sejumlah kecil keringat untuk pengembalian besar dalam bentuk pandangan ke depan dan berpotensi menghindari live-i18n didorong ke 2020.

Layanan runtime untuk pengguna eksternal belum selesai, kami hanya memiliki kode yang menggunakan penutupan ( goog.getMsg ) karena itulah yang kami perlukan untuk menguji ivy dengan aplikasi Google.
Saya akan mengerjakan ini sekarang untuk beberapa bulan mendatang. Ini berarti Anda mungkin belum dapat menggunakan i18n dengan ivy.
Kode untuk runtime i18n baru saja digabungkan kemarin, dan kode kompiler untuk i18n akan digabungkan dalam beberapa hari ke depan (kita sampai di sana!). Kemudian kami akan mengerjakan layanan baru untuk orang eksternal, termasuk pemuat baru yang saya bicarakan di atas, dan layanan untuk menggunakan terjemahan dalam kode Anda.

Untuk mengganti bahasa dengan cepat, itu masih memerlukan pemuatan ulang aplikasi secara penuh, atau mungkin perubahan rute (yang akan membersihkan semua komponen yang ada). Saya belum akan mencoba mengerjakan POC.

Untuk mengganti bahasa dengan cepat, itu masih memerlukan pemuatan ulang aplikasi secara penuh, atau mungkin perubahan rute (yang akan membersihkan semua komponen yang ada). Saya belum akan mencoba mengerjakan POC.

itu wajar, ...namun tidak memerlukan pemuatan ulang aplikasi secara penuh (atau apa pun yang memberikan kelancaran di mata pengguna akhir, AKA tidak kehilangan toko, atau autentikasi, atau url (yah... tidak terhitung /en/... ) dan semua dalam penundaan yang wajar) ....masih rencananya, kan?

@tatsujb Memuat ulang aplikasi tidak memuat ulang halaman, StackBlitz memuat ulang aplikasi pada setiap pengeditan, apakah Anda merasa itu terlihat oleh mata Anda?

Memuat ulang aplikasi berarti melepas aplikasi dan kemudian memasang aplikasi di posisi yang sama, setara dengan transisi SSR-CSR (itu CSR-CSR), dan seharusnya tidak ada tugas asinkron dalam proses bootstrap berikutnya jika arsitektur cache yang tepat sedang dipertimbangkan.

jadi dengan pengaturan yang benar ini; menyimpan nilai variabel dan otentikasi (serta jumlah gulir pada div yang dapat digulir) akan tetap ada?

@tatsujb Selama mereka disimpan di luar instance yang dibuat Angular, misalnya dalam variabel leksikal atau properti jendela.

@trotyl Bagaimana Anda memuat ulang aplikasi tanpa halaman?

@saithis Anda selalu mem-bootstrap aplikasi dengan platformBootstrap().bootstrapModuleFactory() (atau yang setara lainnya), Anda dapat memanggilnya kapan saja di mana saja, tidak ada keajaiban saat dipanggil (kecuali Angular CLI saat ini memiliki beberapa batasan untuk penggantian kode, seharusnya tidak lagi menjadi masalah di Ivy).

Bootstrap dengan penuh semangat pada waktu pemanggilan skrip dan simpan selamanya (jangan dilepas) hanyalah praktik umum untuk SPA, tetapi tidak ada yang memaksa Anda melakukan itu.

EDIT: jika seseorang melakukannya, itu juga diperlukan untuk menghancurkan NgModuleRef yang di-bootstrap untuk mencegah kebocoran memori. Ini adalah pertanyaan di luar topik dan lebih baik dibahas di saluran lain, lebih baik ikuti diskusi i18n di sini.

@trotyl Terima kasih, saya tidak tahu bahwa bootstrap lagi berfungsi.

@ocombe bisakah Anda menghapus spam di sini? dan juga komentar saya.

1. ke @fetis : orang-orang seperti Anda harus berhenti mengikuti masalah & berlangganan untuk rilis
   

2. ke @Andrulko : kami tidak peduli

3. ke @ angular : seperti yang dikatakan saya sangat mengerti keluhan di sini! seperti kami menginginkan ivy untuk v7 bukan untuk vX atau tidak menjual peningkatan besar untuk v7 sementara Anda tidak dapat menanggapinya atau Anda akan memasukkannya ke dalam 7.x hanya untuk menghormati tenggat waktu Anda... ini tidak adil! ya pilihannya adalah untuk tidak mengumumkan apa pun dan tidak ada yang akan mengeluh ini juga ide yang buruk, Anda perlu membuat tempat Anda dalam kerangka kerja. ya kami menunggu i18n yang benar sejak v2, dalam aspek wajib ini untuk aplikasi besar Anda tidak dapat menjual siap pakai sudut untuk aplikasi besar seperti aplikasi web internasional yang berisi 50000 string, tentu saja Anda tentu tidak suka membaca ini tetapi tanpa belas kasihan dan dengan baik iman, imho jika kita tidak mempertimbangkan i18n dan waktu pembuatan/pengembangan yang lambat untuk semua aspek lainnya, saya dapat mengatakan bahwa sudut itu luar biasa. arah tertentu harus berubah di atas, saya berbicara dengan penentu tentu saja. pengecualian tinggi dari kami (yang mengkritik) karena dari big-google kami tidak dapat membuat kesalahan besar seperti ini. saya melihat pengembang google menyukai pengecualian- orang pintar tanpa kesalahan hal ini seharusnya tidak terjadi pada pengembang berpengalaman dan untuk devteam seperti google! pendapat global saya tidak menjual sudut 100% untuk aplikasi besar ketika perusahaan memilihnya kemudian menjual/menjelaskan perusahaan swasta apa itu open source!

4. @ semua terutama bagi mereka yang tidak bekerja di perusahaan bisnis: tidak suka komentar saya karena saya pasti tidak menghormati open source?!?!, lol katakan ini kepada bos saya untuk menunggu.. menunggu... setelah memilih sudut karena kami percaya sudah siap (100% bukan 80%) untuk aplikasi besar... kami bergantung!

ini adalah komentar terakhir saya di sini karena kami meninggalkan kapal! berhenti berlangganan + tidak memilih sudut di proyek saya berikutnya (Anda bisa mengatakan Anda adalah pemenang, proyek sumber terbuka tidak membutuhkan orang-orang seperti kami)

gairah seperti itu! Hanya untuk keseimbangan ... kami menulis ulang aplikasi kami di Angular 6, diinternasionalkan dalam 6 bahasa, dan hanya merasakan ketidaknyamanan kecil. Tentu, waktu pembuatan dan terjemahan yang lebih cepat tentu akan menyenangkan, tetapi bukan akhir dunia bagi kami. 98% dari kerangka kerja yang bukan i18n luar biasa. Kerja bagus! Menantikan fitur baru.

Kami juga memiliki pengalaman yang fantastis dengan Angular untuk portal perusahaan baru kami. I18n adalah fitur terakhir yang hilang yang kami butuhkan karena, di Swiss, kami harus mendukung empat bahasa. Saya pikir masalahnya di sini adalah dengan komunikasi. Untuk perencanaan proyek, jika kami memiliki perkiraan yang lebih baik tentang rilis i18 setahun yang lalu, kami dapat merencanakannya dan mempertimbangkan kemungkinan lain. Karena itu, kami menantikan untuk mendengar pembaruan apa pun. :-)

Untuk mempertahankan sudut, Anda dapat menggunakannya dengan cukup sederhana dalam produksi seperti ini (solusi terbaik yang saya temukan)

1. Bungkus teks variabel yang diterjemahkan dalam komponen sendiri untuk memindahkan logika terjemahan di suatu tempat

parent-component.component.html

<app-route-translation
  [routeData]="routeData"
></app-route-translation>

route-translation.component.html

<span
  i18n="route text|Navigation text for route@@routeText"
>{
  routeData.langKey, select,

  home-1 {Home 1}
  home-1-1 {Home 1-1}
  home-1-2 {Home 1-2}
  home-2 {Home 2}
  home-2-1 {Home 2-1}
  home-2-2 {Home 2-2}
  home-root {Home root}
  lazyPage {Lazy page}
  notFound {404}

  other {Other}
}</span>

1. Konfigurasikan folder konfigurasi build di angular.json seperti

"prod-en": {
  ...
   "outputPath": "dist/en/",
  ...
},
"prod-ru": {
  ...
   "outputPath": "dist/ru/",
  ...
}

1. Konfigurasikan file build buruh pelabuhan seperti ini untuk mengkompilasi aplikasi untuk berbagai bahasa

FROM node:8 as build-stage
WORKDIR /app
COPY angular-util .
RUN npm install
RUN npm run ng build -- --configuration=prod-en
RUN npm run ng build -- --configuration=prod-ru

FROM nginx
WORKDIR /usr/share/nginx/html
COPY --from=build-stage /app/dist .
COPY nginx.conf /etc/nginx/conf.d/default.conf

1. Gunakan nginx.conf ini untuk melayani aplikasi di subdomain (seperti en.site-name.com, ru.site-name.com), di mana ru di set $subdomain ru; harus diganti dengan lokal default Anda

server {
  listen 80;
  set $subdomain ru;
  if ($host ~ ^(\w+)\.) {
    set $subdomain $1;
  }
  location / {
    root /usr/share/nginx/html/$subdomain;
    try_files $uri $uri/ /index.html =404;
  }
}

Untuk lebih jelasnya lihat disini
https://github.com/ivanivanyuk1993/angular-util/tree/master/src/app/util/shared/route-list
https://github.com/ivanivanyuk1993/titans-shoulders-project/tree/master/container-description/ui-container-description

Saya ingin jempol untuk komentar ini. Ini mungkin tidak sempurna, tetapi masih merupakan posting yang paling membantu tentang topik ini yang saya temukan di web

Halo semuanya,

Saya menggunakan terjemahan i18n untuk proyek saya. Saya memiliki keraguan di bidang berikut:

1. Apakah mungkin untuk menghasilkan file sumber xlf yang berbeda untuk perpustakaan yang berbeda (dibuat menggunakan perintah ng generate library libraryName)?
2. Saat menggunakan internasionalisasi untuk pilih atau pluralisasi , file sumber xlf yang dihasilkan membuat id trans-unit untuk alternatif yang berbeda. Apakah mungkin untuk memberikan id melalui templat untuk alternatif yang berbeda juga? (seperti yang ditunjukkan pada gambar di bawah)
   

Tolong bisakah Anda membantu saya dengan beberapa jawaban.

@learnersLicense :

1. Anda harus dapat mengekstrak satu file terjemahan per proyek yang ditangani cli. Meskipun demikian, terjemahan tidak berfungsi dengan perpustakaan saat ini (artinya seseorang yang menggunakan perpustakaan Anda tidak akan dapat memuat terjemahan Anda untuk perpustakaan itu). Itu ada di bagian atas daftar tugas kami untuk fitur berikutnya yang akan kami terapkan (dengan terjemahan kode)

1. Saya tidak berpikir itu mungkin. Anda dapat memberi nama placeholder dengan komentar khusus: <div i18n>Some value: {{ valueA // i18n(ph="PH_A") }}</div> tetapi saya rasa itu tidak berfungsi dengan ekspresi ICU, @AndrewKushnir ?
   Anda dapat membuat permintaan fitur untuk itu, atau mungkin menambahkan komentar ke https://github.com/angular/angular/issues/24080 yang tampaknya serupa (tambahkan desc/artinya ke ekspresi ICU)

seseorang yang menggunakan perpustakaan Anda tidak akan dapat memuat terjemahan Anda untuk perpustakaan itu

Salah satu cara untuk menyiasatinya adalah:
1) memiliki ekstrak perpustakaan i18n ke xliff & terjemahkan
2) mengirimkan file xliff dengan paket perpustakaan

3) konsumen juga mengekstrak file xliffnya sendiri
4) konsumen memuat xliff ke dalam parser xml. menjatuhkan semua trans-unit yang berasal dari node_modules
5) konsumen menggabungkan xliff dengan perpustakaan xliff

artinya seseorang yang menggunakan perpustakaan Anda tidak akan dapat memuat terjemahan Anda untuk perpustakaan itu

Mungkin saya salah memahami pernyataan ini, tetapi saya tahu dengan pengaturan terjemahan untuk aplikasi perusahaan saya ketika saya membuat file xlf saya, mereka menyertakan kunci yang ditentukan dalam templat proyek lain. Salah satu yang terlintas dalam pikiran adalah https://github.com/ng-bootstrap/ng-bootstrap

Ini sepertinya tidak mungkin saat ini:

<my-button i18n-title="@@SHARED_GO_LABEL" [title]="'Go'" [button-style]="'primary'" (click)="navigateToForm()"></my-button>

Dalam lingkup perubahan ini, apakah ini akan ditangani (atau apakah saya melakukan sesuatu yang salah)?

@mikejr83

Itu mungkin. Anda hanya perlu menetapkan nilai dasar title sebagai title="Go" dan bukan [title]="'Go'"

terima kasih @ocombe dan @ewok-janitor atas jawaban dan saran Anda. 👍

@ocombe apakah ada tanggal tentatif kapan terjemahan untuk perpustakaan mungkin tersedia?

Tidak ada tanggal untuk saat ini. Untuk rilis pertama ivy kami hanya mencoba untuk memiliki paritas fitur. Kami akan mengerjakan fitur-fitur baru (termasuk terjemahan kode dan dukungan perpustakaan) tepat setelahnya (atau sebenarnya kami akan mulai mengerjakannya sebelumnya, tetapi itu tidak akan selesai ketika ivy dirilis dalam versi alfa). Ini akan tersedia sebelum ivy menjadi default.

Apakah sudah ada perbaikan untuk file xliff? https://github.com/angular/angular/issues/17506
Tidak mungkin menggunakan format sama sekali selama referensi tidak diperbaiki.

@ocombe Adakah rencana untuk mendukung terjemahan rute?

sudah diminta beberapa kali ya, ini bukan rencana langsung tetapi ada dalam daftar hal yang harus dilakukan

Hai, apakah ada dokumentasi tentang cara menggunakan runtime i18n ketika ivy dirilis dalam versi beta?

@marcelnem , jika Anda memeriksa URL ini, semua poin dokumentasi tertunda.

https://is-angular-ivy-ready.firebaseapp.com/#/status

@ocombe pekerjaan hebat yang Anda lakukan di Google sekarang. Angular i18n seharusnya 'sesuatu' seperti ngx-translate dari awal. Saya bertanya-tanya apakah akan ada panduan migrasi, alat otomatis, perbandingan fitur,... untuk bermigrasi dari ngx-translate ke gaya Angular i18n setelah Angular 8/9 dirilis?

hai ocombe
Perlu memeriksa dengan Anda mengenai Fitur ini, yang Anda nyatakan di atas
Runtime i18n (satu bundel untuk semua lokal dengan AOT) - [mengerjakannya] >> Apakah ini masih dalam proses, atau sudah selesai

Bisakah Anda memberi tahu saya, pekerjaan apa pun, jika masih dalam proses
Terima kasih

@ocombe Anda menulis di atas bahwa paket bahasa harus dimuat dengan pemuatan berenda. Apakah mungkin juga memuat paket bahasa secara langsung di index.html? Karena kami memiliki kasus bahwa aplikasi kami berjalan di atas AWS Lambda dan file sudut yang dikompilasi disimpan dalam ember S3. Sebenarnya ini sudah merupakan solusi bahwa ini berfungsi sama sekali, tetapi kami tidak dapat menggunakan pemuatan berenda karena Angular tidak dapat memuat file dari host lain. Oleh karena itu, semua file yang dibutuhkan Angular harus sudah disertakan dalam index.html (tempat kita menambahkan host S3 melalui skrip).

@nidhi8953 masih WIP, akan tersedia dengan ivy, untuk saat ini hanya berfungsi di dalam google (karena kami menggunakan Closure Compiler secara internal untuk terjemahan). Layanan runtime yang akan menangani terjemahan sangat eksperimental untuk dunia luar. Jika Anda ingin menguji beberapa hal, Anda dapat melihat contoh ini: https://github.com/angular/angular/blob/master/packages/core/test/bundling/hello_world_i18n/index.ts tetapi Anda harus tahu itu fungsinya masih pribadi karena suatu alasan, mereka akan diganti namanya dan diubah dalam waktu dekat. Tujuan saat ini adalah untuk mulai mengerjakan sekumpulan API yang solid setelah v8 keluar (pada akhir bulan) dan mengulanginya untuk keseluruhan v8 hingga v9 keluar, pada titik mana API harus dianggap stabil

@vekunz jika kami mengikuti rencana kami saat ini, itu mungkin ya, karena Anda tetap harus memuat file terjemahan di bootstrap aplikasi Anda

@ocombe Bisakah kita menggunakan Ivy (saat ini 8.0.0-rc.3) dan mengimplementasikan i18n menggunakan metode Angular 7 dari beberapa build? Atau apakah saya harus tetap menggunakan Angular 7 hingga API i18n untuk Ivy dirilis? Jika memungkinkan, saya sangat ingin memanfaatkan Ivy, sementara pada saat yang sama menggunakan cara lama i18n hingga metode runtime baru tersedia.

Pembaruan: Setelah mencobanya, ekstraksi ng xi18n (lihat #https://github.com/angular/angular-cli/issues/14225) maupun bangunan dengan i18n tidak memiliki efek apa pun. Tidak ada file .xlf yang diekspor dan tidak ada kata yang diterjemahkan. Tetapi dengan opsi enableIvy disetel ke false di tsconfig.app.json, keduanya bekerja dengan baik dengan versi 8.0.0-rc.3. Ini berarti saya dapat mengikuti jalur peningkatan Angular, tidak kehilangan i18n, mendapatkan beberapa manfaat baru seperti pemuatan diferensial, dan siap untuk mengaktifkan Ivy setelah i18n berfungsi.

@jacobbowdoin saat Anda mengetahuinya tidak berfungsi dengan ivy aktif, tetapi berfungsi jika tidak diaktifkan.
Saya ingin membuat sistem ekstraksi/pemuatan lama bekerja dengan ivy, tetapi karena itu hanya sementara, itu tidak ditentukan sebagai prioritas oleh tim (yang dapat dimengerti, membuat hal-hal wajib bekerja terlebih dahulu adalah prioritas).

Hai @ocombe , kami ingin mengembangkan i18n sekarang, jadi kami tidak sabar menunggu runtime-i18n. Apakah Anda masih merekomendasikan untuk menggunakan ngx-translate? Apakah masuk akal untuk menggunakannya dengan i18n-polyfill? Akankah menggunakan i18n-polyfill membuat migrasi ke runtime-i18n lebih mudah?

Jika Anda menggunakan ngx-translate, jangan gunakan i18n-polyfill. Masuk akal untuk menggunakannya jika Anda menggunakan angular i18n untuk templat.
ngx-translate masih relevan dan mudah digunakan. Anda tidak harus menempatkan semua infrastruktur pada tempatnya untuk mendukung beberapa build (satu per lokal).

Hai @ocombe , apakah ada update status di :

-Waktu berjalan i18n
-Gunakan string terjemahan di luar template - #11405

Kami sedang berdebat apakah kami harus menunggu terjemahan kode sumber atau menggunakan i18n-polyfill (kami sudah mulai dengan i18n). Kami dapat dengan mudah menunggu beberapa minggu, jadi perkiraan waktu akan dihargai. Terima kasih banyak!

@halilovicedvin segera setelah ivy menjadi default di aplikasi google, kami akan mulai mengerjakan layanan runtime i18n untuk pengguna eksternal, jadi antara segera dan v9
Saya tidak akan mengandalkannya sampai setelah musim panas karena orang-orang akan mengambil cuti beberapa hari

@halilovicedvin kami mulai dengan i18n dengan i18n-polyfill beberapa minggu yang lalu dan itu berfungsi dengan baik. Saya harap runtime-i18n akan digunakan dengan cara yang sama seperti i18n-polyfill

@vekunz Saya juga berharap jika kita menggunakan ngx-translate dengan i18n-polyfill , kita akan dapat bermigrasi lebih mudah ke runtime-i18n tetapi setelah komentar dari @ocombe (https://github.com/angular/angular/issues /16477#issuecomment-498239301) Saya tidak yakin apakah upaya tambahan untuk menyiapkan polyfill dapat dibenarkan. Mungkin kita akan menggunakan ngx-translate saja.

@vekunz apa pengalaman Anda mengaturnya?

@marcelnem Anda tidak dapat menggunakan ngx-translate dengan i18n-polyfill. i18n-polyfill hanya untuk digunakan dengan angular-i18n.

Setup i18n-polyfill memang sangat mudah. Bahkan dokumentasinya tidak sepenuhnya benar, saya menemukan dengan sangat cepat apa yang harus diubah.

@vekunz saya mengerti sekarang, terima kasih. Saya tidak yakin apa tujuan dari i18n-polyfill itu. Apakah Anda masih harus membuat aplikasi beberapa kali dan menerapkannya beberapa kali di bawah http://myapp/en , http://myapp/de , http://myapp/fr ,... seperti pada angular i18n resmi?

@marcelnem ya, Anda juga perlu beberapa build dengan i18n-polyfill. Tujuannya adalah agar dengan angular-i18n Anda dapat menggunakan terjemahan yang saat ini hanya di dalam templat html dan bukan di dalam kode skrip Anda. i18n-polyfill memperluas angular-i18n untuk menggunakan terjemahan di dalam kode TypeScript Anda juga.
Dengan Angular 9 (datang di musim gugur) angular-i18n akan mendukung terjemahan di dalam TypeScript juga, tetapi sementara itu kami membutuhkan i18n-polyfill untuk ini.

@vekunz dapatkah Anda menjelaskan lebih detail tentang ini: "Bahkan dokumentasinya tidak sepenuhnya benar, saya menemukan dengan sangat cepat apa yang harus diubah." Saya mungkin melihat ke i18n-polyfill minggu depan, jadi info apa pun akan dihargai. Terima kasih

@halilovicedvin @marcelnem Saya membuat dokumen pastebin di mana saya menjelaskannya, karena itu bukan topik utama dari Masalah GitHub ini https://Pastebin.com/Xib6X6E9

@ocombe Menggunakan alat xi18n, dapatkah saya membatasi jalur input hanya ke folder src (untuk menghasilkan terjemahan) daripada seluruh proyek/repositori?

@ocombe apakah Ivy mendukung banyak lokal dengan Angular 8 (hanya definisi lokal, bukan file bahasa; misalnya untuk pipa tanggal)? Karena tim lain menggunakan Angular saat ini dengan ngx-translate, tetapi satu komponen pihak ketiga memerlukan lokal yang benar. Salah satu opsi adalah menggunakan kompiler JIT dalam mode prod, tetapi ini tidak terlalu bagus. Tetapi mereka juga tidak dapat mengkompilasi bundel baru untuk setiap bahasa, karena ini akan sangat berlebihan.

@vekunz tidak, Anda tidak dapat mengatur banyak lokal, Anda perlu mengatur lokal untuk setiap bundel yang dikompilasi (dapat diatur dalam file konfigurasi cli)
Aku tahu bukan itu yang ingin kamu dengar, tapi begitulah untuk saat ini

@ocombe Bisakah Anda memberi tahu sesuatu, saya tahu bahwa tim Angular tidak mengidentifikasinya sebagai masalah, tetapi apakah menurut Anda Angular akan mengizinkan kami di masa mendatang untuk mengubah bahasa saat runtime tanpa memuat ulang aplikasi, sehingga memiliki terjemahan di satu bundel tunggal dan memiliki kemungkinan untuk memuat terjemahan yang tepat dan mengikatnya dengan literal teks?

Memiliki satu bundel ya, tetapi terjemahannya akan dimuat di boostrap (saat aplikasi dimuat). Dengan arsitektur yang ada akan sangat rumit untuk "panas" memuat ulang terjemahan tanpa memuat ulang komponen yang sudah menggunakan terjemahan.
Saya tidak mengatakan bahwa ini tidak mungkin, tapi sayangnya saya tidak melihatnya terjadi di masa mendatang.

Terima kasih @ocombe atas respon cepatnya :) Pertahankan kerja bagusnya :+1:

Ada suatu tempat presentasi @ocombe dari beberapa konferensi sudut (saya pikir AngularConnect) di mana dia berbicara tentang i18n dan Ivy, dan di sana dia menggambarkannya dengan sangat baik, mengapa ini sangat rumit. Saya dapat mencoba menemukan videonya.

Saya rasa saya menemukannya https://www.youtube.com/watch?v=miG-ghJhFPc

Untuk orang yang menunggu runtime i18n dengan ivy, rencana saat ini untuk v9 adalah memiliki terjemahan yang berfungsi dengan ivy tetapi hanya sebagai langkah pembuatan (seperti sekarang dengan mesin tampilan). Ini berarti masih ada 1 build / lokal untuk saat ini, dan tidak akan ada terjemahan kode (hanya terjemahan template).

Kekecewaan. Yah, untuk apa nilainya, terima kasih atas kerja kerasmu!

@ocombe apakah Anda masih akan mempertahankan polyfill untuk terjemahan kode runtime?

jika rusak ya, saya tidak akan menambahkan barang baru ke dalamnya

Agak menyebalkan bahwa i18n telah menjadi warga negara kelas 2 begitu lama... Tidak semua orang bekerja di lingkungan lokal asli bahasa Inggris. ):

Saya setuju, saya mencoba mencari beberapa perusahaan untuk mensponsori saya sehingga saya dapat mengembangkan solusi i18n baru yang kuat untuk Angular (saya punya banyak ide).
Jika Anda berpikir tentang orang yang tertarik, beri tahu saya di Twitter (@ocombe) atau melalui email ([email protected])

@ocombe Saya ingin mengucapkan terima kasih atas pekerjaan Anda juga. Ini berita yang sedikit mengejutkan bahwa Anda harus meninggalkan tim. Seperti yang Anda katakan I had to ... , itu memandu saya untuk bertanya langsung kepada Anda apa alasan utamanya. Saya benci petunjuk dan dugaan tidak langsung itu, jadi itu sebabnya pertanyaan langsung seperti itu kepada Anda.

Saya adalah kontraktor eksternal yang bekerja dengan tim Angular dan bukan karyawan penuh waktu Google dan dengan demikian kontrak saya dapat berakhir kapan saja tergantung pada apa yang dibutuhkan tim.
Mereka merekrut orang baru secara internal untuk membantu proyek dan saya yakin mereka akan menemukan orang yang tepat untuk membantu i18n dan topik lainnya, jadi Anda tidak perlu khawatir tentang masa depan Angular :visage_légèrement_sourant: ini hanya kemunduran sementara

@ocombe Terima kasih atas penjelasannya.

Adakah yang bisa memberi tahu saya bagaimana saya bisa menggunakan i18n (i18n-polyfill) di luar kelas seperti enum atau array const atau sesuatu seperti file .model.ts?

Untuk konstanta, saya masih menempatkannya di kelas. Saya tidak tahu alternatif apa pun :/

@ocombe Terima kasih banyak atas semua kerja keras Anda dengan i18n untuk Angular dengan ngx-translate, i18npolyfill dan dengan tim Angular.
Kami menggunakan pekerjaan Anda setiap hari untuk memberikan terjemahan kepada pengguna kami, seperti yang dipersyaratkan oleh aplikasi non-sepele.
Semoga sukses dalam apa yang Anda lakukan bergerak maju.

Untuk konstanta, saya masih menempatkannya di kelas. Saya tidak tahu alternatif apa pun :/

Hmm.. jika saya memindahkannya ke kelas maka saya perlu membuat variabel statis untuk digunakan. Tapi saya tidak bisa menggunakan i18n ke variabel statis.

kelas ekspor Contoh {
konstruktor (i18n pribadi: I18n) {}
variabel statis = i18n('teks'); // Saya tidak dapat menggunakan i18n di sini karena ini tidak statis dari kelas Contoh
}

Berita sedih... ini "melemahkan" Angular... Seperti yang orang lain katakan, itu tetap hanya ucapan terima kasih yang sebesar-besarnya kepada @ocombe atas kerja bagusnya, semoga berhasil!

Saya ingin tahu, apa kerugian menggunakan ngx-translate? Sepertinya itu mampu persis dengan fungsi yang dicari orang

Saya akan mengatakan bahwa kerugiannya adalah sebagai berikut:

• meningkatkan ukuran bundel (lib eksternal + terjemahan sebagai file eksternal alih-alih mengganti kode pada waktu pembuatan)
• tidak resmi (jika saya mati maka lib dihentikan, dan tidak tingkat dukungan yang sama)
• tidak mendukung xliff/xmb (tetapi mendukung json dan format lain melalui plugin, dan seseorang dapat membuat plugin xliff/xmb untuk mendukungnya)
• mungkin memiliki beberapa perilaku buggy ketika malas memuat/membagi terjemahan (saya tidak pernah memperbaikinya)
• sintaks lebih rumit dibandingkan dengan implementasi resmi
• kinerja (pemuatan awal terjemahan dapat membuat teks menghilang selama 1 detik, dan lebih banyak tekanan memori karena saya harus memantau konten saat runtime untuk melihat apakah ada yang berubah)

Dikatakan demikian, tampaknya cukup baik untuk banyak orang

Sangat ingin tahu bagaimana angular mempromosikan dan berinvestasi dalam aksesibilitas tetapi tidak menyertakan bahasa dalam paket itu. Benar-benar terasa bahwa ini adalah keputusan yang diambil dari lingkungan monolingual.

Berasal dari lingkungan di mana kita biasanya harus melayani 3-4 bahasa secara bergantian, saya telah dengan sabar menunggu rilis fitur ini sejak diumumkan dengan keuntungan yang jelas dibandingkan menggunakan perpustakaan eksternal. Dengan berita ini saya harus mempertimbangkan kembali strategi kami untuk mengelola terjemahan sepenuhnya.

@ocombe Tidak ada kemungkinan Google mempekerjakan Anda bukan sebagai kontraktor?😉

@DmitryEfimenko Kami menggunakan ngx-translate saat ini dan cukup senang dengan itu.

@ocombe apa kemungkinan Google menerima fitur ini dari pengembang/komunitas eksternal? Saya pikir kita menunggu terlalu lama.

jika Anda serius dengannya dan ingin menghabiskan waktu mengerjakannya, maka saya akan mengatakan bahwa kemungkinan besar mereka akan menerima bantuan untuk mengerjakan fitur ini

jika Anda serius dengannya dan ingin menghabiskan waktu mengerjakannya, maka saya akan mengatakan bahwa kemungkinan besar mereka akan menerima bantuan untuk mengerjakan fitur ini

@ocombe @IgorMinar Saya ingin memberikan beberapa pekerjaan sukarela untuk Ivy i18n, beri tahu saya jika ada peluang.

jika Anda serius dengannya dan ingin menghabiskan waktu mengerjakannya, maka saya akan mengatakan bahwa kemungkinan besar mereka akan menerima bantuan untuk mengerjakan fitur ini

Saya bersedia berkontribusi tetapi saya sama sekali tidak tahu ruang lingkup dan kompleksitas tugas. Bisakah kita mengambil daftar dalam pesan asli sebagai spesifikasi/persyaratan kita?

Tidak, daftar ini sekarang sudah usang.
Saya akan memberi tahu tim bahwa Anda berdua tertarik sehingga kami dapat melihat cara mengaturnya.

@ocombe Saya pikir ini lebih dari 2 dari kami.

Yang kami butuhkan dari tim Angular adalah

• daftar persyaratan/beberapa spesifikasi
• estimasi kompleksitas kasar
• 1-2 mentor untuk komunikasi

dengan komunitas itu dapat mengatur pengembangan dan membagi tugas

Ada yang saya ketahui di https://hackmd.io/UfFN_wyVT-Ob1p70nA3N_Q?view

@fetis Mungkin bukan ide yang baik untuk membagi pekerjaan terlalu banyak, komunikasi dan berbagi konteks juga sangat mahal, terutama untuk beberapa pekerjaan inti yang memiliki peluang konflik yang tinggi.

Masih terkejut XLIFF terdaftar sebagai pro (atau lebih tepatnya, kekurangannya untuk ngx-translate adalah penipu). Google Terjemahan dan layanan Google lainnya tampaknya menggunakan file ARB, yang merupakan representasi JSON dari string terjemahan. Misalnya, kami membangun aplikasi seluler kami dengan Flutter/Dart, di mana INTL diimplementasikan dengan file ARB. Akan lebih baik jika tim Angular, saat melihat ini, memperhitungkan ini untuk inter-op yang lebih baik dengan item lain di ekosistem Google.

Mungkin bukan ide yang baik untuk membagi pekerjaan terlalu banyak, komunikasi dan berbagi konteks juga membutuhkan biaya besar, terutama untuk beberapa pekerjaan inti yang memiliki kemungkinan konflik yang tinggi.

Saya setuju tetapi saya tidak berpikir keseluruhan ini dapat disampaikan oleh satu orang dalam waktu yang wajar. Cakupannya terlalu besar

Mungkin bukan ide yang baik untuk membagi pekerjaan terlalu banyak, komunikasi dan berbagi konteks juga membutuhkan biaya besar, terutama untuk beberapa pekerjaan inti yang memiliki kemungkinan konflik yang tinggi.

Saya setuju tetapi saya tidak berpikir keseluruhan ini dapat disampaikan oleh satu orang dalam waktu yang wajar. Cakupannya terlalu besar

@fetis Saya dapat bekerja dengan Anda. Kami benar-benar ingin menggunakan angular i18n dalam proyek kami, tetapi sangat terbatas.

Saya akan memberi tahu tim bahwa Anda berdua tertarik sehingga kami dapat melihat cara mengaturnya.

@ocombe ada umpan balik dari tim Angular?

Saya telah memberi tahu mereka dan mereka tampak tertarik, tetapi mereka perlu membuat rencana konkret untuk semua itu sebelum mereka dapat menerima bantuan eksternal (jika tidak, Anda mungkin tidak akan mengerjakan apa yang dibutuhkan).
@petebacondarwin akan mengambil alih mulai sekarang

Hai @ocombe , Saya sedang membaca komentar dan saya kira-kira mengerti bahwa masih belum ada ketentuan untuk membuat ID dinamis untuk tag i18n saat kami menggunakannya di *ngFor. Apakah ada opsi atau solusi lain? Atau saya harus menggunakan ngx-translate saja.

@swapnilvaidankar Saya tidak berpikir ada solusi, tidak

@swapnilvaidankar - dapatkah Anda menjelaskan apa yang Anda maksud dengan ini?

buat ID dinamis untuk tag i18n saat kami menggunakannya di *ngFor

Seperti yang kita ketahui, untuk menerjemahkan teks statis ke bahasa lain kita harus menggunakan atribut i18n pada tag elemen HTML seperti di bawah ini,

<h1 i18n = "Card Header | Title for the under construction card@@constructionheader">Under Construction</h1>

yang menghasilkan cuplikan file xlf seperti di bawah ini dan kami dapat menetapkan target untuk bahasa apa pun. Di sini saya telah menerjemahkan untuk bahasa Prancis seperti di bawah ini,

  <trans-unit id="constructionheader" datatype="html">
    <source>Under Construction</source>
    <target>En construction</target>
    <context-group purpose="location">
      <context context-type="sourcefile">src/app/app.component.html</context>
      <context context-type="linenumber">3</context>
    </context-group>
    <note priority="1" from="description"> Title for the under construction card</note>
    <note priority="1" from="meaning">Card Header </note>
  </trans-unit>

Tetapi dalam kasus daftar dropdown tampaknya sulit untuk menggunakan atribut i18n.
Misalnya, jika saya ingin menampilkan daftar produk seperti kartu nama, brosur, dan buklet ke dalam daftar dropdown atau daftar sederhana, bagaimana saya bisa menghasilkan id dinamis untuktag maka saya dapat menerjemahkan nama produk ke dalam bahasa Prancis atau bahasa lainnya.

Saya sudah mencoba cara ini,

• 
  {{ produk }}
  

yang menghasilkan cuplikan file xlf seperti di bawah ini dan tidak yakin bagaimana menggunakannya untuk menerjemahkan nama produk ke bahasa lain menggunakanmenandai

  <trans-unit id="product" datatype="html">
    <source><x id="INTERPOLATION" equiv-text="{{ product }}"/></source>
    <context-group purpose="location">
      <context context-type="sourcefile">src/app/product/product.component.html</context>
      <context context-type="linenumber">6</context>
    </context-group>
    <note priority="1" from="description"> product name from List</note>
    <note priority="1" from="meaning">product name </note>
  </trans-unit>

Masalahnya di sini, jika Anda dapat melihat id ditag adalah 'produk' saja. Namun saya mengharapkan id harus dihasilkan secara dinamis sesuai dengan daftar produk yang akan tersedia ke dalam daftar dropdown.

Tidak yakin bagaimana mencapai ini setiap kali berurusan dengan konten dinamis atau daftar konten.

Maaf untuk penjelasan yang luas.
Saya harap Anda telah memahami masalah di sini.

Terima kasih,
Swapnil

Bisakah Anda membuka masalah untuk itu? Ini sebenarnya bukan topik di sini dan jika ada orang lain yang mencari hal yang sama akan lebih mudah menemukannya

Atribut @swapnilvaidankar i18n dimaksudkan untuk terjemahan teks statis bukan konten dinamis. Dalam contoh Anda, "produk" berasal dari kode sumber Anda (didefinisikan dalam file ts Anda) dan Anda perlu menggunakan ngx-translate (atau telah menerjemahkan nama produk secara langsung di file ts), atau berasal dari permintaan Http kemudian nama produk yang diterjemahkan harus disediakan oleh backend Anda.

Saya tidak berpikir kita perlu masalah baru untuk itu. Itu hanya permintaan untuk terjemahan run-time dalam file TS yang sudah diminta berkali-kali.

@swapnilvaidankar jika jumlah opsi terbatas dan Anda sudah mengetahuinya, Anda dapat membuat komponen dengan ngSwitch sederhana yang merender teks. Kami menggunakan solusi ini, bekerja seperti pesona.

@fetis - masalahnya adalah sangat mudah untuk masalah umum ini dilacak ke dalam diskusi tentang hal-hal tertentu. Membuat masalah baru memberikan utas baru untuk melanjutkan diskusi itu tanpa mengganggu yang ini.

@fetis Ya, masalah ini telah saya lihat berkali-kali di banyak tempat namun saya tidak menemukan solusi yang tepat. Saya menemukan ngSwitch juga tetapi bukan solusi yang cocok dalam kasus saya. Namun terima kasih untuk solusinya.

@ocombe Saya percaya saya perlu memposting ini sebagai masalah di tempat lain untuk membahas hal yang sama daripada di sini. 👍

Terima kasih semua atas tanggapannya.

@petebacondarwin @swapnilvaidankar inilah masalahnya https://github.com/angular/angular/issues/11405 yang Anda cari
sejak 2.0.0-rc.6 (!) btw

Halo @ocombe , apakah masalah ini masih terkini? Sepertinya Ivy akan menjadi default di Angular 9 jadi saya ingin tahu apa status i18n? Bisakah Anda memperkirakan kapan bisa siap produksi? Dengan Sudut 9, 10, 11? Jika tidak dengan Angular 9, akankah Angular 9 (dan Ivy) dikirimkan tanpa i18n atau akankah menggunakan i18n lama?

Beberapa info lebih lanjut tentang keadaan saat ini dapat ditemukan dalam masalah ini (https://github.com/angular/angular/issues/11405). Komentar yang layak dibaca dalam edisi ini tentang keadaan saat ini:

• https://github.com/angular/angular/issues/16477#issuecomment -512290696
• https://github.com/angular/angular/issues/16477#issuecomment-50637804
• https://github.com/angular/angular/issues/16477#issuecomment -512548506

Juga ini layak untuk dicoba.

Meskipun kami membalik sakelar di v9 sehingga defaultnya adalah menggunakan ivy, kami berharap bahwa mungkin ada sejumlah skenario yang tidak sepenuhnya berfungsi, dan bahwa proyek-proyek tersebut akan tetap menggunakan view-engine untuk saat ini.
Kami sedang berupaya untuk mengaktifkan dan menjalankan i18n untuk rilis v9.0.0 tetapi itu akan ketat.

Apa status saat ini di "Runtime i18n (satu bundel untuk semua lokal)"?

@Ivajkin - maaf masalah ini tidak diperbarui.

"Runtime i18n" adalah fitur yang sering ditanyakan tetapi dapat memiliki arti yang berbeda bagi orang yang berbeda.
Dalam pendekatan i18n $localize yang baru, dimungkinkan untuk melakukan terjemahan aktual saat runtime.

Runtime sebenarnya bisa agak rumit jika Anda tidak hanya menerjemahkan semua pesan yang mungkin sebelum bootstrap aplikasi Angular. Jika Anda melakukan ini maka pendekatan baru untuk mengkompilasi terjemahan waktu bisa menjadi apa yang Anda butuhkan.

Di i18n baru, terjemahan terjadi di bagian paling akhir dari pipa build Anda - bukan di kompiler Angular - ini berarti Anda harus dapat memberikan pesan yang tidak diterjemahkan di perpustakaan dll dan hanya melakukan terjemahan saat Anda membangun aplikasi akhir.

Ini semua dalam pekerjaan untuk v9.0.0.

Lihat https://github.com/angular/angular/tree/master/packages/localize untuk melihat di mana kami berada.

@petebacondarwin Maukah Anda menjelaskan sedikit tentang terjemahan waktu kompilasi yang baru? Apakah ini akan memungkinkan kami membuat satu bundel (dengan AOT) yang berfungsi untuk semua lokal?

Dalam pendekatan baru, alih-alih melakukan terjemahan di dalam kompiler Angular, kami hanya "menandai" pesan yang perlu diterjemahkan melalui global $localize templated string tag handler . String yang diberi tag ini bertahan dari semua jenis bundling dan minifikasi, sehingga pada akhir alur build Anda, string tersebut masih ada dan dapat ditemukan. File-file ini bisa menjadi bundel perpustakaan Anda yang Anda kirim ke beberapa tim lain untuk disertakan dalam aplikasi mereka!

Kami sekarang memiliki beberapa opsi:

a) menjalankan alat yang secara statis mengidentifikasi pesan yang diberi tag ini dan menggantinya dengan terjemahan. Ini secara efektif menghapus referensi $localize dari JavaScript dan meninggalkan Anda dengan bundel kode minimal untuk distribusi. Alat "kompilasi waktu inlining" ini dapat mengambil sejumlah terjemahan dan menghasilkan salinan bundel Anda untuk setiap bahasa yang Anda terjemahkan. Karena dapat dijalankan di bagian paling akhir dari pipeline build Anda, ia menghindari keharusan menjalankan aspek lain dari build Anda untuk setiap bahasa yang Anda dukung.

b) biarkan tag $localize berakhir di kode yang dijalankan di browser, dan gunakan implementasi $localize untuk menerjemahkan pesan saat runtime. Kelemahan dari pendekatan ini adalah payload ke browser lebih besar karena harus berisi panggilan $localize tetapi juga implementasi terjemahan $localize . Anda juga harus mengirim sendiri terjemahannya ke browser. Salah satu manfaat dari pendekatan ini mungkin untuk mendukung pemuatan terjemahan yang lambat saat runtime. Tetapi dapat dikatakan bahwa melakukan terjemahan di server http (atau membangun server) membuat pengalaman runtime lebih efisien.

Opsi runtime b) tolong. Kami dapat memuat terjemahan sebagai file JSON dan mengganti bahasa saat runtime seperti yang saat ini kami lakukan dengan ngx-translate .

Terima kasih untuk penjelasannya. Saya mengerti bahwa pendekatan a) lebih "Sudut" tetapi keuntungan besar dari pendekatan b) (dan pemuatan lambat secara umum) juga kemampuan untuk secara dinamis mendefinisikan/mengubah terjemahan oleh pengguna (terjemahan yang dimodifikasi untuk aplikasi dapat segera digunakan) . Jika saya memahaminya dengan benar, setiap perubahan kecil dalam terjemahan dalam pendekatan a) akan berarti pembangunan kembali baru.

Ini adalah keuntungan yang sama seperti beralih dari halaman yang dibuat secara statis dengan komponen Angular yang telah ditentukan sebelumnya ke template yang dibuat pengguna berisi komponen sudut yang ditentukan oleh programmer seperti yang diinginkan oleh pengguna (template yang ditentukan dengan cara ini juga akan dimuat dari database... )

Anda mungkin juga telah memikirkan kemungkinan bahwa secara default, pendekatan a) akan digunakan saat memuat. Jika permintaan terjemahan runtime muncul (misalnya, backend akan mulai mengirim terjemahan yang lebih baru), blok yang ditandai (berisi teks statis hingga sekarang) akan mulai dirayapi dan diganti secara dinamis, seperti pada pendekatan b). Jadi b) hanya akan diaktifkan jika diperlukan dan semua bagian yang dapat diterjemahkan akan disiapkan sesuai prosedur a). Saya mengerti bahwa pendekatan seperti itu akan lebih memberatkan daripada b) pendekatan itu sendiri dan tentu saja tidak secara langsung layak dengan cara ini, tetapi ini akan lebih dekat dengan kebutuhan pengguna yang sebenarnya.

Untuk opsi yang Anda daftarkan, saya bersedia mengorbankan sekitar 25% dari kinerja aplikasi dalam kasus tertentu untuk mencapai fungsionalitas dinamis seperti itu (tentu saja saya tidak akan menggunakan pendekatan dinamis ini di mana-mana). Jadi, jika template AOT yang dilokalkan dirender dalam 0,4 detik, dalam kasus template dinamis jika dibuat dalam 0,5 detik, saya masih akan menganggapnya dapat diterima di aplikasi di mana saya memerlukan tanggapan segera terhadap perubahan terjemahan.

@demisx kedua pendekatan akan tersedia dengan v9, tetapi hanya opsi a) akan didukung sepenuhnya pada awalnya (untuk retrokompatibilitas), hal-hal baru mungkin dikembangkan untuk opsi b) sebelum sepenuhnya didukung oleh tim Angular.
Perpustakaan saya Locl akan menyediakan beberapa pembantu untuk opsi b) ketika v9 dirilis sehingga siapa pun dapat menggunakannya, hingga tim Angular menjembatani kesenjangan itu

Sadarilah bahwa terjemahan runtime tersebut tidak akan "reaktif" dalam arti bahwa setelah komponen telah dirender, tidak akan mungkin untuk mengubah teksnya secara dinamis, bahkan jika terjemahan baru dimuat.

Pesan yang diterjemahkan bersifat statis sehubungan dengan string yang diberi tag $localize . Jadi komponen perlu dirender ulang. Dan tergantung pada caching template di IVY, mungkin rendering ulang tidak cukup.

Ini adalah salah satu alasan mengapa terjemahan runtime sulit untuk diterapkan karena perilakunya belum tentu intuitif.

Mengenai pendekatan hybrid mulai dengan terjemahan statis di build dan kemudian menambahkan terjemahan runtime nanti. Ini dapat dilakukan jika inlining waktu kompilasi tidak menghapus tag $localize tetapi hanya memperbarui bagian literal string templated. Padahal, ini akan menghasilkan biaya waktu kompilasi ditambah biaya ukuran bundel tambahan.

Menjalankan ng xi18n pada Angular 9 RC1 mengembalikan "Maaf, tetapi i18n belum diimplementasikan di Ivy", tetapi log perubahan menunjukkan bahwa ada _some_ dukungan i18n yang diterapkan sekarang. Saya berasumsi file terjemahan perlu diperbarui secara manual untuk saat ini?

@neil-119 Saat ini ekstraksi tidak didukung dalam mode ivy. Anda masih perlu menonaktifkan ivy untuk menjalankan ekstraksi. Tetapi kemudian Anda dapat mengaktifkannya kembali untuk menggunakan file terjemahan yang diekstraksi.

Saya harap ini direncanakan untuk menyertakan ekstraksi dalam rilis v9 final.

@neil-119 Angular CLI harus secara otomatis menggunakan VE untuk ekstraksi. Anda tidak perlu melakukan apa pun agar itu berhasil. Kami juga mengujinya jadi saya terkejut itu rusak. Bisakah Anda membuka masalah dengan repro?

Saat ini ekstraksi tidak didukung dalam mode ivy.

atau tidak, itu adalah penghenti pertunjukan. Saat ini, kami memiliki proses otomatis dengan ekstraksi string. Bagaimana kami dapat bermigrasi ke Ivy, jika kami tidak dapat mengekstrak terjemahan secara otomatis?
Memanipulasi sconfig.json every time ? Ini tidak terdengar bagus untukku.

@fetis - saya salah. Jika Anda menggunakan CLI, maka panggilan ng xi18n akan berfungsi seperti yang diharapkan, bahkan ketika ivy diaktifkan.

@petebacondarwin terima kasih. Saya akan mencoba Ivy dalam proyek kami saat ini, jadi harap saya akan segera mengonfirmasi ini

Halo, saya mencoba menggunakan komponen saya (sudut 9.0.0-rc.1)

$localize `some string to localize`;

ditemukan sebagai dokumen dalam kode sumber @angular/localize/init.

Ketika saya mencoba membangun seperti biasa untuk bahasa saya, saya mendapatkan kesalahan ini
No translation found for "4145296873012977836" ("some string to localize").

Bagaimana saya bisa memberikan terjemahan untuk string itu?
Apa yang saya harapkan adalah bahwa ng xi18n akan menghasilkan file .xlf dengan juga teks ini dari kode komponen. Apakah itu benar atau saya melewatkan sesuatu?

Hai @Ks89 - mengekstrak pesan dari kode aplikasi (bukan template) tidak didukung untuk v9.
Tapi Anda bisa menyiasatinya jika Anda licik. 4145296873012977836 adalah id pesan jadi jika Anda memberikan terjemahan dalam file terjemahan Anda dengan ID ini, ID ini akan digunakan saat menerjemahkan.

@petebacondarwin kapan fitur ini akan ditambahkan ke Angular?
Saya pikir sangat penting untuk membuat terjemahan runtime dalam komponen benar-benar berguna.

Ketika saya mengirim file .xlf saya ke penerjemah, saya berharap untuk menambahkan semua string dengan cepat dan kemudian menerapkan hasilnya ke aplikasi dengan sangat mudah.

Terima kasih atas jawabannya

Saya mengharapkannya di 9.1

Jika kita memiliki cara untuk memaksa seluruh aplikasi rerender tidak peduli berapa ChangeDetectionStrategy untuk setiap komponen, maka sangat mudah untuk memecahkan masalah dinamis tersebut.

@petebacondarwin Angular 9 sekarang dirilis dengan fungsi tag $localize baru, tetapi tanpa ekstraksi pesan. Anda mengatakan sebelumnya bahwa kami dapat mengharapkan ini di Angular 9.1. Apakah perkiraan ini masih valid, dan dapatkah kita mengharapkan $localize API stabil?

Anda dapat mengekstrak terjemahan dari template.
Jika Anda ingin menggunakan $localize dalam kode Anda juga, Anda harus melihat Locl: https://github.com/loclapp/locl/
@locl/cli akan memungkinkan Anda mengekstrak dari kode & template

@vekunz - ramalannya masih valid. Selain itu, seperti yang ditunjukkan oleh @ocombe , mekanisme ekstraksi terjemahan CLI saat ini berfungsi dengan baik untuk terjemahan apa pun yang ada di dalam template Angular (yaitu hal-hal yang ditandai oleh tag i18n ). Satu-satunya hal yang tidak dapat Anda ekstrak menggunakan alat inti saat ini adalah panggilan ke $localize dalam kode Anda sendiri (misalnya dalam layanan atau komponen).

Panggilan $localize itu sendiri adalah API yang stabil.

Perkakas yang melakukan terjemahan dan ekstraksi (khususnya pada waktu kompilasi) masih bersifat non-publik. Tapi ini bukan masalah kecuali Anda berencana membangun perkakas Anda sendiri di sekitarnya (seperti yang dilakukan @ocombe di Locl!).

Terima kasih @petebacondarwin , dengan ini, kami dapat menduplikasi teks dari kode menjadi templat komponen "tersembunyi" untuk ekstraksi. Maka ekstraksi dan terjemahan keduanya harus bekerja, bukan?

@ocombe Dengan perkiraan bahwa ekstraksi berfungsi dengan Angular 9.1, manajer kami tidak akan membayar untuk solusi Anda. Terutama karena kita tidak memerlukan pengalihan bahasa dan rute terjemahan secara langsung.

kita dapat menduplikasi teks dari kode menjadi templat komponen "tersembunyi" untuk ekstraksi

Ya memang, solusi ini akan berhasil untuk saat ini.

Saya bingung: Apakah terjemahan runtime juga dimungkinkan di 9.1? Atau hanya mengekstraksi di luar template? Atau tidak satupun dari ini?

Bagi saya terjemahan runtime akan menjadi fitur pembunuh. Untuk menyebarkan beberapa bundel dan memaksa pengguna untuk memuat ulang seluruh halaman bukanlah kegunaan yang baik menurut saya.

@JustDoItSascha
Saya telah membuat demo sederhana, yang mendemonstrasikan terjemahan runtime.
https://stackblitz.com/edit/ivy-vjqzd9?file=src%2Fapp%2Fapp.component.ts

Hai! Saya mencoba memanggil loadTranslations di main.ts karena string diterjemahkan saat JavaScript mem-parsing impor, tetapi itu tidak cukup.

main.ts mengimpor AppModule yang mengimpor AppComponent (di mana saya menggunakan $localize ).

Untuk membuatnya bekerja saya lakukan:

loadTranslations(......);
import('./app/app.module').then(m => platformBrowserDynamic(). bootstrapModule(m.AppModule);

Sekarang ini berfungsi tetapi menyebabkan bundel "complier.js" Angular disertakan dalam bundel vendor.

Adakah cara untuk menghindari itu? Terima kasih

Saat ini, loadTranslations perlu dipanggil sebelum aplikasi dimulai, sehingga dapat dilakukan di polyfills.ts . Dan jika Anda ingin memuat kumpulan terjemahan lainnya, Anda harus memuat ulang halaman tersebut. Jika Anda ingin lebih memahami alasannya, saya menulis https://blog.ninja-squad.com/2019/12/10/angular-localize/ untuk menjelaskannya.

Saat ini, loadTranslations perlu dipanggil sebelum aplikasi dimulai, sehingga dapat dilakukan di polyfills.ts .

Bahkan lebih buruk dari itu, perlu dipanggil sebelum file modul apa pun diimpor, itu sebabnya itu berfungsi jika Anda meletakkannya di polyfills.ts (yang dijalankan sebelum file aplikasi utama), tetapi jika Anda ingin menggunakannya di "main" file maka Anda perlu menggunakan dinamis import(...) untuk modul

@vekunz itu alasan bagus untuk tidak menggunakan lib saya untuk saat ini 😊 yang dikatakan Locl bukan hanya tentang ekstraksi, saya bermaksud menambahkan banyak alat lain untuk menyederhanakan i18n

Apakah ada niat untuk mengimplementasikan runtime i18n di Angular? Kami telah mengharapkan fitur ini selama hampir tiga tahun dan sekarang Ivy ada di sini dan masih setengah matang.

Apakah ada niat untuk mengimplementasikan runtime i18n di Angular? Kami telah mengharapkan fitur ini selama hampir tiga tahun dan sekarang Ivy ada di sini dan masih setengah matang.

Pemahaman saya adalah bahwa Ivy, dalam banyak hal, adalah pendorong untuk hal-hal yang akan datang. Tidak mengherankan bahwa jarum i18n memang bergerak luar biasa dengan dirilisnya Ivy, tetapi itu harus melepaskan potensi perubahan besar di masa depan. Itu sudah saya baca, dan harapan saya.

@Karasuni - Saya pikir kita perlu mengklarifikasi apa arti terjemahan runtime sebenarnya untuk kerangka kerja Angular inti karena ada sedikit kebingungan tentangnya.

Perubahan yang kami buat untuk v9 melibatkan terjemahan berbasis $localize . Tujuan utama dari ini adalah untuk memisahkan terjemahan dari kompiler Angular, sehingga memungkinkan sejumlah perbaikan yang bagus:

Yang pertama, yang segera tersedia untuk semua pengguna v9, adalah untuk mempercepat pembuatan aplikasi yang diterjemahkan. Sebelumnya, seluruh pipeline build harus dijalankan untuk setiap bahasa yang Anda inginkan untuk menerjemahkan aplikasi Anda. Sekarang kompilasi utama aplikasi Anda hanya perlu dijalankan satu dan proses terjemahan akhir, yang secara signifikan lebih pendek dijalankan untuk setiap bahasa pada keluaran build. Untuk mendukung ini ada paket @angular/localize baru, perubahan di dalam kompiler Angular dan seluruh beban pekerjaan di dalam Angular CLI untuk menjadikannya semulus dan setransparan mungkin

Kedua, karena tag $localize dapat dibiarkan dalam kode terdistribusi, sekarang juga dimungkinkan untuk melakukan terjemahan di browser (saat runtime, bukan pada waktu kompilasi). Inilah yang kami maksud dalam kerangka kerja Angular inti sebagai terjemahan runtime. Tapi tolong jangan bahwa hasil akhir dari ini secara efektif sama dengan terjemahan pada waktu kompilasi. Terjemahan hanya terjadi sekali; jika Anda ingin mengubah bahasa saat runtime maka Anda harus me-restart seluruh aplikasi (misalnya melalui reload). Ini memiliki keuntungan memungkinkan proyek untuk menyebarkan satu distribusi dengan banyak file terjemahan, yang membantu dalam sejumlah kecil kasus penggunaan di mana Anda tidak ingin menghasilkan semua terjemahan yang berbeda di muka. Ada beberapa masalah rumit seputar memuat terjemahan cukup awal seperti yang ditunjukkan oleh @ocombe dan yang lainnya di sini. Anda dapat mempertimbangkan https://www.locl.app/ untuk bantuan lebih lanjut dalam melakukan ini.

Perhatikan bahwa terjemahan "runtime" ini juga dapat digunakan pada rute yang dimuat lambat sehingga mungkin layak untuk memiliki rute yang berbeda dalam bahasa yang berbeda tergantung pada bagaimana Anda mengaturnya.

Karena tidak ada satu pendekatan pun untuk pemuatan terjemahan ini yang berfungsi untuk semua skenario, kami belum memasukkan ini ke dalam CLI atau menyediakan API publik yang stabil untuk mendukung ini. Setelah kami mendapatkan pemahaman yang lebih baik tentang kasus penggunaan, kami mungkin dapat menambahkan lebih banyak dukungan untuk ini. Sementara itu, hal-hal seperti Locl mungkin membantu jika Anda tidak ingin mencoba menyelesaikannya sendiri.

Terakhir, perhatikan bahwa perubahan dinamis dari string yang diterjemahkan saat runtime secara khusus tidak didukung (berdasarkan desain) oleh kerangka kerja Angular inti. Mengaitkan string yang diterjemahkan ke dalam sistem deteksi perubahan Angular akan membebani sebagian besar aplikasi dan merusak kinerja. Dari interaksi saya dengan komunitas, saya hampir tidak melihat skenario dunia nyata di mana ini benar-benar diperlukan selain memulai ulang aplikasi pada perubahan bahasa. Jika ini merupakan persyaratan untuk aplikasi Anda, maka Anda dapat mencapainya dengan menggunakan pipa yang dibuat khusus pada string Anda dalam templat yang menarik terjemahan, dan mungkin bahkan memanggil $localize dengan cepat untuk menerjemahkan tetapi tidak terlihat seperti ini akan sangat berkinerja. Jika tidak, Anda dapat mempertimbangkan pendekatan yang lebih dinamis seperti https://netbasal.gitbook.io/transloco/.

Perubahan utama yang datang dalam versi minor berikutnya dari Angular akan meningkatkan ekstraksi terjemahan, yang akan dapat mengidentifikasi dan mengekstrak string lokal dari kode TS - saat ini ekstraksi CLI hanya menangani string lokal dalam template.

Perubahan untuk meningkatkan terjemahan runtime, seperti dijelaskan di atas, tidak akan muncul paling cepat setelah 9.1.

Terakhir, perhatikan bahwa perubahan dinamis dari string yang diterjemahkan saat runtime secara khusus tidak didukung (berdasarkan desain) oleh kerangka kerja Angular inti. Mengaitkan string yang diterjemahkan ke dalam sistem deteksi perubahan Angular akan membebani sebagian besar aplikasi dan merusak kinerja. Dari interaksi saya dengan komunitas, saya hampir tidak melihat skenario dunia nyata di mana ini benar-benar diperlukan selain memulai ulang aplikasi pada perubahan bahasa.

Saya mungkin salah tetapi di utas ini saja banyak orang yang secara tegas menunjukkan minat pada kemampuan untuk mengubah bahasa secara langsung, saat runtime, tanpa harus membangun kembali atau memuat ulang aplikasi. Atau apakah semua orang di sini memiliki definisi yang berbeda tentang runtime translation ?

Saya tidak ingin memuat ulang aplikasi hanya untuk mengganti bahasa. Misalnya ketika pengguna berada di halaman dengan formulir, pemuatan ulang halaman penuh untuk sakelar terjemahan akan mengejutkan pengguna.

Hanya untuk menjadi jelas. Yang ingin saya katakan adalah bahwa banyak orang datang kepada saya untuk mengatakan bahwa mereka benar-benar membutuhkan perubahan bahasa langsung dalam aplikasi mereka. Tetapi ketika Anda menggali alasannya, ternyata tidak. Saya tidak mengatakan bahwa tidak ada skenario yang membutuhkan ini, tetapi dalam pengalaman saya selama setahun terakhir, saya menemukan sangat sedikit.

Pertanyaan: mengapa pengguna perlu mengganti bahasa saat membuka formulir tertentu di aplikasi Anda?

Saya tidak berpikir bahwa live switching juga diperlukan. Seberapa sering Anda mengubah bahasa situs web? Biasanya satu kali, maksimal. Dan untuk kali ini, pemuatan ulang halaman tidak terlalu penting. Seperti yang dikatakan @petebacondarwin , hampir semua skenario untuk pengalihan langsung bukanlah skenario dunia nyata yang relevan tetapi hanya "senang untuk dimiliki."

Atau apakah semua orang di sini memiliki definisi terjemahan runtime yang berbeda?

Saya benar-benar membutuhkan terjemahan runtime. Pelanggan kami harus dapat mengedit dan memperbarui terjemahan di lapangan, tidak hanya di server build. Jadi, runtime, sebagai lawan dari waktu kompilasi.

Pergantian bahasa yang sebenarnya setelah pemuatan halaman adalah hal yang menyenangkan.

Hanya untuk menjadi jelas. Yang ingin saya katakan adalah bahwa banyak orang datang kepada saya untuk mengatakan bahwa mereka benar-benar membutuhkan perubahan bahasa langsung dalam aplikasi mereka. Tetapi ketika Anda menggali alasannya, ternyata tidak. Saya tidak mengatakan bahwa tidak ada skenario yang membutuhkan ini, tetapi dalam pengalaman saya selama setahun terakhir, saya menemukan sangat sedikit.

Pertanyaan: mengapa pengguna perlu mengganti bahasa saat membuka formulir tertentu di aplikasi Anda?

Anda mungkin benar bahwa itu bukan persyaratan yang solid. Saya mungkin mencoba menyebarkan terjemahan saat dimuat tetapi itu akan sepenuhnya mengubah pengalaman pengguna aplikasi yang saat ini dapat beralih bahasa secara dinamis - tanpa memuat ulang atau mengubah posisi di halaman - dengan perpustakaan eksternal. Terjemahan telah menjadi topik hangat untuk waktu yang sangat lama.

Saya punya pertanyaan penting: Bisakah file terjemahan dimuat secara tidak sinkron? Semua terjemahan saya disimpan dalam database karena dapat memperbaruinya tanpa membangun kembali adalah penting.

ya mereka dapat dimuat secara tidak sinkron, tetapi Anda perlu menunda dimulainya aplikasi Anda hingga dimuat

Hanya untuk menjadi jelas. Yang ingin saya katakan adalah bahwa banyak orang datang kepada saya untuk mengatakan bahwa mereka benar-benar membutuhkan perubahan bahasa langsung dalam aplikasi mereka. Tetapi ketika Anda menggali alasannya, ternyata tidak. Saya tidak mengatakan bahwa tidak ada skenario yang membutuhkan ini, tetapi dalam pengalaman saya selama setahun terakhir, saya menemukan sangat sedikit.
Pertanyaan: mengapa pengguna perlu mengganti bahasa saat membuka formulir tertentu di aplikasi Anda?

Anda mungkin benar bahwa itu bukan persyaratan yang solid. Saya mungkin mencoba menyebarkan terjemahan saat dimuat tetapi itu akan sepenuhnya mengubah pengalaman pengguna aplikasi yang saat ini dapat beralih bahasa secara dinamis - tanpa memuat ulang atau mengubah posisi di halaman - dengan perpustakaan eksternal. Terjemahan telah menjadi topik hangat untuk waktu yang sangat lama.

Secara teknis Anda dapat memuat ulang seluruh aplikasi dan tetap mempertahankan pengguna di tempatnya.
Anda "hanya" perlu memiliki aplikasi berbasis status (dengan ngxs, ngrx, atau perpustakaan manajemen status lainnya) yang disimpan di suatu tempat dan diambil saat startup.

Satu-satunya trik adalah menjaga posisi gulir tetapi itu juga layak.

@petebacondarwin Saya harus mengatakan bahwa saya setuju dengan Anda. Saya tidak tahu pengguna akhir yang sebenarnya (kecuali penguji dalam fase pengembangan) yang mengganti aplikasi secara permanen antar bahasa saat menggunakannya. Tentu, mereka mungkin melakukannya di awal jika mereka membukanya di tempat yang berbeda, tetapi kemudian, ini adalah kasus yang jarang terjadi.

Atau apakah semua orang di sini memiliki definisi terjemahan runtime yang berbeda?

Saya benar-benar membutuhkan terjemahan runtime. Pelanggan kami harus dapat mengedit dan memperbarui terjemahan di lapangan, tidak hanya di server build. Jadi, runtime, sebagai lawan dari waktu kompilasi.

Pergantian bahasa yang sebenarnya setelah pemuatan halaman adalah hal yang menyenangkan.

Saya tidak yakin, apa yang dilakukan pelanggan Anda, tetapi "pengeditan terjemahan langsung di situs web produksi" tidak terdengar seperti skenario umum.

Saya tidak melihat mengubah bahasa secara langsung (_tanpa memuat ulang halaman_) menjadi pemecah kesepakatan.
Mengubah bahasa untuk pengguna hanya terjadi sekali;

Pikirkan tentang hal ini, berapa kali Anda telah mengubah bahasa telepon Anda? mungkin sekali atau Anda baru saja menggulir dengan bahasa default.

Menonton perubahan bahasa untuk melakukan perubahan langsung tanpa memuat ulang halaman membawa banyak penalti kinerja untuk sesuatu yang hampir tidak digunakan seumur hidup pengguna.

Pada akhirnya, dalam datang ke 3 hal bagi saya;

1. Ekstrak terjemahan dari template dan file TS.
   
   
   
   • Perbarui aset lang sumber.
   
   
   • Perbarui terjemahan juga (_jika saya memiliki banyak bahasa, fr, en, de... Saya ingin semuanya diperbarui dengan kunci terjemahan baru dan yang dihapus._)
   
   
2. Satu build untuk semua terjemahan (_Memiliki 1 build untuk setiap terjemahan juga boleh, asalkan tidak menggandakan waktu build._)
3. Dapatkan bahasa yang tersedia dan ubah bahasa dengan memuat ulang.

@Karasuni
Anda dapat mengambil terjemahan async dan baru kemudian memuat aplikasi sudut.
Lihat komentar saya di atas tentang cara memuat app.module asynchronous menggunakan import(...) .

secara pribadi saya menggunakan Wikipedia untuk mencari tahu apa judul film yang saya tahu "diterjemahkan" ke dalam bahasa lain.

di hari ini dan usia menjadi bilingual atau trilingual lebih dari biasa (selain dari dalam AS, tidak ada salahnya dimaksudkan).

pengguna mungkin ingin tinggal beralih bahasa itu benar-benar masuk akal. contoh Wikipedia adalah hasil positif dari mengaktifkan ini, saya tidak melihat mengapa kita harus menahan penggunaan potensial lainnya sebelum mereka hidup untuk melihat cahaya hari dengan dalih kinerja.

bahkan ngx-translate ocombe yang harus menjadi contoh yang sama untuk kalian tentang "terjemahan kinerja yang buruk" berjalan cukup cepat untuk pengguna sehari-hari.

Saya pribadi menguasai tiga bahasa dan saya tidak bisa menggunakan satu bahasa: semua bahasa itu indah bagi saya

dengan semua yang dikatakan saya tidak setuju dengan ini:

Pikirkan tentang hal ini, berapa kali Anda telah mengubah bahasa telepon Anda? mungkin sekali atau Anda baru saja menggulir dengan bahasa default.

Wikipedia adalah contoh terburuk dari hal ini karena bahasa artikel yang berbeda sebenarnya adalah artikel independen. Biasanya Anda tidak memerlukan bahasa yang berbeda dari situs yang sama persis. Bahkan jika Anda bekerja quadrilingual.
Dan jika Anda benar-benar membutuhkan pengalihan langsung, Anda dapat menggunakan solusi dengan pipa terjemahan khusus, yang disebutkan oleh @petebacondarwin atau alat baru dari @ocombe.

Oke, jadi menurut saya ini bukan tempat terbaik untuk berdiskusi. Saya khawatir bahwa (walaupun sejauh ini semuanya sangat masuk akal) kita mungkin tergelincir ke dalam diskusi negatif. Saya khawatir bahwa di masa mendatang kerangka kerja Angular tidak akan memberikan solusi peralihan bahasa langsung di luar kotak.

Saya merasa bahwa nilai dari masalah ini telah berjalan dengan sendirinya. Saya telah memindahkan masalah terbuka dan PR yang ditautkan dalam deskripsi masalah ini ke https://github.com/angular/angular/milestone/101 dan saya akan menutup dan mengunci PR ini.

Jika Anda memiliki masalah baru dari permintaan fitur, silakan buka masalah baru dan beri tag saya di dalamnya.