The Challenges of Building a Multilingual Website

Share this post

In this global economy, we really don’t need to be reminded that we work on the World Wide Web. The need for targeting clients in more than one country, or who speak different languages, has never been greater. There are multiple challenges which must be considered when building a multilingual website. In sitting down when our clients we need to ask a lot more questions, not the least of which is if unique site architecture will be required for each language. Will there be different pages for each language? How will the translation be achieved? Are there plans for a proxy server to handle one or more of the language sites? Once starting down this road it’s necessary to verify the solution for each separate challenge, or risk encountering a roadblock at each turn.

multilingual website

It’s also an evolving technology. Drupal 8 Core will have aid, support, and enhanced capabilities for multilingual sites and applications beyond anything that have been offered before. With contributed modules the developer should be able to solve most of the typical problems with multilingual websites. Currently, all our open-source technologies can handle these complexities, it just takes time. Ultimately it always gets down to the functionality of the website, not whether it’s multilingual. Like anything else, the greater the demand for a technology the broader the knowledge becomes, thus the easier it becomes to implement it. For now, though, I’d consider it a more senior level engineer task.

Immediate concerns

You must, of course, know where the translation will come from. There is the option of taking advantage of Google Translate to accomplish everything. Some do, although it’s far from perfect. Third party translation services are available to adapt the content, but you have to be wary that it has been accurately done. Some translation companies offer what is known as a proxy server. They negate the need for maintaining multiple sites. What a proxy won’t give you is the ability to customize functionality for the visitors who have found you in the other languages. It’s important to prioritize your needs.

Similarly, even the URL structure needs to be considered, so that every visitor can tell at a glance that they are on the right page. If using URLs with non-English characters, you’ll want to use UTF-8 encoding, so that all characters are encoded in Unicode.

There are even questions regarding latency issues. If you are hosting a site here in the U.S. that is getting the bulk of its traffic from Southeast Asia, there might be some performance problems. Maybe the server should be in Australia, or Hawaii. This may not be a big deal if the server is particularly powerful, but it should be considered.

Right-to-left languages introduce nightmare level challenges to the developer used to only left-to-right languages. It can completely alter the original design. In translating Farsi or Modern Standard Arabic, for example, the entire site layout may need to be switched. Developers also need to explore the availability of compatible fonts. Is there a font the developer can use for Amharic? There may be a font that supports your needs in Farsi, but does it have a corresponding bold or italicized version ‘- and does it matter? Verifying all these components requires research.

The ideal multilingual website

We’ve found that the ideal scenario is to have every site localized, so that the website isn’t a straight-up one-for-one translation. The audience wants, and expects, a fully relatable experience in which they are being spoken to as they should be spoken to. There are so many nuances, cultural and linguistic, for each target language (and dialect). You don’t want to turn off the audience that you are hoping to reach. That whole approach of clicking on a country’s flag, indicating a different translation is available, is now highly disfavored. The placement of a Mexican flag, indicating a Spanish translation, is bad form in uncountable ways.

We suggest a different banner for each language. The content should all be changed, from the text to even, at times, the website’s menu. Allow for as much flexibility as possible. It’s certainly going to be more costly. You’re maintaining multiple sites, not just one, but you probably have also opened new markets with each site. If there is a common technology and common functionality, then having multiple sites with multiple languages will be more manageable.

It gets down to a question of cost for return. Are you aggressively seeking to get a foothold in a particular market, or are you simply trying to establish a presence? If you are unsure, you might want to consider an overseas fact finding trip. Just take me along.

Related Posts

Config Sync Overview

Config Sync Overview

When Drupal 8 was released, it came with Configuration Syncing functionality. This has been a staple ever since for Drupal 9, Drupal 10, and beyond. Configuration Syncing was a game changer and one of my favorite features in Drupal Core.The days before config sync...