Easyling Release Notes - 2015 August

Summer has come to a close (though the weather seems to disagree so far), just like how we’re closing another segment in Easyling’s development. This month was also packed with new features, such as the ability to set alarms to alert you to increased resource usage, the ability to define HTTP Status Codes in the Page Content Override, the prototype ability for using multiple named caches for different proxy modes, and what amounts to the installation of a warp drive into our JavaScript translator. See the details after the jump!

Increased usage alert

Easyling has always tracked the frequency of page loads through it, but statistics were updated once a day. Now we introduced real-time alert system, where you can set custom limits on a per-project basis to get an email notification if pageviews/second, new words/second, or translated words/second rises above this threshold. This can be used to prevent depletion of your wallets, or to alert the customer to the abnormally large number of requests. [caption id=“attachment_2451” align=“aligncenter” width=“954”] Increased resource use can now trigger an email alert[/caption]

Custom HTTP status codes in Page Content Overrides

It’s been a while since we implemented the ability to add custom page overrides, which create new virtual pages in the proxy or override existing ones. Now we’ve expanded this with the ability to define custom HTTP Status Codes and made it easier to use accented URLs. Custom status codes means that now you can define custom redirections easily by specifying a 301/302 status (meaning “Moved Permanently” or “Moved Temporarily”) and a target location, just as easily as reporting a 404 (“Not Found” error). The only restriction is that the defined status codes must be ones a standard Java HTTP servlet implements: this means a 301, 302, 404, and similar ones are okay, and you can see a full list in the Java Documentation. [caption id=“attachment_2452” align=“aligncenter” width=“973”] Custom HTTP status codes can now be specified for Page Content Overrides - within reasonable limits[/caption]

Multiple caches

We’ve rolled out the prototype version of a new feature called the “Multi-cache”: previously, we only had a single Binary and a single Source cache, with this feature, the groundwork was laid to add custom named caches (ten at most in total per project). Each proxy mode (preview, live, published) can be assigned its own binary or source cache, which need not even contain the same content - it is now conceivable to keep proxying one version of the page via the source cache, while a newer version is shown in the preview from another, completely separate source cache. The same applies to binary caches: the version of translations stored in the cache will be quickly swappable by simply assigning another binary cache version. This feature is currently in a sort of a closed beta: it is only available to select partners, but if you wish to try out this feature on a project of yours, feel free to email our support channel to apply.

Language selector dropdown

We’ve also deployed a new language selector, taking the form of a configurable dropdown, in addition to the little flags already available. This language selector is user-configurable regarding its placement on the page: it must be given an “anchor element”, the CSS class of a div element somewhere on the page whose contents will be replaced with the language dropdown, where the display name of each language can be set by the user, if the so desire. Furthermore, since the dropdown is addressable via CSS, the client can customize its appearance with the appropriate CSS rules from the source page. [caption id=“attachment_2450” align=“aligncenter” width=“964”] A new type of language selector, able to anchor anywhere on the page, provided the appropriate class is specified[/caption]

JavaScript translation speedup

Finally, we dug deep into our code, and conducted several in-depth optimization passes on our JavaScript translator. The new translator compares to the old one much like how a rocket compares to a faster-than-light ship: the new translator is up to twenty times faster than the old one (this only applies to the translation itself, not the latency of the original response - see the featured image).