Easyling Release Notes - 2015 August
Sep 8, 2015 - Easyling.com
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”]
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”]
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”]
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).