Pekeliling memeriksa dan bertukar API untuk menjaga aliran terjemahan

[Simon Lloyd]

Saya mempunyai had watak saya untuk google menetapkan 100000 perday demikian dengan tetapan saya "Sentiasa Gunakan Google", "Gunakan Google API V2", "Gunakan Pengesanan Google" ketika saya sampai ke had itu dan tidak lagi mendapat keputusan daripada Google yang dibayar, ia akan mungkin API percuma kemudian mula mengeluarkan hasil?

Jadi, sebagai contoh i menggunakan had pratetap saya Google dan Google tidak lagi mengembalikan hasil bagi saya (mungkin kembali kod ralat seperti mereka dalam kod ujian Google anda) apabila keputusan itu tidak dikembalikan, ia akan menjadi baik jika vBET secara automatik diiktiraf kod kerosakan dan kemudian menghantar permintaan untuk API lain seperti Microsoft (atau mana-mana orang lain yang menyokong kemudian oleh vBET) cara ini, kita yakin mendapat hasil beberapa - bagi saya ini akan menjadi sangat sangat berharga yang diberikan bahawa terdapat had walaupun dengan versi yang dibayar, ia akan membolehkan anda untuk melanjutkan had terjemahan anda.

contohnya
Google menetapkan 100,000 Charcters setiap hari> digunakan> vBET langkah API seterusnya dalam senarai> 400K Microsoft setiap jam atau 4M apabila had sampai vBET memeriksa API seterusnya dan sebelumnya untuk melihat jika had diangkat atau mempunyai beberapa elaun> sama ada berpindah ke API seterusnya atau kembali ke Google dibayar apabila had sampai lagi> memeriksa API seterusnya .... dan sebagainya dan supaya pemeriksaan pekeliling selepas recieving kod ralat akan menjalankan, supaya cukup banyak kemampuan berterusan untuk mempunyai terjemahan.

[vBET]

Saya faham huraian anda dan mata anda. Sekarang kita telah mengetahui bagaimana ia rasa untuk bekerja teknikal.

Salah satu isu yang saya lihat di sini ialah bagaimana kita akan sedar bahawa kita sudah mempunyai had yang didapati selepas mereka di mana dicapai sebelum.

Kita hanya boleh setiap kali meminta pembekal pilihan dan kemudian pergi ke yang seterusnya. Ini akan menelan belanja prestasi kerana bagi setiap permintaan untuk halaman yang memerlukan terjemahan, kita akan membuat panggilan tidak berjaya kepada pembekal pilihan, kemudian kepada 1 akan datang (supaya ia boleh menjadi beberapa panggilan tidak berjaya apabila vBET akan menyokong API lebih).

Penyelesaian yang lain akan menyimpan maklumat bahawa pembekal pilihan tidak boleh didapati dan pergi terus kepada salah seorang akan datang. Ini akan lebih cepat, kerana memeriksa pembolehubah tempatan adalah lebih cepat daripada menunggu respons dari pelayan luar. Kali ini, kita mempunyai isu lain - kita tidak tahu apabila pembekal pilihan boleh didapati. Kita boleh tentu membuat beberapa tugas yang dijadualkan yang akan meminta terjemahan ringkas (pendek) contohnya sekali setiap jam / hari untuk memeriksa. Jadi, dalam strategi ini, kita perlu memutuskan berapa kerap secara lalai tugas itu kira bekerja. Sudah tentu kita akan menyemak hanya apabila pembekal beberapa ditandakan sebagai tidak terdapat.
Juga jika kami meraikan pembekal sebagai tidak ada apa yang perlu dilakukan apabila kita tahu bahawa semua pembekal tidak boleh didapati menambah beberapa maklumat untuk pengguna akhir atau hanya menterjemahkan apa yang ada dalam cache dan selebihnya sebagai asal, tanpa apa-apa info tambahan mengenai kekurangan sementara pembekal terjemahan .

Tidak kira yang cara ia akan dilakukan, Google akan dianggap sebagai salah satu API (v1 atau v2 bergantung kepada konfigurasi) - tidak ada rasa untuk memecahkan, kerana Google v1 akan ditutup tidak lama lagi.

