Circular Überprüfung und Vermittlung von APIs zu fließen Übersetzungen halten

[Simon Lloyd]

Ich habe meine Zeichen für google gesetzt zu 100.000 perday so mit meinen Einstellungen "Always Use Google", "Use Google API V2", "Use Google Detection", wenn ich diese Grenze und erreichen nicht mehr zu bekommen ergibt sich aus bezahlten Google wäre es möglich, kostenlos APIs starten Sie dann zu Ergebnissen führen?

Also zum Beispiel, ich benutze mein Google voreingestellten Limit und Google nicht mehr ein Ergebnis zurückgibt, für mich (wahrscheinlich einen Fehler-Code wie in den Google-Testcode zurückgeben) Wenn das Ergebnis nicht zurückgegeben es wäre gut, wenn vBET automatisch, den Fehlercode anerkannt und dann die Anforderung an eine andere API wie Microsoft gesendet (oder alle anderen, dass vBET unterstützt die später) so man versichert uns immer ein Ergebnis - für mich wäre dies sehr wertvoll Angesichts der Tatsache, dass gibt es Grenzen auch mit kostenpflichtigen Versionen, können es Sie Ihre Übersetzungen-Grenzen zu erweitern.

zB
Google festlegen 100.000 Zeichen pro Tag > aufgebraucht > vBET Verschieben zum nächsten API in Liste > Microsoft 400 k pro Stunde oder 4 M, sobald der Grenzwert vBET Kontrollkästchen nächste API erreicht, und zurück, um zu sehen wenn Limit aufgehoben ist oder einige Zulage hat > entweder Verschieben zum nächsten API oder zurück zur Google bezahlt, wenn wieder erreicht > Überprüfen der nächsten API.... usw. und so die kreisförmige suchen nach dem Empfang ein Fehler-Codes weitermachen würde, so ziemlich viel Konstante Fähigkeit, Übersetzungen zu haben.

[vBET]

Ich verstehe Ihre Beschreibung und Ihren Standpunkt. Nun müssen wir herausfinden, wie es technisch funktionieren nehme.

Eine Frage, die ich hier sehe, ist, wie wir erkennen, dass wir bereits über Grenzen verfügbar, nachdem solche, bei denen vor erreicht.

Wir können einfach jedes Mal bitten, bevorzugter Anbieter und dann gehen Sie zum nächsten. Das kostet Leistung-, da für jede Anforderung zur Seite die Übersetzung erfordert, werden wir fehlgeschlagenen Aufruf bevorzugter Anbieter, dann zur nächsten ein (so dass es mehrere erfolglose Aufrufe bei vBET weitere APIs unterstützt werden kann).

Andere Lösung wäre es, Informationen, die bevorzugten Anbieter nicht verfügbar ist speichern und direkt zu nächsten. Dies wäre sehr viel schneller, weil die Überprüfung lokale Variable ist viel schneller als Warten auf eine Antwort von einem externen Server. Dieses Mal haben wir andere Frage - wir wissen nicht, wann bevorzugten Anbieter verfügbar ist. Wir können natürlich haben einige geplante Aufgabe, die für einfache (kurze) Übersetzung zum Beispiel fragen würde einmal pro Stunde / Tag, um es zu überprüfen. So in dieser Strategie müssen wir uns entscheiden, wie oft standardmäßig solche Aufgabe zu arbeiten nehme. Natürlich würden wir prüfen es nur, wenn einige Anbieter als nicht verfügbar markiert ist.
Auch wenn wir markieren Anbieter als nicht verfügbar - was tun, wenn wir, dass alle Anbieter nicht verfügbar sind, wissen - fügen Sie einige Informationen für Endverbraucher oder einfach nur übersetzen, was im Cache und der Rest als original, ohne zusätzliche Informationen über die vorübergehende Fehlen einer Übersetzung Anbieter .

