Supporting multiple languages and regions isn’t easy.
First there’s the obvious challenge of translation. If you intend to market internationally you will need to support a range of languages, or language variants to be more precise – the Spanish spoken in Mexico City is not the same as you’d hear on the streets of Madrid.
To further complicate things, some countries speak many languages. To talk to a Belgian audience you’ll need to translate your content into Dutch, French and German – and a further nine non-official languages if you want to go the whole hog….
You may also need to adapt your message to cater for local laws and cultural differences or adapt publish timings for local time zones. Multiply this by the number of channels you wish to support, and any internal and external stakeholders involved, and you have a lot of moving parts.
The headless content management approach taken by Dynamic Content helps address the multi-channel complexity with a create-once-publish-everywhere approach, but what else should you consider when implementing localization?
Translate Fields or Content Items?
The key decision you need make is whether to adopt a field level or content item level approach- or a combination of both. So, what’s the difference?
Field level translation
Simply put you model your language variants inside each content item.
The content item above has a translatable ‘Header’ property, with language variants for each of the target locales. Other field types such as images can also be localised.
Item level translation
With this approach you start with a content item and then create separate localized variants for each language.
Whichever approach you choose, Dynamic Content simplifies the process by automatically creating the necessary fields or variants according to the locales set up on your hub.
See the docs for full details: https://docs.amplience.net/production/localization.html
So, what should you be considering which type of localization to use?
1. How many languages are you supporting?
If you are single team translating only a small number of languages, and you don’t have a requirement to publish different languages at different times then a field level approach may be the simplest option.
As the number of languages grows, the editing experience can quickly become unwieldly. Take for example a simple content item with 3 text fields (header text, call to action, description) – if you have 10 languages you will end up with a content item containing 30 fields!
To take away some of this pain Dynamic Content allows users to filter out the locales they aren’t interested in:
2. Are you translating or localizing your content?
Strictly speaking translation is defined as a direct conversion of your content from the source language to the target language(s) whereas localization involves changing the content to cater for the local audience, to take account of region specific pricing and promotions, or to reflect product availability in different markets, for example.
Content item localization offers the most flexibility in this regard as it allows for structural differences between each language variant (within the constraints of the content type). For example, your blog could be structured as paragraph-video-paragraph in the UK and as image-paragraph-video the US. With a field level approach you are more constrained, the content could still be translated but within a fixed structure.
3. Who will be translating your content?
Many organisations have in-market teams who translate content for their region. In this scenario an item level localization approach often works best as each language variant is a distinct item and no dependencies are created between teams or languages.
Dynamic Content can be configured so that localized variants are automatically created in different content repositories according to their locale, making it easier to share translation work among different teams. Restrictions can also be applied to ensure teams can’t edit content in the wrong repository.
Be wary of utilizing a field level approach across distributed teams, you may find yourself waiting for all languages to be translated before you can publish the content item (it’s possible work around this by republishing content item as each language is completed but it can get confusing) and you can’t prevent translators editing the wrong language by accident.
If you are use an external translation provider they will typically employ specialist translation memory software to manage the process and the key consideration is how you will transfer content to and from your CMS. Dynamic Content takes a modern webhook driven API to API approach to integration. The translation process is triggered within the CMS, typically by a user setting a content item’s status to a defined value, for example: ‘Ready to translate’. The content is then automatically sent for translation and returned once complete.
Both field and content item approaches can be supported, but content item localization gives the most flexibility in that each language can be translated independently. In circumstances where you might want to use multiple external providers it also provides the ability to restrict which repository each can write to.
If you intend to utilise machine translation, for example Google Translate, we recommend the same type of approach.
4. Is the content going to be published at different times in different regions?
This one often catches people out. Managing content across multiple time zones is tricky and different language variants may need to be scheduled at different times in different regions.
This is another scenario where an item level approach often makes the most sense as languages variants can be scheduled and published independently. This is more difficult with a field level approach as all the translations are bundled into the same content item.
If you are scheduling across multiple regions don’t forget to set up time zones in your settings, this allows easy switching between time contexts, taking the headache out of scheduling and previewing your content.
In summary…
Field level localization is a good choice if:
You have a single site and support a small number of locales
You have a single in-house team that handles your localization
You don’t have a requirement to schedule and publish content for different locales at different times
Content item localization is a good choice if:
You have many sites and support many locales across those sites. Typically, each site would also have its own set of slots
You use several teams for localizing content into particular locales or groups of locales
You use external localization providers and want to restrict write access to only those repositories that each team is working in
You want to have the option to schedule and publish different locales at different times
Some final advice…
There’s no one ‘right’ way to do it. As we’ve seen you need to weigh up several factors before choosing the approach that works best for your organisation. Don’t be afraid to choose a hybrid strategy according to the needs of different use cases.
Start small. If you are working with a significant number of locales be aware that they will act as a multiplier for any inefficiencies in your process. For this reason, it’s often wise to take an agile approach and prototype across a subset of languages or teams to iron out pain points before rolling out further.
To find out more about how Dynamic Content supports localisation check our docs.