Edaran memeriksa dan switching API untuk menjaga aliran terjemahan

[Simon Lloyd]

Aku punya saya batas karakter untuk google yang ditetapkan untuk 100.000 perday sehingga dengan setelan "Selalu menggunakan Google", "Penggunaan Google API V2", "Penggunaan Google deteksi" ketika aku mencapai batas itu dan tidak mendapatkan hasil dari Google dibayar Mungkinkah gratis api kemudian mulai memproduksi hasil?

Jadi sebagai contoh saya menggunakan batas preset Google dan Google tidak lagi kembali hasil bagi saya (mungkin kembali kode kesalahan seperti orang-orang di Google menguji kode Anda) ketika hasilnya tidak dikembalikan itu akan baik jika vBET secara otomatis diakui kode kesalahan dan kemudian mengirim permintaan ke API yang lain seperti Microsoft (atau orang lain yang kemudian vBET yang mendukung) dengan cara ini kita yakin mendapatkan beberapa hasil - bagi saya ini akan sangat sangat berharga mengingat bahwa ada batas bahkan dengan versi dibayar, itu akan memungkinkan Anda untuk memperluas batas-batas terjemahan Anda.

misalnya
Google mengatur Charcters 100.000 per hari > digunakan > vBET pindah ke API berikutnya dalam daftar > Microsoft 400 k per jam atau 4 M, ketika batas dicapai vBET cek API berikutnya dan sebelumnya untuk melihat apakah batas diangkat atau memiliki beberapa penyisihan > baik bergerak ke berikutnya API atau kembali ke Google dibayar ketika batas dicapai lagi > Periksa berikutnya API.... dll dan jadi memeriksa melingkar setelah menerima kode kesalahan akan membawa, jadi cukup banyak kemampuan konstan untuk memiliki terjemahan.

[vBET]

Saya memahami Anda deskripsi dan titik Anda. Sekarang kita harus mengetahui bagaimana kira bekerja secara teknis.

Salah satu masalah yang saya lihat di sini adalah bagaimana kita akan mengenali bahwa kita sudah memiliki batas-batas yang tersedia setelah mereka di mana mencapai sebelum.

Kita yang dapat hanya setiap kali meminta penyedia pilihan dan kemudian pergi ke yang berikutnya. Ini akan biaya kinerja - karena setiap permintaan untuk halaman yang memerlukan terjemahan, kami akan membuat panggilan gagal untuk pilihan selular, kemudian ke selanjutnya satu (sehingga dapat beberapa panggilan gagal ketika vBET akan mendukung lebih banyak api).

Solusi lain akan menyimpan informasi pilihan selular adalah tidak tersedia dan pergi langsung ke berikutnya. Ini akan menjadi lebih cepat, karena memeriksa variabel lokal jauh lebih cepat daripada menunggu respon dari server eksternal. Saat ini kita memiliki masalah lain - kita tidak tahu kapan penyedia pilihan tersedia. Kita dapat tentu saja membuat beberapa tugas terjadwal yang akan meminta sederhana (pendek) terjemahan misalnya sekali per jam/hari untuk memeriksa itu. Jadi dalam strategi ini kita harus memutuskan seberapa sering secara default tugas seperti rasa untuk bekerja. Tentu saja kita akan memeriksa hanya ketika beberapa penyedia ditandai sebagai tidak tersedia.
Juga jika kita menandai penyedia sebagai tidak tersedia - apa lakukan ketika kita tahu bahwa semua penyedia tidak tersedia - menambah informasi bagi pengguna akhir atau hanya menerjemahkan apa yang ada di cache dan sisanya seperti asli, tanpa tambahan info tentang sementara kurangnya terjemahan penyedia.

Tak peduli mana itu akan dilakukan, Google akan diperlakukan sebagai satu API (v1 atau v2 tergantung pada konfigurasi) - ada tidak masuk akal untuk membagi itu, karena Google v1 akan ditutup segera.