Perkara yang lain adalah untuk membenarkan untuk mengkonfigurasi beratur pembekal bagi setiap pasangan bahasa secara berasingan. Pada masa ini vBET sudah membolehkan untuk mengkonfigurasi pembekal terjemahan bagi setiap pasangan bahasa. Saya berfikir bahawa kita boleh mengubah dari satu nilai kepada nilai dipisahkan koma (CSV). Dengan cara ini kita akan tahu untuk setiap pasangan bahasa yang pembekal menyokong terjemahan ini dan apa keutamaan perintah (hanya perintah dalam senarai CSV).

SILA AMBIL PERHATIAN: ini akan mempunyai sedikit kesan prestasi pula, "katanya. Selain mewujudkan satu objek untuk terjemahan, kita akan mempunyai untuk mencipta pelbagai objek itu dan Susunan objek tambahan (untuk membuat telus bagi bahagian-bahagian lain kod dan kurang bug cenderung). Sudah tentu kita tidak akan mencipta objek bagi pembekal yang kita tahu tidak boleh didapati pada masa ini.
Penyelesaian ini akan menyusun semula untuk prestasi yang lebih baik dan membuang baris gilir pembekal - sama seperti sekarang - satu pembekal setiap pasangan bahasa.
Ini tidak harus mahal untuk prestasi, tetapi masih ada logik tambahan dan penggunaan memori.

Sila memberitahu penyelesaian yang lebih disukai.

[vBET]

Dan satu lagi penyelesaian yang berpotensi. Jika kita akan menandakan API keseluruhan tidak seperti yang boleh didapati dan periksa dengan tugas yang dijadualkan adalah didapati sekarang, maka kita tidak perlu untuk membuat giliran penyedia. Kita boleh melakukannya dengan cara ini - sentiasa diwujudkan hanya satu objek penterjemah (ingatan lebih baik penggunaan) dan dalam satu permintaan kami meminta untuk terjemahan hanya satu pembekal (yang lebih baik CPU). Jika ia tidak boleh didapati, maka ia akan ditandakan sebagai tidak terdapat dan keputusan akan kosong (kebolehpercayaan terburuk). Tetapi hanya satu pertama, kerana masa depan kita akan menggunakan satu lagi pembekal dari barisan. Dan dalam kes jika pembekal tidak boleh didapati, maka penterjemah dummy akan digunakan - kembali nilai-nilai yang sama (tetapi tidak cache) jadi beberapa bahagian akan tidak diterjemahkan tetapi halaman tidak akan mempunyai bahagian-bahagian kosong seperti sekarang apabila pembekal tidak boleh didapati.

[vBET]

Hanya pengumuman cepat - kita telah melaksanakan ciri ini.

Kita mahu untuk melepaskan berpuasa (sebagai BETA) kerana isu yang sama, disebabkan oleh had yang ditetapkan oleh pembekal terjemahan. Kami juga sedang mencari API lain yang boleh disokong oleh vBET :)

[Simon Lloyd]

Fikiran saya telah menghantar terjemahan cek pertama untuk melihat jika pembekal pilihan tersedia, jadi anda berikan kepada kami kod untuk memeriksa jika google atau MS bertindak balas, jadi pada masa panggilan untuk terjemahan ujian googleapi (nama fail ujian saya dengan kod ujian anda ) jika terjemahan menggunakan benar preffered, jika terjemahan flase atau kod tidak adalah 200, maka cuba pembekal depan dalam senarai dan melaksanakan ujian api mereka sebelum menggunakan.

Anda boleh mempunyai Listbox di mana pengguna boleh menyenaraikan setiap satu pembekal per baris dalam susunan keutamaan (ini membolehkan anda menambah sokongan untuk API lain pengguna hanya boleh menambah mereka ke dalam senarai), jadi senarai saya dapat melihat seperti ini:
Microsoft
MyTranslator
Google
YourTranslator
AnOtherTranslator

Andaikan nama gila i masukkan pembekal yang sebenar, apabila panggilan untuk terjemahan kod ujian MS akan lari, jika 200 tindak balas penggunaan MS jika tidak dijalankan MyTranslator kod ujian, semak jawapan bagi 200 jika ya menggunakannya jika tidak menjalankan kod ujian Google **** ****** dll

