Translating dynamic content is often challenging.
It’s typically stored in a database, and to translate it efficiently you’ll need to connect to other tools. A process that might involve:
- Setting up APIs for your systems to communicate
- Converting data into a compatible format
- Creating automated processes for content extraction, translation, and reintegration to your database
- And monitoring and maintaining the integration, considering fallback mechanisms
Yup, there’s a lot to set up before you even begin translation, and processes can get even more complex with time. This is where software internationalization comes into play, as it lays the groundwork for handling dynamic content efficiently.
So we’ve put together this short guide to set you up for dynamic content translation success, whether localizing software, apps, games, or anything else!
What you need to consider before getting started
The database architecture
Firstly, it’s important to understand and consider the architecture of the database where you store dynamic content, and any system(s) it’s connected to. When setting up a multilingual database and managing the languages it contains, you need to be able to accommodate any changes made within the database itself, or in connected systems.
Available database translation workflows
Secondly, unlike standard translation, database translation requires the construction of an entire workflow, with careful consideration given to where the data for the synchronization logic will be stored. This data could reside within its independent microservice, in the database itself, or even exist within a key in Lokalise.
What will be your single source of truth?
Thirdly, you need to decide which system will be your single source of truth for content. For your source content, you might opt for the database where it’s already stored or a user-friendly UI layer atop your database. You might even choose Lokalise.
For translated content, Lokalise is typically the go-to choice. But your database could also serve as the home base. To help you make the right choice, consider how efficient your localization process needs to be.
How do you want to synchronize your data?
Lastly, you need to determine the synchronization style. Do you want to use a full sync, which processes all the content in your database (a more suitable choice for small-scale projects), or a delta sync, which processes only the new and updated keys in your project?
Best practices for translating dynamic content
Below, I’ve outlined some best practices for translating dynamic content in translation management systems, though you could apply some of these best practices in other tools you decide to use.
Store dynamic content in a separate project
When it comes to project organization in your single source of truth, I recommend storing translations of dynamic content in a separate project.
This project should run parallel to the project you’ve created to handle static translations. If you have a high volume of dynamic content, you might want to categorize it into separate projects based on type.
At Lokalise, you can create as many projects as you like at no extra cost. So it’s a great option if you have high volumes of dynamic content.
Create a logical key structure
While managing dynamic content, it’s essential to understand the key and value structure. Set aside time to formulate a logical key structure for your dynamic entries, aiming to use a unique database identifier within the key name, such as:
form.1.title
form.1.details
form.1.overview
form.2.title
form.2.details
form.2.overview… and so on.
The key naming pattern must be unique within its given context in your project. The unique naming structure can also help give context to translators. Key tagging can also be used, making it easier to manage and structure keys during the localization process.
Check out this comprehensive guide to key naming.
Outline your content syncing process
To keep your dynamic content translations up to date, set up a process for syncing your content.
You might opt to do it manually, scripted, or fully automated. This might change over time, but as long as you follow the same logic, you won’t need to restructure your database.
Group keys when uploading them
When it comes to uploading content, start by grouping your keys and original content. You can either gather them into standard file types or organize them as individual keys.
See all supported file types in Lokalise.
Then you can directly upload this collected data to your translation management system, using an API if you prefer.
Tip: If you need to provide further context for translators you can create new key entries in Lokalise and add screenshots or descriptions to your keys.
Keep only one version of your source content
The rule of thumb for managing content translation and localization is to revise only Lokalise’s translated versions of the source content. Any changes to the source content should be done directly within the database. This practice helps prevent any potential versioning conflicts.
Export easy-to-parse file formats
Retrieving translated entries should be easy. In Lokalise, you can simply use the export function or download endpoint. Choose a format you are comfortable with, ideally easy-to-parse formats, or even export at the key level directly using the translations endpoint. Once you have secured your translations for each location, simply store the content associated with each key and locale in the database.
What about database design for multilingual data?
If the database only contains one language, decide on the best location for your translated content.
In the world of database design for multilingual data, there are three main approaches:
- Localized columns within the model
- Separate translation tables
- Completely separate database
The choice between a straightforward or more sophisticated approach will depend on your app’s specific needs and the applications connected to your database. Backend services “consume” the multilingual process and should be able to work with the multilingual structure of the database.
Let’s take a look at each approach and when you might use one over the other:
The column method
Localized model columns, such as ‘title_en’ and ‘title_fr’, allow normal queries and subsequent fine-tuning in the application layer. This approach is ideal for smaller apps with fixed locales.
The separate tables method
If the number of locales is likely to grow, using separate tables per model for translations proves more accommodating. Although this entails complex querying, it provides excellent adaptability—locales can be added indefinitely without disturbing your models.
The separate database method
This approach involves housing all the translations in an entirely different database. While this means managing an additional element, it can offer greater separation and flexibility, especially for larger projects with numerous languages and locales.
Irrespective of the chosen approach, remember to define your tables and text fields with utf8mb4_unicode_ci for full, case-insensitive Unicode support. Additionally, opting for the UTC format for dates and times, coupled with a time zone offset application at retrieval, ensures user relevance. Optionally, a secondary time zone offset column can be included for the logged time zone.
Successful project management practices
Before diving headfirst into your localization process, focus on project management best practices. Begin by gathering your specific requirements, which will help you outline your localization process.
Want your localization process approved by a Sales Engineer at Lokalise?
Get in touch and I’ll let you know if you’re on the right path.
Next, it’s time to prepare the success criteria for your proof of concept (POC). These criteria will guide your POC project and serve as a benchmark for the project’s success. Once the POC project is executed, evaluate the outcome against the preset success criteria, and use your findings to adjust your localization process for optimal efficiency.
Lastly, prepare your implementation project, which should incorporate the insights and refinements from the POC stage. Remember, a robust plan and iterative refinement are keys to success in the localization process, especially when dealing with dynamic content translation.
Final word
Navigating the world of dynamic content translation can be challenging, but Lokalise brings simplicity and efficiency to the task.
Successful localization is about effectively managing both the content and its underlying processes. If your project is small or expansive, Lokalise is a reliable partner, supporting you in managing all your content translation efficiently and intuitively.
See how easy it is to manage your dynamic content with a free 14-day Lokalise trial.
