Easyling release notes May, 2024

As we step into June, we’re excited to share the latest updates and improvements we’ve made in May. Our team has been hard at work to enhance your experience, and we’re thrilled to introduce a standout feature this month: a completely redesigned login screen. I’m also experimenting with AI. Can you guess which parts of this doc are original? Read everything below the fold.

New login screen

Nobody really likes logging in. It’s such a hassle having to press the password manager’s button. Or even worse if you have to actually remember your password. However, as of now, the Dashboard has to be secured somehow. The best we can do is make the lock as pretty as possible. To that end, we re-designed our login screen. This new coat of paint is part of our efforts to keep our systems looking fresh and stylish.

The features are unchanged. You can still log in via your username and password or use your trusty Google or XTM accounts for authentication.

The new design incorporates modern usability standards alongside the usual blue theme of the Dashboard. I think it’s a lot more visually pleasing than the old one was. What do you think? Drop us a line at support@easyling.com and let us know.

API for starting translation in Crest

By default, the Crest translator engine will start translating content as soon as it is loaded. In most instances, that means in the first milliseconds and this works great for the vast majority of websites.

Some websites, however, use a technology called server-side rendering to speed up initial loading of sites that rely heavily on JavaScript. In a nutshell, the JavaScript code is ran on the server before the result is being sent to the user. Assuming that the server can run JavaScript faster than my phone or laptop does, this will result in faster page loading. However, client-side JavaScript is still required for interactivity. This is added via a process called hydration. That process replaces elements with identical-looking, but interactive elements. This is usually invisible to users because they are unlikely to interact with these elements in the milliseconds that this process takes.

The problem with such a system is that when our translation script is added, there are now two scripts trying to edit the website in the first milliseconds of it loading. This produces rather funny results. Let’s assume that the entire navigation of a site is interactive because it has sub-menus. Naturally, it’ll be loaded without interaction first, then the hydration will add the interactivity. At the same time, our script will add translations. The two systems then overwrite each other element-by-element. Depending on which system managed to run slightly faster, you’ll have partially translated and partially interactive navigation on your site. And every time you re-load the page, it’ll be slightly differently partially translated/interactive.

The solution for this scenario is for the translator script to wait until the hydration process finishes. It’s just a few milliseconds after all. But how does it know when the hydration process is finished? It unfortunately can not. So, to ensure the desired translation experience without guessing, it must be notified. First, enable the Start manually tweak under JavaScript publishing on the Dashboard.

Then, you must edit your website. Find the code responsible for handling the hydration process. Then, stick one line of JavaScript to the end:

window.crestTranslator.start();

This is a call to our API, letting the translator script know that it should start translating.

Prevent recursive proxy calls

Let’s suppose that we’re translating www.example.com to Ukrainian via Translation proxy and we set up subdirectory publishing as per the documentation. The translations are now available on www.example.com/ua/. When you load this page, the request arrives to Easyling. It’ll in turn send a request to www.example.com for the English content so that it can be translated. This is the regular mode of operation.

Now let’s consider that someone visits www.example.com/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/. Easyling would dutifully cut one set of /ua/s off and send a request to www.example.com/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/ua/, translate the results and bill you for it. But what happened to that request sent by Easyling? You guessed it, it arrived to Easyling. It would dutifully chop off one of the /ua/s and the cycle would repeat until there are no /ua/s left. Only then would it send the request for the actual English content. Easyling is designed to scale as needed for extreme throughput, so all of these requests would be handled and billed. Naturally, that’s not desired behaviour so now Easyling can detect this and return 410 (Gone) as a response. This is enabled by default for all projects.

Fixes

Naturally, we have a few smaller improvements to mention too:

• An error was fixed that happened when “Recrawl with same settings” feature was used on a scheduled crawl building snapshots.
• We introduced and fixed a bug that would prevent you from creating projects.
• Finally, we squashed a bug where incorrect numbers were displayed in the bulk delete entry dialog in the Workbench.

Disclaimer: The first half of the introduction was suggested by ChatGPT. The rest of the document was prepared using human intelligence, which is my excuse for the typos.