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 API. Après avoir lu les conditions de Service, nous avons ne trouvé aucune limitation contre elle en soutenant vBET (encore nous envoyez par question, juste certes).

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 ne sait pas encore. Nous commençons seulement expérimenter avec elle, aussi nous encore attendons pour la réponse de l'équipe de Apertium, afin que nous ne pouvons dire encore pour beaucoup. Encore, nous voulons que vous sachiez que nous aimerions soutenir dans vBET APIs autant que possible pour vous donner plus de choix et de traductions en cas de limites définie 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 de vBET temps d'attente - 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 la mise en cache vBET traductions obtient toujours immédiatement, pour certains forums cela il peut être pas acceptable pour la page afin de charger 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 fait seulement quelques essais (déjà en vBET le code) sur le forum de petit test.

Aussi nous voyons déjà que nous aurons à ajouter de nouvelles fonctionnalités de configuration dans vBET -comme la possibilité de définir les priorités de fournisseurs à l'échelle mondiale. Maintenant c'est faisable en éditant beaucoup de fichiers de configuration, et nous voyons qu'il n'est pas la voie. Nous ne prédisent que gros changements seront faits dans le marché de la traduction, mais nous adopterons

[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 vBET prend en charge les 30 paires de langues de Apertium (il y a plus mais pas commun pour les autres moteurs de traduction). Nous voyons déjà cet ajout Apertium à vBET est une bonne idée même si la performance n'est pas la meilleure (après tout nous avons cache net time, 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.