Egal, welchen Weg es gemacht wird, wird Google als behandelt werden eine API (V1 oder V2 je nach Konfiguration) - es macht keinen Sinn zu spalten, weil Google v1 sehr bald geschlossen werden.

Eine andere Sache ist Anbieter-Warteschlange für jede Sprachkombination separat konfigurieren. Im Moment kann vBET bereits Übersetzungsanbieter für jedes Sprachpaar konfigurieren. Ich denke, dass wir es von einem Wert in kommagetrennten Werten (CSV) ändern können. Auf diese Weise, die wir für jedes Sprachenpaar wissen, welche Anbieter unterstützen diese Übersetzung und welche Bestellung Einstellungen (nur Reihenfolge auf CSV-Liste).

BITTE BEACHTEN SIE: dies wird einige Auswirkungen auf die Leistung sowieso. Anstatt ein Objekt für die Übersetzung müssen wir Anordnung solcher Objekte und zusätzliche Verpackung Objekt (transparent zu machen für andere Teile des Codes und weniger Bugs anfällig) zu schaffen. Natürlich werden wir keine Objekte für die Anbieter wissen wir, sind in diesem Moment nicht verfügbar.
Lösung hierfür wäre neu zu konfigurieren, um die Leistung und entfernen Anbieter Warteschlange - wie es jetzt ist - ein Anbieter pro Sprachrichtung.
Dies sollte nicht teuer für die Leistung, aber immer noch einige zusätzliche Logik-und Speicher Verbrauch.

Bitte teilen Sie, welche Lösung bevorzugt wird.

[vBET]

Und noch eine mögliche Lösung. Wenn wir ganze API als nicht verfügbar markiert wird und überprüfen Sie es durch geplante Aufgabe ist es ab sofort, dann haben wir nicht in die Warteschlange der Anbieter machen. Wir können es auf diese Weise - ist immer nur ein Übersetzer Objekt erstellt (besser Speichernutzung) und in einer Anfrage für die Übersetzung bitten nur ein Anbieter (besser CPU). Wenn es nicht verfügbar ist, dann wird es als nicht verfügbar und die Ergebnisse gekennzeichnet sein wird leer sein (worst Zuverlässigkeit). Aber nur erste, weil beim nächsten Mal werden wir einen anderen Anbieter aus der Warteschlange. Und für den Fall, wenn kein Anbieter verfügbar ist, dann Dummy-Übersetzer verwendet werden - wieder dieselben Werte (aber nicht zwischenspeichern) so einige Teile nicht übersetzt werden, aber Seite wird nicht leer Teile wie jetzt, wenn Anbieter nicht verfügbar ist.

[vBET]

Nur schnelle Ankündigung - wir sind bereits mit der Durchführung dieser Funktion.

[Simon Lloyd]

Meine Gedanken waren, um den Scheck Übersetzung senden Sie zunächst, ob bevorzugten Anbieter verfügbar ist, so dass Sie gaben uns Code zu überprüfen, ob Google oder MS reagiert, so zum Zeitpunkt der Aufforderung zur Übersetzung Test googleapi (Name von meinem Test-Datei mit Ihrem Test-Code ) wenn die Übersetzung stimmt verwenden preffered ist, wenn die Übersetzung ist flase oder Code nicht 200 dann versuchen, beim nächsten Anbieter in der Liste und führen ihre api-Test vor der Verwendung.

Sie können ein Listenfeld, wo der Benutzer jeden Anbieter eine pro Zeile in der Reihenfolge ihrer Präferenz kann Liste haben (dies erlaubt, wenn Sie Unterstützung hinzufügen für andere APIs kann der Anwender einfach fügen Sie sie der Liste), so meine Liste könnte wie folgt aussehen:
Microsoft
MyTranslator
Google
YourTranslator
AnOtherTranslator

Vorausgesetzt, die daft Namen i getreten waren echte Anbieter, auf Abruf für die Übersetzung MS Testcode laufen würde, wenn Antwort 200 verwenden MS wenn nicht MyTranslator Test-Code auszuführen, überprüfen Reaktion für 200 wenn ja benutzen, wenn nicht ausgeführt Google Testcode **** ****** etc

