Notes de version Easyling - août 2015

L’été s’est terminé (même si la météo semble être en désaccord pour l’instant), tout comme nous concluons un autre segment du développement d’Easyling. Ce mois-ci a également été riche en nouvelles fonctionnalités, telles que la possibilité de définir des alarmes pour vous avertir d’une augmentation de l’utilisation des ressources, la possibilité de définir des codes d’état HTTP dans la surcharge du contenu de la page, la capacité prototype d’utiliser plusieurs caches nommés pour différents modes de proxy, et ce qui équivaut à l’installation d’un moteur à distorsion dans notre traducteur JavaScript. Découvrez les détails après le saut !

Alerte d’utilisation accrue

Easyling a toujours suivi la fréquence des chargements de pages via celui-ci, mais les statistiques étaient mises à jour une fois par jour. Nous avons maintenant introduit un système d’alerte en temps réel, dans lequel vous pouvez définir des limites personnalisées par projet afin de recevoir une notification par e-mail si les pages vues/seconde, les nouveaux mots/seconde ou les mots traduits/seconde dépassent ce seuil. Cela peut être utilisé pour éviter l’épuisement de vos portefeuilles, ou pour alerter le client d’un nombre anormalement élevé de requêtes. [caption id=“attachment_2451” align=“aligncenter” width=“954”] Une utilisation accrue des ressources peut désormais déclencher une alerte par e-mail[/caption]

Codes d’état HTTP personnalisés dans les remplacements de contenu de page

Cela fait un moment que nous avons mis en place la possibilité d’ajouter des remplacements de page personnalisés, qui créent de nouvelles pages virtuelles dans le proxy ou remplacent des pages existantes. Nous avons maintenant étendu cette fonctionnalité avec la possibilité de définir des codes d’état HTTP personnalisés et en facilitant l’utilisation d’URL avec des accents. Les codes d’état personnalisés signifient que vous pouvez désormais définir facilement des redirections personnalisées en spécifiant un statut 301/302 (signifiant « Déplacé de façon permanente » ou « Déplacé temporairement ») et un emplacement cible, tout aussi facilement que de signaler une 404 (erreur « Introuvable »). La seule restriction est que les codes d’état définis doivent être ceux qu’un servlet HTTP Java standard implémente : cela signifie qu’un 301, 302, 404 et d’autres similaires conviennent, et vous pouvez consulter une liste complète dans la documentation Java. [caption id=“attachment_2452” align=“aligncenter” width=“973”] Des codes d’état HTTP personnalisés peuvent désormais être spécifiés pour les remplacements de contenu de page — dans des limites raisonnables[/caption]

Caches multiples

Nous avons déployé la version prototype d’une nouvelle fonctionnalité appelée le « Multi-cache » : auparavant, nous n’avions qu’un seul cache Binaire et un seul cache Source ; avec cette fonctionnalité, les bases ont été posées pour ajouter des caches personnalisés nommés (dix au maximum au total par projet). Chaque mode proxy (preview, live, published) peut se voir attribuer son propre cache binaire ou source, qui n’ont même pas besoin de contenir le même contenu : il est désormais envisageable de continuer à proxifier une version de la page via le cache source, tandis qu’une version plus récente est affichée en preview depuis un autre cache source complètement distinct. Il en va de même pour les caches binaires : la version des traductions stockée dans le cache pourra être rapidement changée, en assignant simplement une autre version de cache binaire. Cette fonctionnalité est actuellement dans une sorte de bêta fermée : elle n’est disponible que pour certains partenaires, mais si vous souhaitez tester cette fonctionnalité sur l’un de vos projets, n’hésitez pas à envoyer un e-mail à notre support pour en faire la demande.

Menu déroulant du sélecteur de langue

Nous avons également déployé un nouveau sélecteur de langue, sous la forme d’une liste déroulante configurable, en plus des petits drapeaux déjà disponibles. Ce sélecteur de langue est configurable par l’utilisateur quant à son emplacement sur la page : il doit se voir attribuer un « élément d’ancrage », c’est-à-dire la classe CSS d’un élément div quelque part sur la page, dont le contenu sera remplacé par la liste déroulante des langues ; l’utilisateur peut définir le nom d’affichage de chaque langue, s’il le souhaite. Par ailleurs, puisque la liste déroulante est accessible via CSS, le client peut en personnaliser l’apparence avec les règles CSS appropriées depuis la page source. [caption id=“attachment_2450” align=“aligncenter” width=“964”] Un nouveau type de sélecteur de langue, pouvant s’ancrer n’importe où sur la page, à condition que la classe appropriée soit spécifiée[/caption]

Accélération de la vitesse de traduction JavaScript

Enfin, nous avons examiné notre code en profondeur et effectué plusieurs passes d’optimisation approfondies sur notre traducteur JavaScript. Le nouveau traducteur se compare à l’ancien à peu près comme une fusée se compare à un vaisseau plus rapide que la lumière : le nouveau traducteur est jusqu’à vingt fois plus rapide que l’ancien (cela ne s’applique qu’à la traduction elle-même, et non à la latence de la réponse initiale – voir l’image à la une).