Hal lain adalah untuk memungkinkan untuk mengkonfigurasi penyedia antrian untuk setiap pasangan bahasa secara terpisah. Saat ini vBET sudah memungkinkan untuk mengkonfigurasi terjemahan penyedia untuk setiap pasangan bahasa. Saya berpikir bahwa kita dapat mengubah dari satu nilai untuk nilai-nilai dipisahkan koma (CSV). Dengan cara ini kita akan tahu untuk setiap pasangan bahasa penyedia mendukung terjemahan ini dan apa preferensi urutan (urutan hanya pada daftar CSV).

PLEASE NOTE: ini akan memiliki dampak kinerja beberapa tetap. Alih-alih membuat satu objek untuk terjemahan kita harus menciptakan array seperti objek dan objek pembungkus tambahan (untuk membuatnya transparan untuk bagian lain kode dan kurang bug rentan). Tentu saja kita tidak akan membuat objek untuk penyedia yang kita tahu tidak tersedia saat ini.
Solusi untuk ini akan mengkonfigurasi ulang untuk performa yang lebih baik dan menghapus penyedia antrian - seperti itu sekarang - satu provider per pasangan bahasa.
Ini tidak boleh mahal untuk kinerja, tetapi masih beberapa tambahan logika dan memori konsumsi.

Tolong katakan solusi yang lebih disukai.

[vBET]

Dan salah satu solusi potensial lainnya. Jika kita akan menandai seluruh API sebagai tidak tersedia dan periksa dengan tugas terjadwal itu tersedia sekarang, maka kita tidak harus membuat antrian penyedia. Kita dapat melakukannya ini cara - selalu dibuat hanya satu penerjemah objek (penggunaan memori lebih baik) dan dalam satu permintaan kami meminta terjemahan hanya satu provider (CPU lebih baik). Jika akan tidak tersedia, maka akan ditandai sebagai tidak tersedia dan hasilnya akan kosong (terburuk kehandalan). Tetapi hanya pertama, karena waktu berikutnya kita akan menggunakan penyedia lain dari antrian. Dan dalam kasus jika penyedia tidak tersedia, kemudian dummy penerjemah akan digunakan - kembali nilai-nilai yang sama (but do not cache itu) sehingga beberapa bagian akan tidak diterjemahkan tetapi halaman akan tidak memiliki bagian yang kosong seperti sekarang ketika penyedia tidak tersedia.

[vBET]

Hanya cepat pengumuman - kami sudah menerapkan fitur ini.

Kami ingin merilisnya dengan cepat (sebagai BETA) karena masalah umum, yang disebabkan oleh batasan yang ditetapkan oleh penyedia terjemahan. Kami juga mencari API lain yang dapat didukung oleh vBET

[Simon Lloyd]

Pikiran saya adalah untuk mengirim cek terjemahan pertama untuk melihat apakah pilihan penyedia tersedia, jadi Anda memberi kami kode untuk memeriksa jika google atau MS merespons, sehingga pada waktu panggilan untuk terjemahan tes googleapi (nama saya tes file dengan kode tes) jika terjemahan adalah benar menggunakan preffered, jika terjemahan adalah flase atau kode ini tidak 200 kemudian mencoba berikutnya penyedia dalam daftar dan melakukan tes api mereka sebelum menggunakan.

Anda bisa memiliki listbox di mana pengguna dapat daftar setiap penyedia satu per baris dalam urutan pilihan (ini memungkinkan ketika Anda menambahkan dukungan untuk api lainnya pengguna hanya dapat menambahkan mereka ke daftar), jadi saya daftar bisa terlihat seperti ini:
Microsoft
MyTranslator
Google
YourTranslator
AnOtherTranslator

Dengan asumsi nama gila saya masuk adalah penyedia nyata, panggilan untuk terjemahan MS tes kode akan berjalan, jika respon 200 menggunakan MS jika tidak menjalankan MyTranslator tes kode, memeriksa jawaban untuk 200 jika ya menggunakannya jika tidak menjalankan Google tes kode ********** dll

