Apertium - une autre traduction API sera soutenue en VB Enterprise ?

[vBET]

Bonjour

Nous voulons simplement vous assurer que nous cherchons de nouvelles possibilités pour les traductions. En ce moment, nous travaillons à l'appui Apertium traduction de l'API. Après avoir lu les Conditions De Service nous n'avons trouvé aucune limitation à l'encontre de la soutenir dans vBET (toujours nous envoyer un email avec la question, juste pour être sûr).

L' API est libre maintenant (nous ne savons pas sera elle être manoeuvré à payé un) il supporte beaucoup de paires de langues et Il est encore en version bêta. En ce moment nous n'ont aucune idée quelles limites qu'ils ont (nous savons que certaines limites sont définies.). Aussi la qualité de la traduction n'est pas encore connu. Nous venons de commencer à expérimenter avec elle, aussi, nous sommes toujours en attente de réponse de Apertium de l'équipe, donc on ne peut pas dire encore beaucoup. Et encore, nous voulons que vous sachiez que nous voudrions soutenir dans vBET que de nombreuses Api que possible pour vous donner plus de choix et plus de traductions dans le cas des limites fixées dans une API.

Toute nouvelle importante sur l'intégration de Apertium est publié ici.

[vBET]

Quelques infos après les premiers tests.

Nous avons déjà il travaillant dans vBET (vBET est facile d'ajouter la nouvelle traduction API).
Performance de l'API de traduction Apertium en ce moment est pauvre. Environ 300 millisecondes sont réponse courte demande quelle est OK. Demandes encore longs sont une réponse même 13 secondes (heure de l'intervention différents - dans nos quelques tests entre 5-13 secondes). Bien entendu, nous pouvons faire rien dans ce domaine : il s'agit pour VB Enterprise, temps d'attente - en attente de réponse. Nous ne pouvons dire does performances seront améliorées ici : il s'agit de 3 rd party service. Ce n'est pas question cruciale parce qu'après que la mise en cache de vBET obtient immédiatement traductions, toujours pour certains forums en cela qu'il peut être pas acceptable pour page à charge 20 secondes - même si c'est uniquement pour la première traduction. D'autre part - qui veut ont une traduction rapide ont des options en API rémunéré, en manque d'autres API libre (Microsoft seront encore libre uniquement pour les caractères de la limite des 2 millions par mois-, mais il sera toujours libre).

Nous testerons il bien sur le forum de test et de la réelle. En ce moment, nous avons fait seulement quelques essais (déjà dans le code de vBET) sur le forum de petit test.

[vBET]

Nous avons commencé déjà tests Apertium traduction API sur notre forum réelle. Nous définissons les billes, donc après un certain temps, nous serons capables de dire plus sur le rendement réel.

En ce moment VB Enterprise prend en charge les 30 paires de langues de Apertium (il y a plus mais pas commun pour les autres moteurs de traduction). Déjà, nous voyons qu'ajoutant Apertium vBET est bonne idée, même si la performance n'est pas la meilleure (après tout nous avons cache net tellement de temps que c'est immédiat). Nous la voyons dans les journaux - où les autres limites a été atteint maintenant, nous sommes toujours en mesure de faire des traductions grâce à Apertium. En ce moment les billes nous voyons que surtout ceux qui sont des traductions de l'anglais (la plupart des contenus ici sont en anglais) à: es, ca, gl de cours est plus supporté.

Pour voir la liste complète de langage pris en charge paires, veuillez consulter ici : http://API.Apertium.org/JSON/listPairs
Ceux sont les paires de langues qui ne sera pas assuré (au moins maintenant) :

oc => es
es => ca_valencia
oc_aran => ca
an => es
fr => eo
nb => nn_a
ca => en_US
ca => oc_aran
nn => nb
ca => oc
oc_aran => es
es => eo
oc => ca
br => fr
en => eo
ca => eo
es => oc_aran
nn => nn_a
es => pt_BR
es => oc
es => an
eo => en
nn_a => nn
es => en_US
nb => nn

Ne nous soutiendra pas il maintenant, parce qu'il n'y a aucun soutien tout-à-all et autres moteurs n'ont pas de ces langues. Nous allons toujours vérifier sont certains codes ne peut pas être juste mappées dans l'affaire si même langue avec les autres codes est utilisé dans les autre API de traduction. De toute façon dans la première version soutenant Apertium nous soutiendra pas toutes les paires.

Nous voulons (et sont prêts à faire maintenant) pour utiliser Apertium pour ces paires de langues :

bg => mk
ca => en
ca => es
ca => fr
ca => pt
cy => en
da => sv
en => ca
en => es
en => gl
es => ca
es => en
es => gl
es => pt
es => ro
eu => es
fr => cs
fr => es
gl => en
gl => es
gl => pt
is => en
it => ca
mk => bg
mk => en
pt => ca
pt => es
pt => gl
ro => es
sv => da

Il faudrait 30 des personnes. Si nous manquer quelque chose veuillez nous le faire savoir. Aussi si vous obtiendrez des informations sur les nouvelles paires de langage pris en charge, puis aussi veuillez nous contacter.

[Simon Lloyd]

Grand travail Michael , les clés API plus nous pouvons entrer pour différentes API le mieux, même s'ils sont payés ones, vous pourrait introduire des cases à cocher pour les utilisateurs de pouvoir activer/désactiver celles versées api qu'ils souhaitent utiliser - agréable de voir cette élaboration de toute façon !

[vBET]

Oui, nous avons déjà considéré pour donner la possibilité d'activer/désactiver certaines API sans modifications dans les fichiers de configuration. En ce moment, je pense qu'il sera simplement reconnu par clé API. Si la clé API n'est pas utilisé pour certaines API de traduction l'API n'est pas utilisé. Il n'est pas implémentée pourtant - seule idée maintenant.

[vBET]

Parce que nous allons ajouter Apertium soutien dans la prochaine version, il y aura un changement de licence petit - Apertium est également listé comme fournisseur de traduction.