Circolare controllo e commutazione di API per mantenere il flusso delle traduzioni

[Simon Lloyd]

Ho il mio limite di caratteri per google set a 100.000 perday così con le mie impostazioni "Usa sempre Google", "Usa API di Google V2", "Usa Detection Google" quando ho raggiungere questo limite e non ottenere risultati di pagamento di Google sarebbe possibile per le API libera poi iniziare a produrre risultati?

Così per esempio, io uso il mio limite predefinito di Google e Google non più restituisce un risultato per me (probabilmente restituendo un codice di errore come quelle nel codice di test di Google) quando viene restituito il risultato non sarebbe bene se bb riconosciuto automaticamente il codice di errore e quindi inviata richiesta ad un altro API come Microsoft (o qualsiasi altri supporta più tardi quel bb) in questo modo siamo certi di ottenere qualche risultato - per me questo sarebbe molto molto prezioso dato che non ci sono limiti anche con versioni a pagamento, ti permettono di estendere i vostri limiti di traduzioni.

ad esempio
Google imposta 100.000 Charcters al giorno > utilizzato > BB spostare all'API successivo nell'elenco > Microsoft 400 k ore o 4 M, quando il limite raggiunto bb controllo successivo API e precedenti per vedere se il limite è elevato o ha qualche assegno > spostare al prossimo API o torna a Google pagato quando ancora una volta raggiunto il limite > controllare il prossimo API.... ecc e così il controllo circolare dopo ricevo un codice di errore sarebbe portare avanti, così carino molto costante capacità di avere traduzioni.

[vBET]

Capisco la tua descrizione e il punto. Ora dobbiamo scoprire come supponga per lavoro tecnicamente.

Un problema che vedo qui è come si riconoscerà che abbiamo già limiti disponibili dopo quelli dove ha raggiunto prima.

Possiamo semplicemente ogni volta chiedere fornitore preferito e poi andare a quella successiva. Questo avrà un costo prestazioni - perché per ogni richiesta di pagina che richiede la traduzione, facemmo chiamata soccombente al fornitore preferito, al prossimo uno (quindi può essere diverse chiamate infruttuose quando bb supporterà più API).

Altra soluzione sarebbe per memorizzare le informazioni che il provider preferito non è disponibile e vanno direttamente al prossimo uno. Questo sarebbe molto più veloce, perché il controllo variabile locale è molto più veloce di in attesa di risposta dal server esterno. Questa volta abbiamo altra questione - non sappiamo quando il fornitore preferito è disponibile. Possiamo naturalmente fatto qualche operazione pianificata che vorrei chiedere semplice traduzione (breve) per esempio una volta al giorno/ora per controllarlo. Così in questa strategia dobbiamo decidere come spesso per impostazione predefinita tale compito supponiamo di lavorare. Naturalmente abbiamo controllassi solo quando alcuni provider viene contrassegnato come non disponibile.
Anche se vi segnalo i fornitori come non disponibile - cosa fare quando sappiamo che tutti i fornitori non disponibili - aggiungere alcune informazioni per l'utente finale o tradurre solo ciò che è nella cache e il resto come originale, senza qualsiasi ulteriore info su mancanza temporanea di fornitori di traduzione.

Non importa quale modo sarà fatto, Google sarà trattata come una API (v1 o v2 a seconda della configurazione) - non non c'è alcun senso per dividere, perché Google v1 sarà chiuso molto presto.

Un'altra cosa è di consentire a configurare separatamente coda di fornitori per ogni coppia di lingua. In questo momento bb già permette di configurare i provider per ogni coppia di lingua di traduzione. Penso che possiamo cambiare e da un valore di valori separati da virgola (CSV). In questo modo sapremo per ogni coppia di linguaggio quali provider supportano questa traduzione e quali sono le preferenze di ordine (ordine solo sulla lista CSV).

NOTA BENE: Ciò avrà qualche impatto sulle prestazioni in ogni caso. Invece di creare un solo oggetto per traduzione dovremo creare array di tali oggetti e oggetto di avvolgimento addizionali (per renderlo trasparente per le altre parti di codice e meno bug incline). Naturalmente non creiamo oggetti per i provider che conosciamo non sono disponibili in questo momento.
Soluzione per questo sarebbe per riconfigurare per migliorare le prestazioni e rimuovere la coda di fornitori - proprio come lo è ora - un provider al paio di lingua.
Questo non dovrebbe essere costoso per le prestazioni, ma ancora qualche ulteriore logica e memoria consumo.

Dica quale soluzione è preferito.

[vBET]

