Localizing content well takes in-depth knowledge of the language, culture, environment, and economy of the region that you are trying to reach. This market research cannot be automated; the process develops a connection between your business and your customers in the area. As a developer, this can be disappointing. There is no API or AWS service that replaces the need to collaborate across the business to create and implement an international strategy. However, expanding to other countries does require some technical work to ensure a great experience for all visitors. This article will cover several resources and techniques that can help you build a website or app for a multinational audience.
Imagine that you are a developer for an athletic clothing company where you build and maintain the e-commerce website. At the moment, the company only offers its products in the United States. After a long strategy session, senior management decides that the company wants to offer its products to the German market. You get an email asking when the website can be available in Germany. We will use this example throughout the article, but the strategies developed are applicable across nations and markets.
Like most requests for a time estimate, this one has insufficient detail for a meaningful response. Unless you have done something to prevent people in Germany from accessing the website, it is already available there. However, it is advertising the products in English, the prices are in USD, and that stars-and-stripes banner left over from the 4th of July doesn't quite hold the same appeal. Furthermore, all requests are traveling back and forth across the Atlantic ocean to your
us-east-1 AWS servers, decreasing site responsiveness.
Just as you're packing up to head home, you get a response to your email asking for clarification. Management wants the website to feel as native to Germany as it does to the United States. Other business units will provide you with resources and product direction, but you have a lot of work to do.
A First Pass at Usability
There are a few things that you can do on day one to prepare the site for internationalization.
Make sure that your stack supports a character set that includes symbols like ä, ö, ü, and ß. Write some unit tests that process inputs with these characters. This will help with supporting German names and addresses. For expansion efforts into countries without a Latin alphabet, such as Japan, character set support and testing will be a larger challenge, but your stack or platform should offer plugins or libraries to help.
One of the first things that you can do is localize your forms. Make sure your length limits are sufficient for names and addresses. In particular, make sure that the city field is able to accommodate names like "Hellschen-Heringsand-Unterschaar," an actual city in Germany. Also, the address format can be slightly different, with the house number after the street name and the postal code before the city and region. Again, having test cases with localized inputs will ensure functionality.
Speaking of formats, many parts of the world outside of the United States write dates as DD-MM-YYYY instead of MM-DD-YYYY. As a programmer, date-times can be difficult to work with, and this adds yet another layer of complexity.
If you wish, you can purchase a domain
yourcompany.de to complement the
yourcompany.com or similar that you already use. If you do so, I recommend using the domain as a simple redirect rather than trying to support two independent websites. Pointing the domains to different servers would introduce unnecessary complexity to your deployments and could result in inconsistencies in things like URL patterns and resource locations. Furthermore, spinning up multiple independent versions of the website for each domain does not scale well into targeting dozens of markets over time.
Finally, at this first stage it's a good idea to read over the documentation for your payment provider and make sure that their offerings work well in other countries. In this case, send the finance people a heads-up if there are higher fees for accepting payments in Germany. If your provider doesn't support international transactions, you will either have to switch to one that does or integrate a second provider that works in Germany. Make sure to include shipping information prominently on the site and at checkout. You don’t want customers to be surprised by import duties or high postage costs.
Developing Localized Resources
For much of the content in this section, you'll want to send emails to various departments with your needs. Autonomy as a developer is fantastic, but many of the resources needed for a good digital internationalization require product and marketing people to work their magic and provide you with useful building blocks to proceed.
Translating content is a two-part process: you need to change the language and preserve the meaning. For example, translating a sizing chart into German will not only require changing "Shirt" to "Hemd," you'll also need to convert measurements to the metric system and standardize to German sizes.
If you didn't want your website to read like a scam email offering you a surprise inheritance, you once needed a competent copywriter fluent in the source and target languages to perform the translation. However, it is no longer strictly necessary for said writer to be fluent in the source language.
On AWS, we can translate every line of English copy to German using Amazon Translate. It costs 15 dollars per million characters at the time of writing, meaning that an entire site translation should cost a couple dollars. The quality of the translation is such that a copyeditor fluent in German should be able to fix it up for much less work than translating from scratch. Anecdotally, I have used this strategy before to bring content from a language that I do not speak to English, and the resulting translation has always been only a copyedit away from being usable. Perhaps I am doing myself a disservice by publicising the strategy, but using this tool can save your company on the cost of freelance writers.
Other things that you might want to consider are adding images, colors, patterns, slogans, and legal & compliance assets to your site. For colors and patterns, look into vexillology, or the study of flags. Vexillology will reveal, for example, that orange is equally important to Irish Protestants and Buddhists, but with very different meanings. Hopefully, your product or marketing team will provide you with direction for what to modify.
If this were an undergraduate textbook on managerial economics, I might pause to recount the fable of the Chevy Nova, a small car that Chevrolet produced from the 60's to the 80's. To an English-speaking customer, "Nova" connoted supernova and was likely conceived to conjure images of the space race and patriotic excellence in engineering. To a Spanish-speaking customer, "El Chevy no va" translates to "The Chevy doesn't go," a poor message for a car. The effect of this on sales has been pretty thoroughly disproven; even cursory knowledge of Spanish grammar and usage casts it into doubt. However, the myth is so common that even dispelling it is overdone. All of this to say: don't give a horde of marketing writers a true anecdote to recite; check your branding before entering new markets.
Separate Content from Code
A week later you get an email from the marketing department. They have new copy written in German, a new color scheme for the site, blog posts from German fitness influencers, and new photographs of every product you sell as worn by members of FC Bayern Munich. Finally, we can talk tech.
Separation of concerns is a best practice across application architectures. We can apply the principle to support localization efforts. Whatever content you have developed such as text, images, and styles should be stored separately from the code responsible for delivering it to the client. For example, a checkout page could load a price and currency from a database, text from a file, and images from a CDN.
Using a CDN, or content delivery network, is an important method for globalizing your site. CDNs cache your content across the world, making your site faster for users in every location. Storing styles, scripts, and images on a global CDN will improve website responsiveness for all users, but it will help the most for users who live far away from your primary servers. Cloudflare is the largest independent CDN, and there are dozens of competitors.
AWS offers its own CDN, but you can achieve some of the same benefits by storing resources in the appropriate regions. You can set up the same resources that you have in North Virginia at the Frankfurt data center and then use a load balancer to ensure that traffic is distributed accordingly.
Determining Customer Location
Once you have developed a set of resources for each target locale, it is time to make sure that visitors see the correct content. When a user makes an HTTP request to your website, that request will most likely contain a header that will let you read their IP address. While you could check for
REMOTE_ADDR headers, your backend framework or web server should have access to a library or module to perform this check. Always remember that HTTP headers are user-provided and thus should not be trusted for access control, because the user could be using a proxy or VPN or sending a manually constructed request. That said, assuming that all you are doing is serving localized content, you shouldn't have to worry about such behavior. The worst that could happen is that the user could see the page in the wrong language.
With the IP address in hand, there are numerous lookup services that map IP addresses to physical location. These lookups are usually reliable with a tolerance of a few miles. As IP ranges are an active market, corresponding physical locations can change from time to time. For example, many universities purchased or were granted large blocks of IP addresses in the early days of the internet and have since sold part or all of those ranges. Geolocation by IP address is an imprecise science, however, we only need to check if a user is in Germany. The method is generally sufficient for such purposes. This variable precision is another reason that testing your international content is essential.
That said, a simpler method of determining a user's nationality, language, currency, and other relevant settings is simply to ask them. When a user provides their shipping address with a purchase, you know their nation of residence and can serve content accordingly. Regardless of how you decide if a user should be shown the American or German site, you should always provide an easy toggle (for example, two flags in the nav bar). If you only provide IP-based localization, your New York business executive will have no way of ordering from today's drop if she is at a conference in Berlin.
Localizing your website is a cross-company effort that requires significant investment to make a great user experience in every country that you offer your products or services. A good localization improves your competitive position by diversifying your revenues; in contrast, poorly internationalized content can deal long-term negative damage to your brand in the new target market.
After putting in the work to create and distribute content in a new market, it is important to test and maintain the website. In the example situation, you could use WonderProxy to launch a proxy & VPN server in one of several German locations. You can use this server to connect to your website as if you were in Germany to test that the site contains the correct content, responds quickly (a proxy adds very little latency), and responds to your location. With this added confidence, the launch is ready to proceed.