Translation has come a long way since the days where everything was sent via excels and separate documents. Even so, organization, reviews, dictionaries and budgets can still make managing translation projects a daunting prospect. And to add to the complexity, translation teams often need to learn several systems to manage it all.
The first step of automating translations is to link your CMS to the Translation Management System (TMS) with a translation connector via an API. These either come along with the TMS package or are custom built to individual requirements. Translation connectors identify content which needs to be translated and, leaving the code out, send it it in a format like XML that the TMS can read so translations can start. Once done, the TMS sends the translations back to the CMS via the connector and the project is done.
Ideally a translation connector will let you configure workflows, mapping of languages and what kind of content is sent or not sent for translations as well.
Having only a connector can work if you want to translate everything automatically or periodically make all your new updates and you don't necessarily need to have an overview . The connector would not need a manual trigger or manual configuration from the user in the CMS. This can of course solve a percentage of the business cases out in the market but is not the usual setup required by clients.
Translation project management in TMS
Typically, a TMS will come with its own project management tool or dashboard. This gives a visual display where you can review and manage your projects. However, the overview you see is in the TMS not your CMS where you initiated the translation. It makes sense and would always need to be there so the translations team can work on all the projects assigned to them. This is particularly important where there is a large pool of team members required to translate all target languages.
The question remains how content owners can trigger these translation projects. For this, some kind of management system in their own CMS is necessary. Some companies opt to just have a trigger system, which indicates via their CMS which content goes to the TMS. The difficulty here is that if they want to manage the project itself - for example, to cancel it because they have made a mistake - they have to go to the other system. This can work if you have a thorough understanding of your own content and do not need a very detailed control of the process. The trigger is enough control for them and if they need more, they can go to the TMS project management view.
Occasionally we see teams opting for the TMS dashboard because of limitations of the connector, CMS or TMS and therefore the ideal solution is is to use both systems to manage projects. For example, the connector cannot read all project metadata from the TMS and can therefore not parse and display that in the CMS. The only way for translations teams to get the correct data for them to manage their translation projects is via the TMS project management dashboard.
These setups work, but still leave you with multiple systems and sometimes are kind of workarounds to make it all work. More systems mean more training (having to learn multiple UI’s) and lower productivity (spending time switching between systems). And workaround speaks for itself. So overall, these setups are not the ideal situation but can be acceptable for some cases - for example, when building a feature is way more expensive than working with the workaround.
Translation project management in your CMS
Having the complete management of translation projects in your CMS avoids having to train the team to learn multiple systems as they can just work within the UI they are familiar with. It also allows the team to manage everything in one place, being able to track project status from start to end in one translation project management dashboard.
Ideally a translation project dashboard should be capable of displaying any information you want and enable users to manage the projects with actions like starting, accepting quotations and, options like cancelling, pausing and validations.
More advanced features include reviewing received translations in your own system. This has the advantage of being able to see it on the actual page with the frontend code applied, hence putting it in context and allowing marketeers to make solid decisions and with the confidence that no frontend design issues will arise.
Another feature is having the possibility to update the translation memory in the TMS via your own CMS. Often translations can be context sensitive or need consistency across the site. Translation memory can help, because instead of sending revisions by email or manually updating in the TMS, you can indicate what content is considered memory in your CMS and send that back to the TMS.
So what is then the best approach? It really depends on your business case and processes, budgets, and systems you want to use. Very often it comes down to analyzing the processes first and plotting those on the systems capabilities. This will give insight into what is possible, what budgets are aligned with possible solutions and what limitations might exist.
Both CMS and TMS systems are often bought 'off the shelf' which means clients and translation agencies are compelled to follow their roadmaps. Even with custom proprietary systems, dependency on roadmaps remains but might be easier to manage. These factors are important to consider when reviewing what the ideal solution is from various angles and in what point of time.
At Luxus, we have a wide range of experience implementing translation solutions for our clients. We consult, build connectors and translation project dashboards in your desired CMS connecting it with any TMS that is required. We are very familiar with translation processes and configurations and can therefore implement the best solution for your business case. Whether you are a client with a CMS or a translation agency looking to expand and improve your offering, we're here to help. Contact us!