Auf diese Weise müssen Sie nie irgendwelche Informationen über Anbieter (sonst könnten Sie Textfelder, wo Nutzer ihre Grenzen setzen für jeden Anbieter könnten eingeben müssen, aber ich denke diese Information wuld nutzlos, wie sie es ändern könnte und es würde bedeuten, mehr Kontrolle zurück und Prüfung speichern nach vorne, bevor sie eine Übersetzung) würden Sie sich niemals Gedanken machen, wenn Grenzen wurden wieder zur Verfügung, so dass keine Notwendigkeit für einen cron-Job ausführen, um diese zu überprüfen, wird die Last auf dem Server für diesen einen kleinen Übersetzung zu überprüfen (Code, den Sie in FAQ vorgesehen) nichts.

Hoffentlich habe ich das in Ordnung erklärt, so dass Sie meine Idee zu bekommen, ich glaube, es könnte nur durch die kleine überprüfen und ohne Speicherung etwas getan werden.

[Simon Lloyd]

Nur schnelle Ankündigung - wir sind bereits mit der Durchführung dieser Funktion.

Ich habe Ihnen eine oder zwei (in einem Post, den Sie wegen der Links gelöscht), dass man Ansatz, wenn Sie eine Beta-Freiwilligen wollen, ich bin dein Mann

[vBET]

Ich habe Ihnen eine oder zwei (in einem Post, den Sie wegen der Links gelöscht), dass man Ansatz, wenn Sie eine Beta-Freiwilligen wollen, ich bin dein Mann

Ihre Nachricht wurde weich gelöscht, weil sein Inhalt wurde Anzeige von jemand anderem geschrieben, aber wir haben Zugriff auf diese Nachricht und wir werden auf sie

Wir haben sogar schon Frage abschicken E-Mail an eine dieser Übersetzungen Anbieter zu Zahlung Details. Einige von denen bezahlt werden (auch wenn es als freie beschrieben ist es nicht auf API-Ebene - das gleiche, was Sie mit Google übersetzen Sie kostenlos Browser kann, aber nicht durch API), aber die Preise konkurrenzfähig sein können, so ist es immer noch gut (mehr Wettbewerb bessere Preise).
Einige haben wir untersuchen, sind die wirklich externe Übersetzungen API oder einfach nur lokale Wörterbücher eigenen Benutzer (dies ist auch eine Sache auf unserer ToDo-Liste - erlauben zu ändern und stellen eigene Übersetzungen) - geschrieben Radek hat diesen Teil.

[vBET]

Wir sind in den letzten Phasen der Tesing neue Funktionalität. Sie sehen bereits geänderten Beschreibung: http://www.vbenterprisetranslator.co....html#post8914 (siehe letzte HINWEIS)

[Simon Lloyd]

Thanks Michael, ich habe eine kurze Nachricht in Taht Faq, die zweifellos erforderlich wird, entfernen, weil es ist nicht der richtige Ort für sie Wenn Sie möchten, zu testen auf ein ein live-Board, die viele Übersetzungen PM ruft mich und ich Ihnen Zugang zu Admincp und Forum Wurzel gebe, werde auch ich Google-Übersetzung-Grenze, die ich oben und unten auf Ihre Befehl festgelegt haben, so können Sie testen

[vBET]

OK, so. Anbieter-Warteschlange wird implementiert, und es wird in Version 3.5.1 und 4.4.3 aufgenommen werden. vBET 3.5.1 wird heute veröffentlicht. vBET4.4.3 ist noch in der Testphase. Stand-Versionen werden BETA, so dass jeder in den größeren Foren geprüft werden kann, die man zu testen. Bitte beachten Sie, dass wir bereits 3.5.1 auf einem unserer realen Foren testen. Noch aufgrund der wichtige Änderungen ist es zunächst im BETA-Stadium.