One of the major obstacles faced with the proxy is the reluctance to transmit potentially-sensitive information through third parties. There can be quite a few legitimate reasons for this:
At other times, the situation simply may not be conducive to using a proxy: the site might be hosted on an internal network that’s strongly isolated from the outside, preventing access to the crawler; there may not even be a route in, due to corporate network-provided DNS-wizardry; or the site might actually be a complex single page application (while Easyling can handle that, it might be outside the client’s budget) that is pulling in data from external services that still require translation.
For these use cases, there’s Easyling’s Client-Side Translation system, which allows the content to mostly or completely bypass the proxy, avoiding most troubles. It only requires minimal changes to the site (inserting the loader script - more on what that is a few paragraphs down - which can even be hosted in your own systems) to prepare for localization.
You can use the crawler to collect content, and use regular Easyling facilities to translate it; or for trusted users that are logged into Easyling at the time, it is also possible for the translator script to submit the new content directly to Easyling’s service for processing. If needed, the only difference is in the publishing step.
If you operate in a field where using the proxy is prohibited, instead of publishing the translations via our subdomain or subdirectory methods, you can insert a one-liner loader script in your site template. This will pick the language most familiar to the visitor (based on their browser settings or previous choices on your site), and translate the page in-situ, in their browser. This makes sure no data is sent anywhere, so your client’s data stays safe and secure.
Client-side translation consists of two parts: the loader and the dictionary. Although by default, both of these are served via Easyling’s CDN, there’s nothing stopping you from downloading the files and hosting them yourself. Though the CDN is provided pro bono for you, self-hosting the files allows the translation system to work on intranet-type sites or in high-security environments which preclude any sort of outside requests.
The loader takes care of deciding the language the page should appear in, and loading the appropriate dictionary. This is done using a number of inputs, in order of precedence:
__ptLanguagequery parameter, that will override any other choice and have the page appear in the language queried.
Whichever option prevails, the choice is stored in the browser’s local storage, so that when the site is visited in the future, it will immediately appear in the correct language.
One the loader has selected the most applicable language, it downloads the dictionary and translation script. This is what takes care of the actual translation, by exchanging all content to the provided target language content in the browser. It also installs a watcher on the page (called a
MutationObserver) that keeps track of any new content appearing on the page as the visitor reads, and handles it as necessary. This ensures the page remains fully translated as the visitor browses.
As new content appears on the website and translations are updated, it is necessary to regularly re-publish the translations by exporting the latest dictionaries and making them available for the loader. This can happen either by publishing the latest exports from within Easyling (if the loader is hosted in our CDN) or by downloading the latest exports, and manually rehosting them on the client’s service (if the proxy is to be completely out of the picture).
In either case, Client-Side Translation is slightly more cumbersome in the sense that it requires human intervention to update its visible translation, while the Proxy Route does this automatically for the client.