Running a Translation Management System (TMS) is the first step towards a global success strategy. It accelerates automation, increases cost reduction, and allows reaching more customers aboard who are not very keen on consuming non-native content.
The second step is to understand how it works, so that you maximize its service output. By using, for example, previously translated strings – known as Translation memory – or adding Reporting and analytics, you can compare how the localization strategy has made a significant positive difference to the KPIs or improved the customer onboarding experience.
One last step is to choose your ideal type of TMS to localize your content. Two options are at your disposal: a File-based or a Key-based TMS. Let us try to see them in a comparative perspective and balance their pros and cons.
File-based Translation Management System
In a File-based TMS or File-based translation, we have our content as files that come as a whole. As part of an automation process, the content gets translated by referencing the translations from those specific files. The translation process can be done either by translators or computer-aided tools bundled within the platform. If there is a translated content for a particular locale, it can be loaded as part of the request.
Some of the most traditional approaches to localization use exactly this method. One typical example is gettext tooling with PO and MO files. This kind of TMS software offers numerous advantages, but it also has some obvious drawbacks.
- Fast to execute: As the content is already bundled with the translation, we just load it; this happens because the content may be cached or pre-rendered as part of the deployment process.
- Conventional: Using PO, MO files, for example, to manage the translation is widely and well supported.
- Easy to automate: You can set pipelines to bundle the translations together.
- Not very dynamic: At almost all times, it requires a new deployment if some of the content layout changes.
- File format specific: The file formats or protocols usually dictate the features available. Also, not all file formats are easy to use and supported.
- Not very extensible: As we have a more coarse-grained control, we also have more difficulties getting into details and extending them to support multiple ways of handling translation keys.
- Some inconveniences: You need convention rules for translating certain strings in order to be translatable.
In general, File-based TMS software is suitable for most everyday use or for developers wanting to have a more complete control of the localization process.
Key-based Translation Management System
In a Key-based TMS or Key-based translation, we have our content referenced as keys instead of files. These are saved in a database or a storage that is later retrieved per request. For example, when a client has specific locale preferences and requests content that matches the current locale, then the content is fetched and displayed. The site admin can update the content without needing to redeploy the site as the content is referenced from the same store. Translators can also assign new tags and projects that reference to existing translations, which makes the management platform easier to navigate and more natural to work with. The customization does not end there as we can group them by feature or semantics, so that we can track them more efficiently. Let us take a look at the advantages and disadvantages of using this kind of TMS software:
- Dynamic: Updating the content and the translations is easier as the queries and the command share the same document or tables in the database.
- Easy to use: No developer skills needed. Adding or tagging translations gives more semantic control of the translatable content.
- Semantic and more natural to follow: Tagging and grouping offer a more natural way to work with translatable content.
- Extensible by design: Handling keys instead of files gives a more fine-grained control of the localization process.
- Not easy to automate: There is little or no automation in the process.
- Little or no ecosystem or standardization: There is no clear way on how to implement this in practice and every framework has its own ways of providing that leading to a lot of fragmentation.
Overall, Key-based TMS software is suitable for content creators who want a quick and easy localization platform and developers wanting a more efficient way to manage the i18n of their apps.
What Translation Management System Should I Use?
It all depends on what kind of localization experience you want to offer to your users. If you want to offer a developer-centric and conventional approach to localization with tooling that already exists, you can use a File-based TMS. If you have content marketers or developers who want to do something more advanced and functional or just want a quick and easy solution for the content they want to translate, you can use a Key-Based TMS. What is also important is to have an agile flexibility to update translations without any deployment and the easiness of customization. This is exactly where Phrase shines and I recommend taking a look at what they have to offer.
Using the right translation management software (TMS) will make or break your localization experience and process. Taking time to search for the right platform that will allow managing your worldwide team more effectively and with reduced costs is crucial. Luckily, the Phrase platform has got us covered. Feel free to learn more about Phrase, referring to the Getting Started Guide.
I hope this article helped you understand the different TMS types out there. Stay put for more articles regarding i18n and l10n here.