How can we help you?
Let's talk over your ideas. We'd love to hear from you
hello@pobl.tech
© Pobl Tech
15 April 2021 — Gweirydd
Building a multilingual website may have more considerations than you first think. If you haven’t developed a multilingual website before, we’re going to cover a few things to consider before and during its development.
These are all in relation to building websites that fall under the Welsh Language Standards.
There are a few essentials you will need to have in place if you;re creating a multilingual website.
As you may well know, your multilingual website will need a way of switching between languages. This is usually a toggle of some kind at the top of the page. Even with a simple toggle, there are a few considerations:
Firstly, make sure that your language toggle takes users to the same mirroring page in another language. The toggle should not be defaulting back to the homepage.
When working with two languages, a recommended approach is to have the toggle as a single button in the opposite language to the page language. Such as Cymraeg/English, or English/Français. It will switch the page to the other language once pressed.
When there are more than two languages, the toggle may feature a drop-down menu of language choices.
Related to the above point, avoid using flags to represent a language. A recommended approach is to use the language names in the native language (e.g. Cymraeg/Français). This avoids political complications or misrepresentation.
Users will easily identify the relevant language they need.
You will need to ensure that the toggle is clearly visible on the page – this includes smartphone and desktop. Traditionally the toggle appears on the top navigation bar of the website.
Note, with smartphones: do not hide the language toggle within the dynamic menu section. If you hide it away within the menu, the user must always press into the menu to find the language switcher. Try building the toggle in a way that allows it to be visible on the same page without tapping elsewhere.
There is a fourth consideration, which is to give users a language choice before entering the website or digital device. This is especially relevant for users who follow links from search engines or links from another website. Those who do are nearly always taken to the predetermined language of the link in question.
Note, this option is not a common practice or expected by the common user. Having a language selection screen would be a preference for you and your organisation.
If you do choose to include it, having a language choice upon entering a website is useful to users who have clicked on an external link. Those users may not have had a language choice on their journey. A relevant example of this is a search engine such as Google, which will more than likely serve the more popular language over the other – creating an inequality. The same is true when following links from 3rd party websites. The likelihood is that the more populous language will be used as a destination behind a link.
This could be an important factor in countries where a minority language is under pressure and will not be served by search engines as the main link. Allowing your users to make their choice before entering the website will always give them a choice.
If you’re considering some additional functionality you may need to consider these.
Having a website able to switch between languages may not always be enough when handling more advanced functionality, such as blogs.
When all your website’s content is managed fully by you with no user input, you should be looking for a fully multilingual solution. Developing the capacity to create a blog in multiple languages should not be a problem, but it’s usually something additional for you to input into your development scope.
This can get complicated when user-generated content is also being used, such as users commenting on a website post or talking in a forum. With these instances, having the navigation being fully bilingual should be a starting point. The remainder will come down to circumstance and your language requirements.
This is something to talk through in detail before including such functionality on your website.
If your website depends on a search function, consider what language it’s searching for within your database. Is it searching all the options in all the relevant languages? Or only doing it in the language the user is using? What happens when someone searches for a term using language 2 when using the interface in language 1?
For example, if you’re searching for a place name in English on the Welsh side of the website, will it only be searching for the Welsh name within the Welsh database? If so, “Swansea” will not be appearing on the Welsh side of the website, it will only have “Abertawe”.
If this is something you need to consider, remember to discuss it through with your developers. They will be able to apply a language search query across multiple databases to give the user the result they are looking for.
This is not something that is usually automatically given to you as default, so make sure you ask about it.
Again, integrating with other platforms can be complicated when multilingual considerations are at play. If you have firm language requirements, you may need to source a solution that gives you a multilingual solution or data feed. Or if there are no providers that can fulfil your language requirements, you may need to develop a solution yourself – which could take a lot of time.
Make sure you’ve outlined all your needed integrations early on when scoping your project, and look into the language elements before you start integrating or using them.
An element that is nearly always forgotten during development is the language requirements you may have on your data and communications strategy. Do you need to be contacting people in the language of their choice in future? Will you be sending welcome emails and additional information through the website? Are you sending out password reset messages? If so, you will either need to send out multilingual messages or will need to be capturing the user’s language preference beforehand to let you know what language to serve.
If you’re capturing this language data this will need to be done clearly, similar to how clear GDPR is on signing up for marketing materials. It’s not acceptable to be capturing this data based on assumptions such as what language users were using at the time or mobile phone language settings. Users need to make this decision consciously and then captured by the system. They need to be choosing their language by using a selection function such as a tick box or a dropdown.
The user also needs the ability to easily change their language choice, with that change instantly updated in your database. You may need to build in profile or accounts to help you save the data if your website is more advanced. Unless you can work with cookies, this may be something else to add to your scope if it isn’t already there.
Another often forgotten element when building a multilingual website is the URL. If you have multilingual requirements, then you may need to be using 2 different URLs in 2 different languages. There are 2 levels to this;
When you have a brand name (such as ‘Tesco’) that won’t have a counterpart in another language, your main consideration will be the slug of your URL. Don’t fall into the trap of defaulting the URL as a single language slug with “/lang2” at the end to make it different. The slug is usually the title of your page, and this should appear in the relevant language.
Also, make sure that you can edit the ends of your URLs to be fully multilingual. This is especially relevant with blog content you may write for a multilingual website.
The second instance is where you have an URL that would differ between languages, which in turn will change your URL when a language switch occurs. As an example, the Welsh Government will be translated into other languages as a different name altogether. In this instance, your URL will also need to be different for all languages. There are different technical solutions to this one, and you will need to talk it through with your developer as soon as possible. It’s much easier to do it the first time around rather than to go back and redo it.
Depending on your language requirements, you may want to be offering your staff the option of working in their language of choice. This will mean your CMS will also need to be multilingual.
This is easier than you think, as there are CMSs available in numerous languages. You can also create your own multilingual CMS.
When everything is built and ready to go, the final task is making sure you’ve got great website content and that every single page has been translated.
But, there are things you should not be doing. Do not auto-translate your whole website by using something like Google Translate without any proofreaders or content writers helping you. Don’t ask a colleague who happens to speak a language to translate your whole website. Do not ask your son or daughter who happens to be learning the language in school to translate your website.
Make sure you have adequate language skills at your disposal through content writers and professional translators. Even after receiving professionally created content, make sure you have someone to check your website within context. This is especially true of your navigational elements and buttons, as some translation may need to change within a particular context. It’s not the 98% that you got correct that will catch you out, but the 2% that went wrong.
Finally, you should not be launching your website without all your languages translated and included on your website. So, make sure you’re getting your content translated early enough in the process. Not doing so could mean standing around for a while not being able to launch your website on time!
Building a multilingual website with language requirements is not always easy, especially if you haven’t done it before. Hopefully, we’ve covered a few useful topics in this article that will allow you to consider these elements beforehand. As with many things, it’s far easier when you do it right from the start.
Remember to get in touch if you have any questions
Let's talk over your ideas. We'd love to hear from you
hello@pobl.tech
© Pobl Tech