In this blog post, we will explore the benefits and challenges of key-based vs file-based translation management systems (TMS), and how to choose the right tool for your localization projects to achieve a successful continuous localization workflow.
With the rise of Agile methodologies and continuous delivery practices in software development, the demand for continuous localization and key-based translation management systems is on the rise.
But some localization tools (like CAT tools) have failed to keep pace with this approach and are still built on a file-based system.
Continuous localization ensures that the content is always release-ready, while Agile localization may require waiting for the completion of a sprint before releasing the content.
Miguel Sepulveda, Global Localization Manager, King @ yolocalizo
What is file-based TMS?
As its name suggests, a file-based TMS stores translations in files. Typically, these files are in XLIFF or JSON formats, and they contain all of the content that needs to be translated.
The typical translation life cycle of user documentation articles in a file-based TMS
Translators download these files, translate the content, and then upload them back to the TMS. This approach requires file extraction and import/export processes to manage translations, which can be time-consuming and prone to errors, particularly for localization projects with frequent updates.
Challenges of a file-based TMS process
The content lifecycle in a file-based system can also be slow, inefficient, and lead to high costs. Here are some challenges that you might run into:
- Extra steps involved. Each time an article is updated, it is treated as a new project that requires filling out an intake form, setting up a Jira or Trello ticket, and configuring with the correct settings and contributors.
- Repetitive and time-consuming. The entire file has to be imported, and the translation memory must be reapplied from scratch, even when only one sentence has changed.
- Error-prone. The TMS’s logic for deciding which memory entry to apply is unreliable as it depends on a multitude of factors. This may lead to a different translation for a source sentence that didn’t change.
- Double work. Translators either have to process the entire file, even if only one sentence was changed, and previous translations can be viewed and edited, or the file has to be specially processed to hide existing translated content and then reconstructed after the translation is complete.
- Additional QA steps are needed to ensure that no errors or unexpected changes have been introduced during the process.
- Extra admin costs. The resulting unnecessary costs are associated with admin, translation, and QA effort.
- Delays. Changes to translated articles take much longer to publish than is ideal.
Benefits of a file-based TMS process
File-based TMSs are still widely used and can be suitable for some localization projects, especially those that involve large files or projects with fewer, less frequent updates. Here are some benefits of a file-based TMS:
- Familiar. File-based TMS is a familiar and well-established approach that is widely used in the localization industry.
- One-off updates. They can be suitable for certain types of localization projects, particularly those with fewer updates or larger files, as they allow translators to work with the entire file in a single go.
- Easy set-up. They can be easier to set up and use than key-based TMS, particularly for smaller teams or projects.
- Robust features. Many file-based TMS have robust features for handling different file formats, content types, and integrations with other tools.
What is Key-based TMS?
A key-based TMS uses a unique identifier, called a key, to manage translations.
Instead of storing translations in a file, a key-based TMS stores translations as individual key-value pairs in a centralized database. This approach enables translators to work on small, discrete pieces of content rather than entire files, making the localization process more efficient and flexible.
The typical translation life cycle of user documentation articles in a key-based TMS
With a key-based TMS, developers can easily integrate the localization process into their workflow by simply tagging the content with a key. This eliminates the need for manual file extraction and import/export processes, reducing the risk of errors and ensuring that the latest translations are always up-to-date.
Challenges of a key-based TMS
While key-based TMSs offer many benefits over file-based systems, there are still some challenges that come with this approach:
- Learning curve. Teams may need to adjust their workflows to accommodate key-based systems, which may require some learning and training.
- Managing keys. As the number of keys grows, it can become difficult to manage and organize them effectively. This can lead to confusion and errors, especially if different teams are working on different sets of keys.
- Integration. Key-based TMSs may require custom integrations with other tools, which can be time-consuming and costly to set up.
- Content changes. If a key is used in multiple places throughout the content, changing the translation of that key can have ripple effects throughout the entire project. This can make it challenging to ensure consistency and quality across all content.
- Context. Keys are not always self-explanatory and may require additional context to be fully understood. This can be especially challenging for translators who may not have the full context of how the content will be used.
Benefits of a key-based TMS?
One of the key advantages of using a key-based TMS like Lokalise is its versatility. While it’ is’s a popular choice for product teams working with code repositories, it’s also a great option for teams managing any type of content held in a CMS. Overall, working with a key-based TMS is faster, more efficient, with lower effort, cost, and risk than a file-based TMS. Let’s take a closer look:
- Reusable project settings and contributors. Project settings and contributors can be reused, saving time and effort on administration and quality assurance.
- Single source of truth for translations. The project’s editor serves as the source of truth for translations, not the translation memory. This prevents unintended edits to existing translations in keys that have not changed.
- Less effort. Only the delta of new or changed sentences needs to be translated and reviewed, reducing turnaround time and costs.
- Immediate availability of the latest source text. If changes are synced before the translation is complete, the latest source text is immediately available for translators.
- Ability to flag changes. If changes are synced after the translation is complete, the status is immediately flagged and marked as unverified. It can be included for editing in the next scheduled handoff, allowing for more accurate and up-to-date translations.
Conclusion
Overall, a key-based TMS like Lokalise provides greater flexibility, control, and scalability than a file-based system, making it a popular choice for teams looking to streamline their localization processes and achieve continuous localization.
By managing translations by keys instead of files, teams can reuse project settings, reduce double work, and ensure that existing translations are not accidentally overwritten.
One of the key advantages of using a key-based TMS like Lokalise is its versatility. While it is a popular choice for development teams working with code repositories, it’s also a great option for teams managing any type of content held in a CMS.
In conclusion, key-based TMSs offer significant advantages over file-based systems, enabling teams to streamline translation workflows, reduce costs, and improve translation quality.
How Lokalise overcomes key-based challenges
- Lokalise is an easy-to-use TMS, and allows users to organize and tag keys efficiently
- Integrations with popular tools like Jira and GitHub so teams can sync translations quickly and seamlessly
- Contextual translation features, such as screenshots, the Figma plugin, and AI-assisted translations so you can give translators context to ensure accurate and high-quality translations
FAQs
What happens when someone makes changes to translated articles directly in the CMS?
When the TMS and CMS are decoupled, it requires manual effort to apply corrections directly to the translation memory, with the hope that the changes will be reflected in the article during the next sync. However, an integrated tech stack can pull the changes made to the translated article into Lokalise at the same time as other changes to the source content, thus automatically updating and keeping the translation memory aligned.
Is it time to move away from offline document authoring?
As more teams switch to cloud-based, collaborative tools like CMSs and Figma, the idea of once-and-done content authoring in offline file formats is becoming outdated. A modern tech stack requires a connected, collaborative TMS that supports continuous localization in a streamlined and repeatable way. Lokalise’s key-based approach supports version control, ongoing updates, and collaboration, enabling each unique key to exist independently of a file or be associated with many files as a shared component.
What does this mean for file-based CAT tools?
File-based CAT tools and key-based tools like Lokalise have their pros and cons, and they are both fit for their original intended purpose. However, the nature of the job has been changing in a way that increases the relevance of key-based tools like Lokalise in your tech stack, regardless of whether you work on software content.
