Some easy to avoid pitfalls when translating a website
I spent many years involved in the development and managing of large multilingual international websites, and over those years I discovered many pitfalls and learned some best practices.
In the selection of examples below you’ll see that awareness of regional, cultural and language differences can help shape the customer journey for a wide range of customers without causing confusion or even offence in the way that you present your web content.
Let’s begin with a simple oversight where efficient coding lead to some easily avoidable reworking.
Days of the week – Couldn’t possibly go wrong, could it?
A large corporate company had been running a very successful e-commerce website in English for many years, but they wanted to increase their effectiveness in international markets by producing translated versions of their website.
The translated websites would actually be variants of the English version, and operate on the same platform. In other words it would essentially be the same website, but in French, German and other languages.
Efficiency in coding
In web development, and writing code in general, it makes a lot of sense to produce chunks of code which can be re-used. This is an economical use of code which makes for easier expansion, maintenance, improvements, etc.
Reusable chunks of code makes it possible for that code to be used in other identical situations elsewhere on the website. Navigation bars and footers are two common examples, but there are plenty of other things a developer might write bespoke code snippets for, and use them wherever they want on a website without having to reinvent the wheel each time.
This website uses many such examples, whether it be for page headers, schema frameworks, contact form features, buttons for use on mobiles, page content listing bullet points, and many other things.
In some cases this will cause the same feature or content to display in the exact same way wherever that code is used on the website, and in other cases the code snippet may be dynamic, so different information and values can be applied to it and the output will be determined by that input, but within the framework that the code was written to reproduce.
The bullet points near the top of this page, along with the anchor links to specific sections of this page are an example of this. That method is used on many pages across this website, but in each case the number of links, the text on those links and the actual links themselves are determined by the values which are applied to a reusable chunk of code.
So reusing code is a great idea, but reusing code in similar but not identical situations might require some adjustment to the code to accommodate the additional scenarios it needs to handle, whilst also allowing its original purpose to continue without breaking.
Using a calendar on a website is an example of where reusable code can be applied. If you’re going to provide access to a calendar on several pages, why use many instance of that code when you can re-use the same one multiple times? However, on this particular occasion there was some economical use of code within the calendar module.
As any English speaker would agree, Saturday and Sunday start with the same letter, as do Tuesday and Thursday. So for first letter of the days, we only need MTWF and S.
So the calendar module was coded to use just these 5 letters, with the S and T being used twice for Saturday & Sunday and Tuesday & Thursday respectively.
So what?
Well when that website was translated into French, as very easily avoided problem occurred.
Tuesday = mardi
Thursday = jeudi
Saturday = samedi
Sunday = dimanche
So you’ll now see why code which uses T for both Tuesday and Thursday, and S for both Saturday and Sunday cannot be used for translations. It caused problems in Italian, Spanish and many other languages.
It wasn’t spotted immediately, but the lesson learned was to use 7 separate letters for the days of the week instead of trying to economise.
Mind your grammar!
I recall from my introductory school lessons in French many years ago that not all languages structure their sentences in the same way. For example whilst we could say red car
in English, the French would say voiture rouge
So if your web developers were to implement a content management system (CSM) which had one variable (or placeholder) for colour, and another for item, that might be a sensible way to handle things such as:
red car
red lorry
yellow car
yellow lorry
In English that would be fine... insert the name of the colour in the first variable (or placeholder) and the name of the item in these second placeholder.
But as we have already seen, would not work in some other languages, because the order of those words would need to change for it to make grammatical sense.
voiture rouge
camion rouge
voiture jaune
camion jaune
I realise that this is a very basic example for the purpose of demonstrating a point, but in the context of international multi-lingual websites, it needs to be taken pretty seriously. For example Manual Transmission
and Automatic Transmission
would need to translate to Transmission manuelle
and Transmission automatique
respectively.
Fuelling units of measure
Similar can be said for other things such as units of measure.
For example if you were to need to display the fuel consumption of a range of cars on your website, are you aware the whilst we are used to using terms such as 48mpg or 62mpg in the UK, even though we might be making fuel consumption references to the same makes and models of cars overseas, it is not simply a case of using the number (48 and 62) in these examples, and then using the translated equivalents of mpg
because that won’t work for everywhere else.
Keeping with French, for example, they are more familiar with litres per 100 kilometres than miles per gallon. And so displays such as 6.2 litres per 100km
and 7.7 litres per 100km
for fuel consumption is what would be expected.
Another related point to note that that whilst the UK and the US would both use the term mpg (miles per gallon), there is a difference in the actual volume of a gallon of fuel in the US compared to the UK. A US gallon the equivalent of about 0.833 the size of an imperial gallon.
In other words an imperial gallon is about 20% larger than the volume of a US gallon.
Tax – Included or not?
Another easily overlook point is whether the prices displayed should be inclusive or exclusive of tax.
For example if you were to go to the website of a retailer in the UK you should see prices displayed inclusive of tax. So a radio you see on Currys.co.uk displayed at the point of selection at £99 will still be £99 when you get to the checkout. (I’m ignoring any delivery charges here)
But if you go the similar retailer in the US, such as Best Buy, and select an item for $99, when you reach the checkout the final price would have increased due to the sales tax added.
In both case the final price will have been communicated before you commit to the sale and make a payment, but the key difference is that in the US the sales tax is typically added at the end, but in the UK and many other countries, tax (VAT) is included in the prices at the point of selection.
Such differences can have a big impact on international e-commerce platforms, such as those for hotels, car rental, airlines, etc., and the way it impacts users can vary based on where they live, where they’re travelling to, and whether they’re paying in full in advance or in part at the car rental location, hotel, etc.
Etiquette – Is it okay to be formal?
When a customer makes a purchase or a reservation, you are likely to be asking their first and last names in individual addresses on the booking or purchasing form. It might therefore make sense to use the name captured in the first name field and apply that value to your confirmation page and confirmation email, and say something like Hi David. Thanks for booking with ABC Travel
That casual informal approach can add a welcome personal touch in many cases, but be aware that it doesn’t work well for everyone. Some nationalities may actually take offence that they’re being communicated to in such a formal way by someone (or in this case a company via it’s website) who does not know them personally.
Awareness of this fact should allow you to quite easily factor in such formal or informal ways of addressing customers based on their nationality, and make use of their title too (Mr, Mrs, Miss, Dr, etc)
Formal: "Dear [title] [lastName]. Thank you for making a reservation with ABC Travel"
Informal: "Hi [firstName]. Thank you for making a reservation with ABC Travel"
Getting people to opt in
Generating and maintaining a list of potential and existing customers for purposes such as sending marketing information is an important process for many businesses, but international laws determine how that information is gathered.
The most common acceptable approach, certainly in Europe, is to provide a checkbox and accompanying message inviting people to check the box if they wish to receive marketing information. That is shown as the first method in the list below:
- Start with an empty checkbox and invite people to check the box if they want to receive marketing information.
- Start with an empty checkbox and indicate that the user should check the box if they do NOT wish to receive marketing information.
- Start with an pre-checked checkbox and indicate that the user should uncheck box if they do NOT wish to receive marketing information.
In many countries the first method is the only acceptable method, because it requires the user to explicitly provide consent. The other methods assume willingness to opt in, and they require the user to act if they do NOT wish to receive information. Whilst this method is acceptable in some countries, you'd be breaking the law in other countries if you used this method.
So do your homework on this, and remember that the rules apply to where that customer is based. That means that having customers in many different countries could make it necessary to have country specific methods to enable the most appropriate method of getting opt in consent, and possibly many other features, options, advisories, restrictions, etc., which need to be determined either by the customers country of residence or where they may be travelling to.
You'll learn more along the way
Let's face it. Knowing the kind of detail covered in this article right at the beginning of a huge project like the development of a multi-lingual international e-commerce platform can make the initial setting up of that platform far simpler then having to adapt an existing platform, especially when there are legacy systems involved.
However, the reality is... is the case with most projects... you are unlikely to know everything you need to know right at the start. Scope creep is inevitable and will need to be managed. The MVP (minimum viable product) is likely to change, and the expectations of the business (and potentially individual sections of the business which have their own targets and objectives) will need to be managed.
But that is life.
In Summary
So in summary, simply converting an English website into a translated version for use in an international marketplace requires more than a change of words. In some cases it is local culture which dictates how things should be displayed, whilst in other cases the differences are made mandatory by law.
Certain laws will apply to where the customer lives, and in other cases the laws will apply to the country they may be travelling to, in which case transparency of essential information is really important, because you don't want to misinform your customers or suppress information they need to be made aware of.
Clearly a single page article cannot cover all aspects of international ecommerce and translated websites. Shipping, import duty and other taxes, restrictions on the migration of certain kinds of products, age restrictions, etc., may all need to be factored in depending on your business.
If in doubt, get plenty of analysis done before committing. A good business analyst should be able to keep get you on the right track without you getting derailed.
Just make it as easy on yourself as possible so handling updates, additions and variations can be accommodated without major reworking, and with minimal impact on other parts of the website and supporting process.
And for heavens sake document everything and make sure it’s kept up to date!
Can I help?
I have more than 27 years of prefessional web experience, with 20 of those spent developing and managing multilingual international ecommerce websites with turnover in excess of $3.7 billion
If I can be of any assitance with the evolvement of your international ecommerce website, please feel free to contact me directly:
01406 373511
daron@targaweb.com
Thoughts, suggestions or comments?
Comments or Feedback?
If you have any comments, thoughts or suggestions about this article, please let us know.
Use the social media buttons below to share this article.
Fields marked with * are mandatory
I'm Daron Harvey, founder of Targa Web Solutions, specialising in website management, testing, auditing, troubleshooting & consultancy. I'm now in my 28th year of professional website production, testing and eCommerce best practices, including management of large multi-lingual multi $Billion global websites. No AI was needed or used to write the content on this page!
