As a website grows and becomes more popular, it's only natural to want to reach out to new audiences. But how do you do that? Should you translate your site into other languages? If so, how will you translate the content of each page? What happens when you need to change your existing content later? Running a website in multiple languages can be a lot of work; careful planning will help ensure you don't end up with a web presence that is hard to manage.
CSA did a research survey in 29 countries and found that:
- 65% prefer content in their language, even if it's poor quality
- 67% tolerate mixed languages on a website
- 73% want product reviews in their language if nothing else
Multilingual, Internationalization, Localization, or Translation?
Are these all kind of the same thing? While they may often be used interchangeably, in reality internationalization includes localization which requires translation.
Internationalization is making software or systems usable for people who speak different languages. Many systems don't do this on their own, and it can be quite difficult to gracefully add the tooling required to serve audiences in different languages at all after the fact.
Multilingual is similar to internationalization, is it even possible to serve multiple locales with unique languages?
Localization is actually using the internationalization features to serve an audience in a particular locale (country or region.) You might use the same language (English) across multiple locales (UK vs. US.)
Translation is the process of producing matching content in two languages.
So to make this more real:
Your Content Management System may or may not be "multilingual" or "support internationalization" natively. There may be extensions that promise to add "multilingual support." Assuming there is some way to do this, you'll then start a process of localization where you consider what is really required in serving your audience. This will of course involve translating content to some specific languages, but may also include other concerns like date formatting or even including/excluding some content as it makes sense for specific markets.
Interface vs. Content
Keep in mind there are two main parts to consider:
- Translating your User Interface (UI). Can the CMS software you're using run in multiple languages for your editors? Can any interactive functionality in your visitor-facing website be delivered in multiple languages? This might be login pages, my account areas, dashboards, any eCommerce functionality, etc.
- Translating your content. Can the actual content you serve to audiences be localized as well? Are there tools for managing content in multiple languages easy?
Translating your UI
Running your CMS and functionality in your app across multiple languages will be vital if you've got content contributors who are not native English speakers. People are more effective and productive working in their native language.
Concrete CMS is created to support international teams. The CMS itself can be fully translated and has been into dozens of languages.
The term "string" refers to a short line of text in programming. Every application has strings. An application that is internationalization ready makes sure all of those strings can be swapped out in a language file. Take a look at Concretes UI, there are side menus, forms, and save and publish buttons all with text labels. Those are strings, and they're all wrapped with a function that makes it easy to swap in a new language file depending on who has logged in and make the application appear as if it was designed just for their language. 
Most well-designed applications should be able to support this UI translation. Programmers can pull the strings out of their code into centralized pools. These lists of strings can easily be translated.
If you have content contributors who are not native English speakers and would be more productive in another language, being able to run your CMS or offer any interactive functionality in multiple languages will be crucial.
Translating content
There are two basic approaches to managing translated content, highly structured and organic.
The way the string translation works (above) is highly structured. You have a very clear bit of text and for every language you're going to provide you need a translation for it. This is the way a programmer naturally will think, and it makes sense for some types of content.
For example, a product page likely has consistent structured data like product name, short description, images, specs, features, etc. If you're serving this product to multiple locales you'll likely want a translation for every field.
As you think about the other types of content that end up being in websites, a lot of it may start to feel a lot more organic. A contact or about page might change pretty dramatically from country to country. Category pages or lead conversion pages might have entirely different approaches as you try to serve the expectations of that market. You might not even offer some products in some locales, so your site architecture will change across the translation.
When thinking about how you want to manage translations for these organic pages, you really want more flexibility instead of a 1:1 string translation.
It's important to spend some time with your content plan and editor team to decide how you want to handle this fundamental architecture choice. For some cases requiring all content to always be 1:1 translated to every language makes sense, while in other cases maintaining a different tree of content pages for each language is a better option.
Keeping content fresh as it matures over time can be a challenge.
A big issue with internationalization is that keeping your Content fresh as it matures over time can be challenging. When you change content or add a page in one language, is there reporting to let content owners know it needs to be translated? Is it easy to find connected pages in different languages?
The time required to keep multiple languages accurate is significant.
How does Concrete CMS handle internationalized content?
Concrete CMS includes a powerful way to manage content across different languages using different trees in the core.
Every page in one language tree can easily be aliased to another and then overridden with localized content. There's tooling and reports for keeping the different site trees organized and fresh, but you can also easily fork one language to become different from another.
The Page Report tool shows which pages are linked across locales:
This flexible approach is excellent for many scenarios, particularly when you have a distributed team with local product/site managers who want to collaborate but also have the flexibility to make their own locale.
Conclusion
Internationalization is not easy.
Most modern web browsers offer a built in automated translation service that works alright for the casual need.
Ensure you've got an international market and the resources needed to manage multiple languages. If you do, consider not only having a CMS that works in different languages but also the approach the CMS takes to managing content across languages.