Dengan cara ini anda tidak perlu menyimpan apa-apa maklumat tentang pembekal (jika tidak, anda boleh mempunyai kotak teks di mana pengguna boleh masukkan had yang ditetapkan mereka untuk setiap pembekal tetapi saya rasa maklumat ini wuld menjadi sia-sia kerana mereka boleh mengubah dan ia akan bermakna lebih menyemak semula dan memeriksa ke hadapan sebelum membuat terjemahan) anda tidak perlu bimbang jika had lagi jadi tidak perlu untuk kerja cron untuk berjalan untuk memeriksa ini, beban pada pelayan bahawa daftar satu terjemahan kecil (kod yang anda berikan dalam Soalan Lazim) akan apa-apa.

Mudah-mudahan i menjelaskan yang ok supaya anda mendapat idea saya, i think semuanya boleh dilakukan hanya melalui cek yang kecil dan tanpa menyimpan apa-apa.

[Simon Lloyd]

Hanya pengumuman cepat - kita telah melaksanakan ciri ini.

Kita mahu untuk melepaskan berpuasa (sebagai BETA) kerana isu yang sama, disebabkan oleh had yang ditetapkan oleh pembekal terjemahan. Kami juga sedang mencari API lain yang boleh disokong oleh vBET :) saya menghantar anda satu atau dua (dalam sesuatu jawatan anda dihapuskan kerana pautan) yang anda boleh mendekati, jika anda mahu sukarelawan beta Saya :) lelaki

[vBET]

Saya menghantar anda satu atau dua (dalam sesuatu jawatan anda dihapuskan kerana pautan) yang anda boleh mendekati, jika anda mahu sukarelawan beta Saya :) lelaki

Mesej anda telah dipadamkan lembut, kerana kandungan iklan yang ditulis oleh orang lain, tetapi kita mempunyai akses kepada mesej ini dan kita berada di :)

Malah kita sudah menghantar e-mel soalan kepada salah satu daripada pembekal terjemahan kira-kira butiran bayaran. Beberapa orang-orang yang dibayar (walaupun ia digambarkan sebagai percuma tidak pada tahap API - perkara yang sama yang anda telah dengan Google, anda boleh menterjemahkan bebas oleh pelayar, tetapi bukan oleh API), tapi harga boleh bersaing, jadi ia masih baik (lebih banyak persaingan harga yang lebih baik).
Sesetengah kami telah menyiasat orang-orang terjemahan yang benar-benar luar API atau hanya kamus tempatan yang ditulis oleh pengguna sendiri (ini juga satu perkara dalam senarai TODO kita - membenarkan untuk mengubah suai dan meletakkan terjemahan sendiri) - Radek mempunyai bahagian ini.

Jadi kami sedang berusaha untuk memperbaiki vBET dan menjadikannya lebih murah dalam penggunaan sebagai :) mungkin

[vBET]

Kami secara berperingkat-peringkat yang terakhir tesing fungsi baru. Anda sudah boleh melihat perubahan description: http://www.vbenterprisetranslator.com/forum/vbet4-troubleshooting/413-faq-2.html # post8914 (lihat NOTA lepas)

[Simon Lloyd]

Terima kasih Michael, i membuat pos cepat Fosil Faq yang pastinya anda akan mempunyai untuk membuang kerana tidak tempat yang betul untuk itu :) jika anda ingin untuk menguji di papan aa hidup yang menyeru banyak terjemahan PM saya dan saya akan memberikan anda mengakses ke akar admincp dan forum, i juga akan meletakkan had terjemahan google bahawa saya telah ditubuhkan dan di perintah anda supaya anda boleh menguji :)

[vBET]

OK demikian. Beratur pembekal dilaksanakan dan ia akan dimasukkan dalam siaran 3.5.1 dan 4.4.3. vBET 3.5.1 akan dikeluarkan hari ini. vBET4.4.3 adalah masih dalam peringkat ujian. Siaran gerai akan BETA supaya semua orang boleh menguji dalam forum yang lebih besar bahawa ujian 1. Sila ambil perhatian bahawa kami telah menguji 3.5.1 pada salah satu forum sebenar kami. Masih kerana perubahan penting dalam peringkat BETA 1.

[Simon Lloyd]

