Publishing Compared - Easyling's modes of operation

Easyling.com can be used to publish your translations in a variety of ways and with such a wide portfolio to choose from it’s sometimes easy to get lost among the solution that is best suited for your specific need. This post will help you make sense of each and pick the best one to assist your client.

BLUF (Bottom Line Up Front)

Easyling has three major publishing modes: proxy, JavaScript, and static HTML. Each has various pros and cons associated with it that should be taken into consideration before making your choice on how your site should ultimately be published.

Additionally, Easyling can deploy the JavaScript-powered translator in the form of a Chrome extension. Because this can be enforced through enterprise policies, using channels already built into Chrome, it can be useful for enterprise customers where strict policies and conflicting stakeholders prevent the necessary changes for any other publishing mode.

Mode	Setup difficulty	Follow-up ability	Security	Performance
Static HTML Export	Low	None	N/A	N/A
Client-Side Translation	Medium	Medium	Good	Good
Website Translating Chrome Extension	Medium	Medium	Good	Good
Proxy in subdomain mode	Medium	Excellent	Good	Excellent
Proxy in subdirectory mode	Potentially complex	Excellent	Good	Excellent

On publishing modes

Each publishing mode focuses on a different use case about how the translations are to be served as well as having different intended uses. The scale moves between ease of utilization and the ability to follow up on changes in order to guarantee an immersive translation experience.

Static HTMLs

Perhaps the easiest to explain is the static HTML export. This is best used when the project is a “one-shot” deal; after the initial translation, no changes are expected to the content and more importantly the client insists on hosting the page(s) themselves. Additionally, the site needs to be very simple - things like web apps and forms are out of the question with this mode.

Here, the proxy simply conducts a final crawl of the website, applying translations as it goes, and writes the resulting data to storage, which can then be downloaded as a single archive, to be hosted on any provider of your choice.
Of course, the problem here is that any changes to the original are not visible on the translated pages, nor can any resource replacements and content injections work, since the request never even reaches the proxy for translation.

Thus, this mode is only recommended as a last resort, or in case of client “off-boarding” at the end of a contract.

Proxy

The most powerful mode of the three is the proxy, whether it’s in subdomain or subdirectory mode. Either choice allows you to bring the full power of Easyling.com to bear on the client’s website, leveraging features such as image-/resource-replacement to provide transcreated visuals, content injections to create entirely new language pages, and a world-class CDN to achieve exceedingly fast response times.

In either case, the proxy sits between the original CMS and the visiting browser, operating on the soruce language responses in real time. This allows it almost unlimited ability to modify and alter the responses to achieve the perfect results envisioned by the LSP and the client together.
The downside is that, as a proxy service, Easyling must be injected between the two, which might mean additional firewall configuration or clearance by INFOSEC (depending on the organization).

And it is this last point that led to…

JavaScript

Our JavaScript publishing mode sacrifices some functionality for greatly improved compliance. Here, the translation itself is handled by a JavaScript snippet provided by the service, which downloads the entire dictionary for the project and applies the translations in the client’s browser. Any content which cannot be translated (because it’s new, and translations are missing) is reported back to Easyling for handling as part of the regular maintenance workflow.

The fact that it runs completely on the visitor’s machine means the backend does not need to handle sensitive data, and there is no need to open firewalls to serve the site. As long as the template can include the loader provided by Easyling, the translations will be shown.
The downside to this method is that despite our efforts to make the translator as widely compatible as possible, the prevalence of many different browsers and JS engines means we cannot make any guarantees regarding its operation. Additionally, since the content needs to be ready before it can be translated in the browser, a Flash of Untranslated Text is inevitable, no matter how brief that is.

CREBBL - The Localization Extension

Because we realize that sometimes, it is simply not possible to make the changes required to publish the site one way or another, we developed an alternative packaging for the JavaScript-powered client-side translation system: a Chrome extension that takes care of injecting this script into the website. Once the translator is placed into the page, it will automatically download the necessary dictionary and apply it to the page to translate it, with all the new content being sent back for translation.

With Chrome’s support for managed profiles, the already-established channels to manage these profiles can be used to enforce the installation of this extension, which takes care of localizing the site in the user’s browser, leading to the same immersive experience, but with much less difficulty in the publishing process.