Circulaire de vérification et de commutation des API pour maintenir des flux de traductions

[Simon Lloyd]

J'ai ma limite de caractères pour google définie sur 100 000 par jour, donc avec mes paramètres « Toujours utiliser Google », « Utilisation Google API V2 », « Utilisation Google détection » lorsque j'ai atteint cette limite et ne plus obtenir des résultats de Google rémunéré serait-il possible gratuitement API puis démarrez produisant des résultats ?

Ainsi par exemple, j'utilise mon seuil préétabli de Google et Google n'est plus retourne un résultat pour moi (probablement retournant un code d'erreur comme celles de votre code de test de Google) lorsque le résultat n'est pas retourné il serait bon que VB Enterprise reconnu automatiquement le code d'erreur et puis envoyé demande à un autre API comme Microsoft (ou toute autre que VB Enterprise supporte plus tard) de cette façon, nous sommes assurés d'obtenir certains résultats - pour moi, ce serait très très précieux étant donné qu'il y a des limites même avec les versions rémunérées, il vous permettrait d'étendre les limites de vos traductions.

p. ex.
Google définie 100 000 caractères par jour > utilisés jusqu'à > vBET passer à la prochaine API dans la liste > Microsoft 400 k par heure ou 4 M lorsque la limite atteinte vBET cocher prochaine API et avant de voir si la limite est levé ou a une provision > soit déplacer vers la prochaine API ou retour à Google payé lorsque limite atteinte à nouveau > vérifier la prochaine API.... etc. et donc la vérification circulaire après alimenté un code d'erreur transporterait, pretty tellement beaucoup constante de la capacité d'avoir des traductions.

[vBET]

Je comprends votre description et votre point de vue. Nous avons maintenant découvrir comment il suppose de travailler sur le plan technique.

Une question, que je vois ici, c'est comment nous reconnaîtrons que nous avons déjà les limites disponibles après celles où atteint avant.

Nous pouvons simplement chaque fois demander fournisseur préféré et puis aller vers le suivant. Ce coût performance - car pour chaque demande de page qui exige la traduction, qui nous fera infructueux appel au fournisseur préféré, puis au prochain un (donc il peut être plusieurs appels infructueuses lorsque vBET soutiendra plus API).

Autre solution consisterait à stocker les informations de ce fournisseur préféré n'est pas disponible et aller directement au prochaine une. Ce serait beaucoup plus rapidement, parce que la variable locale est beaucoup plus rapide que d'attendre de réponse du serveur externe de la vérification. Cette fois nous avons autre question - nous ne savons pas quand le fournisseur préféré est disponible. Nous pouvons évidemment fait quelque tâche planifiée qui demandait simple traduction (courte) par exemple une fois par heure par jour pour le vérifier. Donc dans cette stratégie, nous avons de décider combien de fois par défaut telle tâche suppose de travailler. Bien entendu nous il vérifie uniquement lorsque certains fournisseur est marqué comme non disponible.
Également si nous marquons fournisseurs comme indisponible - ce qu'il faut faire lorsque nous savons que tous les fournisseurs ne sont pas disponibles - ajouter des informations pour l'utilisateur final ou juste traduire ce qui est dans le cache et le reste en originales, sans n'importe quelle information supplémentaire sur l'absence temporaire de fournisseurs de traduction.

N'importe quelle façon ce sera fait, Google sera traitée comme une API (v1 ou v2 selon configuration) - il n'y a aucun sens de split, parce que v1 de Google sera fermé très bientôt.

Une autre chose est de permettre de configurer la file d'attente de fournisseurs pour chaque paire de langue séparément. En ce moment VB Enterprise permet déjà de configurer le fournisseur de traduction pour chaque paire de langue. Je pense que nous pouvons changer il d'une valeur de valeurs séparées par des virgules (CSV). De cette façon, nous saurons pour chaque paire de langue permettant aux fournisseurs de soutenir cette traduction et quels sont les préférences de l'ordre (ordre juste sur la liste CSV).

S'IL VOUS PLAÎT NOTE: Cela aura un impact sur les performances de toute façon. Au lieu de créer un objet pour la traduction, nous aurons créer le tableau de ces objets et l'objet emballage supplémentaires (pour le rendre transparent pour d'autres parties du code et moins de bogues sujettes). Bien entendu nous allons créer pas les objets pour nous savons les fournisseurs ne sont pas disponibles en ce moment.
Solution pour cela serait de reconfigurer pour de meilleures performances et supprimer la file d'attente de fournisseurs - tout comme il est maintenant - un seul fournisseur par paire de langue.
Cela ne devrait pas être cher pour les performances, mais encore quelques autre consommation logique et de la mémoire.

Veuillez indiquer quelle solution est préférable.

[vBET]

Et une solution plus. Si nous marquera toute API comme non disponibles et vérifier par tâche planifiée est elle disponible maintenant, alors nous ne pas faire la file d'attente des fournisseurs. Nous pouvons le faire cette façon - toujours est créée un seul objet de traducteur (meilleure utilisation de la mémoire) et dans une demande, nous demandons à la traduction qu'un seul fournisseur (meilleure CPU). Si il sera pas disponible, alors il sera marqué comme non disponibles et les résultats seront vides (pire fiabilité). Mais un seul premier, parce que la prochaine fois, nous allons utiliser un autre fournisseur de la file d'attente. Et dans l'affaire si aucun fournisseur n'est disponible, puis traducteur factice sera utilisé - renvoyer les mêmes valeurs (mais ne pas en cache il) donc certaines parties seront traduits pas mais la page n'aura pas de pièces vides comme maintenant où fournisseur n'est pas disponible.

[vBET]

Annonce juste rapide - nous implémentons déjà cette fonctionnalité.

[Simon Lloyd]

Mes pensées sont à envoyer à la traduction de vérifier d'abord pour voir si préféré fournisseur est disponible, et vous nous avez donné code pour vérifier si google ou MS répond, donc au moment de l'appel pour traduction test googleapi (nom de mon fichier de test avec votre code de test) si la traduction est vrai utiliser préférée, si la traduction est flase ou code n'est pas 200 puis essayez prochain fournisseur dans la liste et effectuer leur test api avant de l'utiliser.

Vous pourriez avoir un contrôle listbox où l'utilisateur peut répertorier chaque fournisseur, un par ligne par ordre de préférence (cela permet lorsque vous ajoutez de soutien pour les autres API, l'utilisateur peut juste ajouter à la liste), donc ma liste pourrait ressembler à ceci :
Microsoft
MyTranslator
Google
YourTranslator
AnOtherTranslator

En supposant que les noms daft je suis entré étaient prestataires réels, sur appel de code de test de traduction MS irait, si l'utilisation de réponse 200 MS si non exécution MyTranslator code de test, vérifiez la réponse pour 200 si oui l'utiliser, et sinon exécuter le code de test de Google ********** etc.

Cette façon vous n'avez jamais à stocker les informations sur les fournisseurs (sinon vous pourriez avoir texte cases où les utilisateurs pouvaient entrer leurs limites définies pour chaque fournisseur mais je pense que cette information arriver être inutile, car ils pourraient changer et cela signifie plus de vérification de retour et de vérifier avec impatience devant faire une traduction) vous auriez jamais à vous inquiéter si les limites étaient disponibles à nouveau si aucun besoin d'un cron ne job à exécuter pour vérifier ces, la charge serveur pour cette un vérification petit (le code que vous avez fourni dans la FAQ) ne serait rien.

J'espère que j'ai expliqué que sur ok afin de vous faire mon idée, je pense qu'il pourrait tout faire juste par cette petite cocher et sans stockage quoi que ce soit.

[Simon Lloyd]

Annonce juste rapide - nous implémentons déjà cette fonctionnalité.

Je vous a envoyé un ou deux (dans un poste, que vous avez supprimé en raison des liens) si vous voulez une version bêta bénévole je suis votre homme, vous pourrait approcher

[vBET]

Je vous a envoyé un ou deux (dans un poste, que vous avez supprimé en raison des liens) si vous voulez une version bêta bénévole je suis votre homme, vous pourrait approcher

Votre message a été supprimé doucement, car son contenu a été écrite par quelqu'un d'autre, de publicité, mais nous avons accès à ce message et nous sommes sur elle

Nous envoyons même déjà Courriel de la question à l'un de ces fournisseurs de traductions sur les détails de paiement. Certaines personnes sont payés (même quand il est décrit comme étant libre, ce n'est pas sur les API niveau - même chose vous avez avec Google vous pouvez traduire gratuitement par navigateur, mais pas par l'API), mais les prix peuvent être compétitifs, il est toujours bon (prix meilleurs à plus de concurrence).
Certains nous avons étudier sont les traductions vraiment externes API ou les dictionnaires juste locales écrits par propres utilisateurs (c'est aussi une chose sur notre liste TODO - permettent de modifier et de mettre les traductions propres) - Radek a cette partie.

[vBET]

Nous sommes dans les derniers stades de tesing de nouvelles fonctionnalités. Vous pouvez déjà voir description modifiée : http://www.vbenterprisetranslator.co....html # post8914 (voir dernier REMARQUE)

[Simon Lloyd]

Merci Michael, j'ai fait un post rapide en récupération Faq qui ne fait aucun doute que vous deviez supprimer parce que ce n'est pas le bon endroit pour elle Si vous désirez tester sur une une Commission vivant qui appelle de nombreuses traductions PM moi et je vais vous donner accès à racine admincp et forum, je mettrai également limite de traduction de google que j'ai fixé monte et descend à votre commande donc vous pouvez tester

[vBET]

OK, donc. File d'attente de fournisseurs est mis en œuvre, et il sera inclus dans les Communiqués 3.5.1 et 4.4.3. vBET 3.5.1 sera publié aujourd'hui. vBET4.4.3 est encore en phase de test. Booth communiqués seront BETA afin que tout le monde peut le tester dans les forums plus gros qu'un test. Veuillez noter que nous expérimentons déjà 3.5.1 sur un de nos forums real. Toujours en raison de changements importants c'est en version bêta d'abord.