E una soluzione più potenziale. Se ci sarà marchio API intero come non disponibili e controllare che da attività pianificata è disponibile ora, quindi non abbiamo fare la coda dei fornitori. Possiamo farlo questo modo - sempre viene creato un solo oggetto di traduttore (migliore utilizzo della memoria) e in una sola richiesta chiediamo per traduzione un solo provider (meglio CPU). Se esso non sarà disponibile, quindi esso verrà contrassegnata come non disponibile e risultati sarà vuoti (peggiori affidabilità). Ma solo prima, perché la prossima volta useremo un altro provider dalla coda. E nel caso se non è disponibile alcun provider poi traduttore fittizio saranno utilizzati - restituire valori stessi (ma non cache) quindi alcune parti saranno non tradotto ma la pagina non avrà parti vuote come ora quando provider non è disponibile.

[vBET]

Annuncio appena rapido - noi stiamo già attuando questa caratteristica.

[Simon Lloyd]

Annuncio appena rapido - noi stiamo già attuando questa caratteristica.

Ti ho mandato una o due (in un post che è stato eliminato a causa dei collegamenti) che poteva avvicinarsi, se si desidera una versione beta di volontari sono tuo uomo

[vBET]

Ti ho mandato una o due (in un post che è stato eliminato a causa dei collegamenti) che poteva avvicinarsi, se si desidera una versione beta di volontari sono tuo uomo

Il tuo messaggio è stato eliminato dolcemente, perché il suo contenuto è stato annuncio scritto da qualcun altro, ma abbiamo accesso a questo messaggio e siamo su di esso

Inviamo anche già domanda e-mail a uno di questi fornitori di traduzioni sui dettagli di pagamento. Alcuni di questi sono pagati (anche quando è descritto come libero non è su API livello - stessa cosa avete con Google è possibile tradurre gratis dal browser, ma non da API), ma i prezzi possono essere competitivi, quindi è ancora buono (più concorrenza i migliori prezzi).
Alcuni abbiamo indaghiamo sono quelle davvero esterni traduzioni API o dizionari locali appena scritti dai propri utenti (anche questa è una cosa sulla nostra lista TODO - permette di modificare e mettere le proprie traduzioni) - Radek ha questa parte.

[Simon Lloyd]

Per inviare la traduzione di controllo per vedere se si preferisce il fornitore è disponibile, in modo che ci ha dato il codice per controllare se google o MS risponde, quindi al momento della chiamata per traduzione prova googleapi (nome del mio file di test con il codice di test) se la traduzione è vero utilizzare preffered, se la traduzione è flase o codice non è 200 poi provare next provider nell'elenco e loro api del test prima di utilizzare i miei pensieri erano.

Si potrebbe avere un controllo listbox dove l'utente può elencare ogni provider uno per ogni riga in ordine di preferenza (in questo modo quando si aggiunge il supporto per altre API, l'utente possono solo aggiungere alla lista), così la mia lista potrebbe assomigliare a questa:
Microsoft
MyTranslator
Google
YourTranslator
AnOtherTranslator

Supponendo che i nomi daft entrai erano fornitori reali, su chiamata per codice di test di traduzione MS correrebbe, se uso risposta 200 MS se non eseguire codice di test MyTranslator, controlla la risposta per 200 se sì utilizzarlo se non eseguita il codice di test Google Week ecc

In questo modo non hai mai memorizzare tutte le informazioni sul provider (altrimenti avresti potuto scatole dove gli utenti potevano entrare loro limiti di impostare per ogni provider, ma penso che questa informazione difforme essere inutile, come si potrebbe cambiare e vorrebbe dire più controllo indietro e controllo avanti prima di fare una traduzione testo) non avreste mai preoccuparsi se limiti erano disponibili ancora così bisogno di un cron non lavoro da eseguire per controllare questi, il carico sul server per quel controllo traduzione piccolo uno (il codice che hai fornito in FAQ) non sarebbe nulla.

Speriamo che ho spiegato che ok così si ottiene la mia idea, penso potrebbe essere fatto tutto giusto da quel piccolo controllo e senza archiviare nulla.

[vBET]

Siamo nelle ultime fasi di tesing nuove funzionalità. Si può già vedere descrizione modificati: http://www.vbenterprisetranslator.co....html#post8914 (vedi ultimo NOTA)

[Simon Lloyd]

Michael grazie, ho fatto un post rapido in taht Faq che senza dubbio si dovrà rimuovere perché non è il posto giusto per esso Se vuoi testare su un bordo dal vivo che chiama molte traduzioni PM me e io darò consente di accedere alla radice admincp e forum, anche io porrò limite di traduzione di google che ho impostato su e giù al tuo comando per eseguire test

[vBET]

OK, quindi. Coda di fornitori viene implementato e saranno incluse nelle release 3.5.1 e 4.4.3. 3.5.1 bb uscirà oggi. vBET4.4.3 è ancora in fase di test. Booth comunicati saranno BETA quindi tutti possono verificare nei forum più grandi che prova uno. Si prega di notare che stiamo già sperimentando 3.5.1 su uno dei nostri forum vero e proprio. Ancora a causa di cambiamenti importanti è in fase BETA prima.