Adakah ia perlu untuk menjadi satu tugas yang dijadualkan dan satu pembekal tertentu dimatikan selama satu jam pada satu-satu masa?, I membuat cadangan di sini Pekeliling memeriksa dan bertukar API untuk menyimpan aliran terjemahan di mana mungkin kita sentiasa boleh bermula di bahagian atas pembekal kami senarai dan membuat panggilan ujian (seperti yang anda berikan untuk menguji tindak balas Google dan sambutan Microsoft) jika ujian tindak balas panggilan 200 atau teks diterjemahkan kemudian digunakan oleh pembekal, jika sambutan tidak 200 atau teks ujian tidak diterjemahkan (menggunakan sama teks bagi setiap ujian dan REGEX untuk menyemak teks yang diterjemahkan) kemudian beralih kepada pembekal yang akan datang, tiap-tiap panggilan terjemahan kemudiannya boleh bermula di bahagian atas senarai dan bekerja ke bawah

Yang tidak mempunyai keputusan yang kosong akan yang baik kerana apabila kita mempunyai pulangan kosong thats bagaimana ia kekal, saya telah mempunyai ramai orang mengadu bahawa ini adalah kes dalam forum saya.

[vBET]

Ia tidak perlu menjadi cara ini, ia sekarang. Terima kasih atas nota anda. Masih - tidak. Ia tidak mempunyai rasa. Sila ambil perhatian bahawa meminta terjemahan luar adalah lebih perkara yang memakan masa di vBET keseluruhan (dan ia tidak terpulang kepada kita). Tiada rasa kepada beribu-ribu gila permintaan apabila kita sudah mencapai had. Ini akan increaser masa tindak balas, penggunaan CPU dan penggunaan memori juga (tujuan yang lebih dicipta).

Kami mendapati bahawa maklumat Google tentang TOS penyalahgunaan mungkin hilang selepas beberapa lama. Kita tidak tahu tetapi mungkin jika kita akan terus bertanya apabila kita sudah disekat, Google boleh menyekat lebih banyak masa. Mungkin tidak, tetapi masih strategi sebenar adalah jauh lebih baik untuk prestasi. Pada akhir anda telah menyemak pekeliling. Jika seseorang tidak boleh didapati, ia ditandakan sebagai tidak ada dan lain digunakan. Jika yang lain tidak boleh didapati, maka perkara yang sama berlaku. Kita tidak menyemak ia boleh didapati sekali lagi setiap permintaan tidak mempunyai rasa (ia boleh menjadi berjuta-juta pertanyaan sebelum ia akan didapati) hanya sekali setiap jam. Dan jika ia akan didapati ia akan saya menandakan kita akan kembali kepada salah satu pilihan - dan anda mempunyai bulatan di sini. Turut menguji setiap kali akan membuat had anda sampai lebih cepat atau kos yang lebih tinggi jika anda menggunakan terjemahan dibayar (ia masih mengira sebagai terjemahan).
Juga kami bersedia untuk mempunyai pembekal lain juga. Apabila kita akan menyokong lebih daripada 2 strategi itu akan menjadi pembunuh untuk pelayan anda. Bayangkan 5 panggilan ujian kepada pembekal yang berbeza dan kemudian terjemahan sebenar bagi setiap permintaan terjemahan. Terima kasih No. Untuk idea anda :) Kami benar-benar menghargai idea pengguna, kali ini kita akan kekal bersama penyelesaian sebenar.

Sila ambil perhatian bahawa anda boleh menukar berapa kerap vBET perlu menyemak ketersediaan pembekal. Kini ia adalah salah satu sejam, tetapi anda boleh reconfigure bahawa dalam CP Penyelaras -> Berjadual Tugas -> Petugas Berjadual Pengurus dan menetapkan ia sebagai contoh untuk setiap 10 minit 0 sama seperti tugas RSS Poster Robot lakukan sekarang.

[vBET]

Perubahan sedikit dibuat - kita akan menyemak ketersediaan pembekal tidak sekali sejam tetapi setiap 10 minit. Jika anda sudah dinaik taraf kepada vBET 3.5.1 sebelum mesej ini, sila hanya memuat turun pakej vBET sekali lagi dan memberi ulasan kepada gambar produk sekali lagi.

Perubahan itu dibuat kerana kita dapati di forum sebenar kita yang sering pembekal tidak tersedia untuk masa yang singkat. Kami akan menyiasat lebih untuk mencari lain penambahbaikan.

[Simon Lloyd]

Great guys kerja :), saya telah dinaik taraf ini tetapi akan memuat turun tetap terkini dan menggunakan itu, saya akan mewujudkan satu thread baru untuk maklum balas mengenai perkara ini.