Dengan cara ini Anda tidak pernah menyimpan informasi pada penyedia (jika tidak Anda bisa memiliki teks kotak di mana pengguna dapat memasukkan mereka menetapkan batas untuk setiap penyedia tapi saya pikir wuld informasi ini menjadi tidak berguna karena mereka bisa mengubah ini dan itu berarti lebih banyak memeriksa kembali dan memeriksa maju sebelum membuat terjemahan) Anda tidak akan pernah perlu khawatir jika batas tersedia lagi sehingga tidak perlu untuk cron pekerjaan untuk menjalankan untuk memeriksa ini, beban pada server untuk itu satu kecil terjemahan cek (kode yang Anda berikan dalam FAQ) akan menjadi apa-apa.

Mudah-mudahan saya menjelaskan bahwa ok sehingga Anda mendapatkan ide saya, saya pikir itu semua dapat dilakukan hanya dengan cek yang kecil dan tanpa menyimpan apa-apa.

[Simon Lloyd]

Hanya cepat pengumuman - kami sudah menerapkan fitur ini.

Kami ingin merilisnya dengan cepat (sebagai BETA) karena masalah umum, yang disebabkan oleh batasan yang ditetapkan oleh penyedia terjemahan. Kami juga mencari API lain yang dapat didukung oleh vBET

Saya mengirimkan satu atau dua (di posting Anda dihapus karena link) bahwa Anda bisa mendekati, jika Anda ingin beta relawan i 'm your man

[vBET]

Saya mengirimkan satu atau dua (di posting Anda dihapus karena link) bahwa Anda bisa mendekati, jika Anda ingin beta relawan i 'm your man

Pesan Anda telah lembut dihapus, karena isinya iklan yang ditulis oleh orang lain, tetapi kami memiliki akses ke pesan ini dan kita berada di itu

Kami bahkan sudah mengirim email pertanyaan ke salah satu penyedia terjemahan tersebut tentang rincian pembayaran. Beberapa dari mereka dibayar (bahkan ketika hal ini digambarkan sebagai gratis itu bukan pada API tingkat - sama hal Anda dengan Google Anda dapat menerjemahkan gratis oleh browser, namun tidak oleh API), tetapi harga dapat kompetitif, sehingga masih baik (lebih persaingan harga yang lebih baik).
Beberapa kami telah menyelidiki adalah orang-orang benar-benar eksternal terjemahan API atau hanya lokal kamus yang ditulis oleh pengguna sendiri (ini juga adalah satu hal pada daftar TODO kami - memungkinkan untuk memodifikasi dan menempatkan terjemahan sendiri) - Radek telah bagian ini.

Jadi kami bekerja untuk meningkatkan vBET dan membuatnya semurah mungkin dalam penggunaan

[vBET]

Kami berada dalam tahap terakhir tesing fungsi baru. Anda dapat melihat deskripsi berubah: http://www.vbenterprisetranslator.co...html#post8914 (lihat terakhir CATATAN)

[Simon Lloyd]

Terima kasih Michael, saya membuat posting cepat dalam bahwa Faq yang tidak diragukan lagi Anda harus menghapus karena tidak benar tempat untuk itu Jika Anda ingin menguji pada papan hidup yang panggilan banyak terjemahan PM saya dan saya akan memberikan Anda akses ke akar admincp dan forum, aku juga akan menempatkan google terjemahan batas yang saya telah menetapkan atas dan ke bawah pada perintah Anda sehingga Anda dapat menguji

[vBET]

OK jadi. Penyedia antrian dilaksanakan dan akan disertakan dalam rilis 3.5.1 dan 4.4.3. vBET 3.5.1 akan dirilis hari ini. vBET4.4.3 ini masih dalam tahap pengujian. Stan rilis akan BETA sehingga semua orang dapat mengujinya di forum-forum yang lebih besar yang menguji satu. Harap dicatat bahwa kita sudah menguji 3.5.1 di salah satu forum kami nyata. Masih karena perubahan penting adalah dalam tahap BETA pertama.