The Smartling Global Delivery Network (GDN) is comprised of a translation proxy and client-side components that enable you to offer translated websites and web applications without the need to internationalize your site or host and manage translated content within your systems. It also allows you to modify translations and apply those changes on your production site within seconds. To understand how it works, we’ll first look at how web browsers display websites.
How Browsers Display Websites
Simple Web Page
When you ask your browser to display a web page by entering the page address (URL), the browser opens a communication channel with the server where the website is hosted and sends a request asking for the page specified in the URL path (e.g., ‘/products’). Upon receipt of the request, the server sends a response back to the browser over the same communication channel. The response contains the initial web page content, which the browser renders on your computer.
As part of the rendering process, the browser typically loads additional content referenced in the page via further request-response exchanges, such as images, CSS, and dynamic content stored in JSON and Javascript.
Simple Web Page with the GDN
With the GDN, the same steps are followed with two key differences.
1. First, the communication channel passes through the GDN: the browser sends requests to the GDN proxy, which forwards them to the web server; and the web server sends responses back to the GDN proxy, which forwards them to the browser.
This enables the GDN to modify the request and response ‘in transit’ as they pass through it. In particular, it allows the GDN to substitute translations for the original language content sent in the response from the server. Thus, a web page that leaves the web server in English might arrive at the web browser in French.
2. The second key difference is that a client-side component is injected into the web page, allowing translation to be done at render time in the browser. Most modern websites use some type of Javascript framework to build interactive user experiences. These frameworks spread content across a mix of JSON and Javascript files, which sometimes makes translating that content in transit via the proxy challenging. Rather than trying to capture and replace content on the way to the browser, it can be advantageous to intercept it during page rendering as it is less technically complex and produces reliable results.
The diagram below depicts a typical GDN setup for an English (not translated) and French (translated) website. Please note that this diagram only shows the setup of the GDN web proxy, and does not display Smartling's client-side Dynamic Content Support component.
This approach, in which the GDN sits between the browser and the web server, is called proxying. Only your translated website is routed through the GDN – your source website is served as normal without the GDN.
Link Rewriting
Once a user has reached a translated site delivered by the GDN, you must ensure the user doesn’t inadvertently navigate off the site by clicking on a hyperlink. To do this, the GDN uses a technique called "link rewriting." Links pointing to the source site are updated automatically to point to the translated site.
For example, a link to www.company.com/about might be updated to fr.company.com/about on your French site powered by the GDN. This ensures that if the user clicks the link, the request will be sent through the GDN, and they will receive the translated version of the "About" page.
The GDN has default link rewriting behaviors, which can be customized to your specific needs.
Content Capture and Translation
When the GDN proxy is processing a response from the server, its main job is to replace the source-language content with the corresponding translations. To do this, it must extract the translatable content from the source page, retrieve the associated translations for this content, and insert the translations into the page before sending it to the browser.
For HTML content, the GDN automatically extracts certain content from the page and breaks it into separate translatable pieces called "strings" based on block-level tags within the HTML. The example below will be captured as two separate strings for Smartling translation.
<div>
This will be ingested as <span>one</span> string with
some <a href="/a.html">inline tagging</a>.
</div>
<p>
This will be a second string.
</p>
This is because the <div></div> and <p></p> tags are both considered "block-level" tags in HTML, whereas the <span></span> and <a></a> tags found in the first sentence are considered "inline" tags. Inline tags will be visible to Translators as part of the content to be translated, and the translation tool will ensure that these tags are also appropriately included in the translation. Details on which tags are considered block versus inline and how to change this behavior can be found in our article on Changing content segmentation.
In addition to the content within block-level tags, the GDN will automatically capture separate strings for translation from the following attributes:
- 'title' for all tags
- 'alt' for <img> & <input> tags
- 'label' for <optgroupt> tag
- 'content' for <meta name="keywords"...>
- 'content' for <meta name="description"...>
Additional attributes can be added to this list via a configuration change in your Smartling dashboard.
For translatable content stored in JavaScript or JSON, the GDN proxy can extract content explicitly identified for translation through special directives. However, it is generally better to use the GDN DCS (Dynamic Content Support) client-side component to process this content automatically when the page is being rendered in the browser. This approach requires less configuration and works well with modern website technology stacks, especially Javascript frameworks.
When it makes sense to translate some of this content via the proxy, it can be captured using specific rules and directives to indicate where the content is present and how to safely extract it. Additional details on processing this type of content are found in Capturing JSON Content and Capturing JavaScript Content.
Once the content is extracted, the GDN searches its translation cache for matching translations in the language served. If a match is found, it is added to the page in place of the original source language content. This process happens in real-time, taking only milliseconds to execute.
If no matching translation is found, the new content without translations is automatically sent to your Smartling GDN project. It is then available to be placed in a Job and a translation workflow to be processed. As soon as the translation is completed and published in the Smartling workflow, it will automatically added to the GDN’s translation cache and thus will appear on the translated web page on subsequent page loads.
Images, CSS, and Other Resources
Most web pages include other types of content outside of HTML, such as images, style information (CSS), and JavaScript, which are required for the browser to properly display the page but are not included directly in the first response. Instead, the first response to the browser usually contains some HTML content along with a list of additional resources needed before the page can be displayed. The locations of this content are included as URLs in the initial page response, allowing the browser to follow the same process of opening a connection to the server where the resource is located and requesting each additional item required to display the page.
Since these additional items often do not contain translatable content, they do not need to pass through the GDN and, by default, will bypass it. When they contain translatable content (for example, in JavaScript or JSON files), assuming that DCS is not used to translate them, the requests to retrieve them and the associated responses are routed through the GDN to translate that content. Bypassing the GDN for resources that don’t require translation is achieved by "absolutizing" the URLs for those resources. For example, a relative image URL like '/images/banner.jpg,' which would usually be requested via the translated page it's found, would be modified to load via '[your source site]/images/banner.jpg.' where [your source site] is the domain for your source site This would cause it to be requested from the source site, bypassing the GDN.
Thus, the browser can load the initial page and all required resources, using the GDN where needed, so that all the necessary content is translated.
How Requests Get Routed to the GDN
Requests can be made to pass through the GDN in two ways: one is based on the Domain Name Service (DNS), and the other is based on having another layer sit in front of the GDN, which would often take the form of a Content Delivery Network (CDN).
Regardless of how traffic is routed to the GDN, all traffic for a customer will route to a client-specific CNAME where the GDN listens for requests made to that client’s translated sites. A CNAME is a special type of DNS record that acts like an alias, allowing traffic for multiple domains (i.e. multiple languages) to be routed to one point.
Let’s look at the DNS approach first.
DNS-Based Routing
For the browser to establish a communication channel with a web server, it must first obtain the unique address of the server. This address is known as the IP address, and it is obtained using an internet service called DNS, which associates the server's name with its IP address. When the browser wants to open a connection to www.company.com, it first asks the DNS for the IP address of www.company.com and then opens a connection to the server with that address. For the browser to open a connection with the GDN instead, the address stored in the DNS for the server name must be set to a client-specific CNAME for the GDN.
The DNS-based approach is used when the translated websites can have a different server name from the source-language site. For example, to route traffic for a French version of www.company.com, a customer may choose to put their translated site on a subdomain and the French site would be fr.company.com. In their DNS settings, the entry for www.company.com would not be modified. Instead, a new entry would be created as a CNAME. That CNAME would point fr.company.com to that customer’s client-specific CNAME where the GDN listens for requests.
In some cases, it is not possible to use DNS to route traffic for a translated site. Some examples of when DNS wouldn’t work include when using ccTLDs (country-code top-level domains) for your translated sites, e.g. www.company.fr or when using subfolders, e.g. www.company.com/fr. In those cases, another routing mechanism is needed.
Routing via a Layer (CDN, proxy, web server etc.)
When routing via DNS is not possible, another server or layer must receive connections meant for the translated site and then make a decision about where to send that connection.
This additional server decides on which requests to forward to the GDN based on some other information in the request, such as the language folder included in the URL or the top-level domain being requested. If a Content Delivery Network (CDN) is used, it can often perform this task. In that scenario, DNS would point traffic for www.company.fr or www.company.com/fr to the CDN and rules configured in the CDN would either route traffic to an origin (source) server or to the GDN. Some logic is built into the CDN to understand when traffic is going to the GDN and when traffic is coming from the GDN to avoid a routing loop.
Using a CDN is the most efficient way to route this type of traffic as they generally have servers spread across the globe, ensuring that a local server responds to the connection request and quickly routes the connection to the correct destination. It is also possible to use another proxy or web server to listen for connections and make routing decisions. However, those setups will typically only be present in one location and thus, regardless of where a user sits, they must first make a connection to this server before it finally makes the decision to route to the GDN. Each customer will have different requirements in terms of routing, performance, management capabilities and scalability. Smartling’s Professional Services team will make recommendations on the best setup based on your needs and technology stack.
Tip: Additional information on choosing among these options is available in Choosing a Domain or Routing Strategy and Localized Domain and Routing Options.
Avoiding Source-Language Bleed Through
While content is still being translated, the source language content will be displayed on the translated page instead of the translation, which can result in the translated page having a mixture of translated content and source-language content.
A number of approaches are available to avoid source language content appearing on a live translated web page.
The most common approach is to access the content on a staging server through the GDN before it goes live. This allows the new content to be discovered and submitted for translation so that a translation is available by the time the content goes live.
Another option is to enable the GDN’s Site-Wide MT option. This will quickly machine translate any new content found on your site while still allowing that content to move through your normal translation workflow. Once a finalized translation is available for the new text, it automatically replaces the machine translation with your finalized translation for use on your site.
Customizing the Behavior of the GDN
While the default behavior of the GDN may address all your needs, there could be areas where you need to customize the behavior to match your requirements more precisely. Here are some examples of when you might want to modify the default behavior of the GDN:
- Excluding certain parts of your site from translation, such as user-generated content.
- Disabling link rewriting so that certain links always point to the source site.
- Translating specific content found in JavaScript or JSON files via the proxy instead of using DCS (Dynamic Content Support).
- Removing portions of your content from the translated versions of the site.
- Swapping in locale-specific content in sections of your site.
The GDN provides a number of different approaches to this type of customization. For more information, see Methods to Control Global Delivery Network Behavior.
Visual Context for Translators
Visual context is a powerful Smartling capability, enabling Translators to produce higher-quality translations in the first translation step.
With the GDN, visual context can be captured automatically for HTML content. For content stored in JSON and other formats, Smartling provides a variety of additional methods for capturing the related visual context for your web content.
Search Engine Optimization (SEO)
The GDN is effectively invisible to search engines, and thus it does not have any negative effect on SEO. Search engine indexers view translated sites created by the GDN in the same way as they do your original site. Content delivered via the GDN is fully accessible by search engines. The various translated sites served through the GDN look like separate sites to search engines, each are indexed and are shown in search engine results.
However, it is still vital to consider SEO carefully to ensure you obtain satisfactory SEO results for the translated versions of your website. In addition, it may be necessary to tune GDN behavior to meet your SEO requirements, such as choosing an appropriate domain name strategy and ensuring that page metadata is appropriately translated.
The GDN fully supports sitemaps.xml and robots.txt, which provide additional instructions to search engines on how to index the site, including what to ignore. Your web administrator can explicitly set certain pages on the GDN-powered site to be ignored by search engines. Furthermore, the GDN properly handles "hreflang" tags, which tell the search engines what language is contained in the translated site.
If your SEO experts have specific thoughts on how subdomains (fr.example.com), ccTLDs (example.fr), and subdirectories (www.example.com/fr) impact SEO, the good news is that any of the above can be configured for individual language sites with the GDN. The GDN can also serve multilingual sites via cookie or header-based locale selection, without a unique URL. All of this is configurable in the dashboard and the Smartling Professional Services team can provide you with detailed guidance on how to employ these various domain/routing types.
Tip: For more information, read our documentation on optimizing your GDN sites for SEO.
Performance
Localized page requests are broken down and delivered in approximately 40 milliseconds on average - a delay which is not noticeable to end users. This time is an average across a wide range of sites proxied by the GDN and individual sites or pages can impact this processing time. Bigger pages, with more content and more complex rules for handling them may increase or decrease the total processing time.
Additionally, Dynamic Content Support (DCS) loads it’s own resources into the browser. Our best practice is to limit the amount of content handled by DCS when possible. This is because DCS must load a translation file into the browser and when loading large amounts of translations, it can impact page performance.
Thinking of using the Global Delivery Network in your international strategy? See Planning a Global Delivery Network Strategy.