What are my deployment options?

The deployment of GlobalLink Web is how the site switches from language to language.

You have 4 options to deploy GlobalLink Web, all of which can be setup and controlled from your Installation page under Project Settings. Each deployment method does not generate a new site or page; rather, the technique localizes the site.

To implement GlobalLink Web, you must inject the GlobalLink Web code snippet. The injection is done once across all the target languages. The deployment mechanism also validates the domain in the referrer header. Doing so adds validation logic so there are no cross-translations between GlobalLink Web customers.

These are the four deployment methods supported on GlobalLink Web:

1. domains    e.g.  de.example.com
2. folders       e.g., example.com/de/
3. query  e.g., example.com?lang=de
4. cookie e.g., example.com

Each deployment strategy has advantages and disadvantages. Three additional methods are shown, but they are only there to delineate their problems.

Below, each method is explained in further detail. Only the domain, folders, query strings, and cookies methods are supported.

1: Domains

One of the most popular and functional methods of deploying the localized site involves selecting a distinct subdomain per language. Using a domain provides a unique URL for each language, visible to users and bots. This method positively impacts SEO because the domain can reflect the in-language content. Below are examples of how the target language is distinguishable in the URL.

If you do not wish to set a domain for your origin language, you can assign the deployment value of the language setting to "oljs_default." If the program cannot find a domain matching any language, it will default to this language setting. All the domains (DNS entries) will point to your origin site but inject the project-specific code snippet. The deployment method and corresponding value will localize the site into different languages. The deployment value can be a list of domains if the site has multiple domains.

We suggest using subdomains over domain suffixes for two reasons. The first reason is that subdomains, e.g., de.example.com, are typically oriented around languages, while domain suffixes, e.g., example.de, are determined by countries. Subdomains eliminate this confusion by specifying the language instead of the country. The second reason is that subdomains are cheaper because changing a domain suffix involves purchasing a new domain with domain authority and requires distinct certificates.

The advantages of both subdomains and domain suffixes include:

• Distinct domain in URL per language
• Spiders and bots can see translated URLs (increase SEO)
• Ability to copy & paste a translated URL
• Easy to understand which language you see and why you see that language

When managing domains for localized sites, your IT department may need to:

1. Purchase additional domains
2. Purchase SSL certificates
3. Manage DNS for the additional domains

2: Folders (Directories)

This deployment method involves establishing an individual folder for each language. Like the domains option, this method provides a unique URL for each language, positively impacting SEO.

If you choose the folder option as your deployment method, the first step is to set up the virtual folders for each required target language. The specific steps to setup these virtual directories depend on how your site is built and deployed. Some CMS platforms will allow you to do this via their admin UIs, but you may need to set this up directly on your Web Server from your management console. The functional requirement is for the language folder version of each page to serve the content found on your origin site version. GlobalLink Web will localize the contents of the page when the language value is detected in the URL.

If you do not wish to set a path in the URL for your origin language, you can assign the deployment value of the language setting to "oljs_default." If the program cannot find a path matching any language, it will default to this language setting. It is also best practice that the folder pattern should include the leading and trailing slashes as part of the pattern (/de/). Be aware that the origin might not have a folder pattern.

Warning: If a multilingual CMS produces your website, you do not want the folder to trigger the other languages in your CMS.

All the folders serve the same content, but the GlobalLink Web injection localizes the site to the specified language. The language code after the domain does not bring you to a new page. It merely triggers the injection. If the site has multiple folders, the deployment value can be a comma-delimited list, e.g., /de/, /de-de/, /de-en/.

Using folders to indicate language has the same advantages as the domains method, namely:

• Distinct domain in URL per language
• The ability for spiders and bots to see translated URLs (increase SEO)
• Ability to copy & paste a translated URL
• Easy to understand which language you see and why you see that language

When managing domains for localized sites, your IT department may need to:

1. Create a virtual directory for each language, e.g., /de/
2. Ensure all links work under each virtual directory, e.g., all URIs on example.com/de should start with /de/

3: Query String

A simplified URL approach uses a query string to differentiate the languages. The query string is a subtler way to deploy the localized site, and it keeps the domain the same throughout all languages. This strategy is deployed less frequently than domains or folders, but it is possible with GlobalLink Web. However, query strings are very risky when it comes to SEO, and some search engines ignore them completely.

Below are examples of the language code in a query string.

Your web server serves up the same content but injects the query parameters. If you do not wish to pass a query parameter for your origin language, you can set the deployment value of the language setting to "oljs_default." If the program cannot find a query parameter, it will default to this language setting. 

The advantages are:

• The ability for spiders and bots to see translated URLs (SEO)
• The ability to copy & paste a translated URL

However, there are notable disadvantages:

• It is hard to understand why you see a particular language
• The lang parameter will be "tangled" with query parameters that your site might already use for queries
• Some marketing teams care about the URL and think it looks awkward
• Some SEO engines ignore query strings

When managing a query string deployment for localized sites, your IT department may need to:

1. Create a query string for each language
2. Ensure all links within a specific language include the correct query string

4: Cookie

GlobalLink Web will check the browser for the cookie's language preference and set the language based on the code provided. If no code is provided, the default is the origin language. This strategy is strongly discouraged for public websites because SEO is not possible while using it. However, websites that are behind a login may want to use this strategy because they do not utilize SEO, and it's the easiest method to implement.

Below are examples of the language code in the cookie.

GlobalLink Web will supply the correct translations based on the cookies. If you do not wish to set a cookie for your origin language, you can assign the deployment value of the language setting to "oljs_default." If the program cannot find a cookie, it will default to this language setting. Be aware that the origin might not set a cookie.

The advantages are:

• It is easy to understand why you see a particular language
• The langPref parameter will not be "tangled" with query parameters
• It will keep the URL looking clean
• It will not need to be managed by the IT department

However, there are notable disadvantages:

• Lacks the ability for spiders and bots to see translated URLs (SEO)
• Lacks the ability to copy & paste a translated URL

Other Deployment Strategies

The following strategies have many differences compared to the four approaches provided by GlobalLink Web, and these are not currently supported:

Browser Language Preference:

Your computer's settings may apply a language preference to your browser. The deployment occurs in the browser preference, so the URLs are identical.

Relying on browser language preference as the only mechanism for language selection has disadvantages:

• No ability for spiders and bots to see translated URLs (SEO)
• No ability to copy & paste a translated URL
• Not easy to understand why you see a particular language

HREF Lang:

Some browsers examine a meta tag called "HREF lang" on each webpage and compare it to your browser's preferred language. For example, when you assign your browser's language to German, the browser will prompt you to bring you to that alternative language.

The URL remains unchanged, and the prompt that localizes the site comes from the browser settings. Using HREF Lang requires a distinct URL for each language, so HREF Lang is not an alternative approach to language selection: it must leverage your language selection approach and redirect users to those distinct URL patterns.

GEO Location:

There is no unique URL pattern, but the action to change languages is also out of your control and dependent on the device's location. The application does not support this deployment method because it is fraught with problems. We only mention this approach so that we can explain the issues with it:

• No ability to copy & paste a translated URL
• Spiders and bots cannot see translated URLs (fails SEO).
• Where the spiders or bots are hosted determines which language they will see (you have no control over that)