Any enterprise competing in global markets today is experiencing an explosion in content as they strive to create compelling customer experiences. To scale and deliver at market speed, companies are investing in Content Management Systems (CMS) that empower content creators, manage a variety of assets, and publish across many channels. But as capable as these content systems are, translation is not always a key feature.
How do you know if your CMS is translation ready?
Spartan Software would like to help. From our long experience connecting content systems to translation, we’ve compiled a list of questions to assist decision makers evaluate CMS capabilities for handling global content.
1) Is my CMS internationalized?
At a minimum, your CMS should store and display content in any language including double-byte characters, complex scripts, and right-to-left languages. It should also support international date, time, calendar, currency, address, name and title conventions. Translatable text should be externalized from code and available for extraction. Proper internationalization is expected for any software product these days, but gaps still exist in some systems.
2) Does my CMS have translation-specific web services and APIs?
Is there a dedicated API to handle the filtering, packaging, export and import of translated content? Can you automate transmission of translation projects? A native translation API means that any translation customizations or connectors developed against that API should not break when you upgrade your CMS. If not, a developer may have to access foundational APIs exposing the code to more complexity, upgrade issues, and points of failure. No web service means you will have to manually send content to translation or drop it on an FTP service.
3) What content can be translated?
At a minimum your CMS should support the export of page or body content to be translated. But what about other translatable or globalizable text such as UI components, metadata tags, SEO words, URLs, sitemaps, templated text, attachments, user-generated content? If these items are not systematically accessible for translation, you may need to write custom code or plan for manual or semi-automated processes to handle them.
4) How do I indicate the content to translate and initiate translation?
Ideally, your CMS has a user interface for collecting content into a package and sending it to translation. This interface should allow the user to search, filter, add and delete content until the package is suitable for submission. If your CMS does not have an existing UI to build the content manifest and submit translation, you should ensure that a translation connector includes this capability or plan on building a custom UI within the CMS.
5) Does your CMS allow metadata to be transmitted with the translation package?
Frequently files are not all you need to transmit for a successful translation project. Your business may need to associate metadata such as an internal project number, cost center, product line, due date, translator instructions, etc. with the translated package. Does your CMS support adding fields or attributes to the translation project that will be needed for reporting or financial purposes? If not, then look for a connector that includes the ability to add metadata to the package.
6) What file formats are supported?
Exported content must be consumable by the translation system. Does your CMS export to translation industry standards such as XLIFF or other formats such as XML, DITA XML, HTML, IDML, MS Office, etc.? Translation management systems typically filter translatable text from a variety of formats, but if your CMS can export XLIFF, you may save on filter maintenance.
7) How does your CMS track translation status?
Is there a dashboard or other visualization of translation status in your CMS? Your web producers, project managers and other stakeholders all have a vested interest in knowing the status of translation projects in-flight. Also, tracking the relationship between source content and translated content is key to global content governance and keeping content in synch across regions.
8) How is the translated content injected back into the CMS?
Translation is a one-to-many process. When content comes back from translation, how is it stored and associated with the source content? Many CMS maintain parallel content structures and inheritance relationships between source and translated content. But some systems don’t maintain the link to the source (some blogs and wikis) or can’t store the translated content in the same CMS instance. This means extra effort and administrative overhead to ensure consistency and prevent orphaned content.
9) How are content updates handled?
Content updates can cause significant grief for content publishers and localization teams. Both source and translated content will change after initial publication and not at the same time. Many companies partially translate content per region or fall back to a source region like the US when content has not been translated. Published content must live happily with content still being developed. Ask if your CMS can version both source and translated content, ideally highlighting changes so they are easily identifiable to reviewers. Can your CMS publish production-ready content while allowing for changes to pre-production content without overwriting it? What happens if you make changes to published translated content? Is there a way to propagate those changes back to the translation system so you don’t lose edits on the next update?
10) What happens to deleted or canceled projects?
Finally, if a project is canceled or deleted from either the CMS or the translation system, there should be a mechanism to prevent orphaned projects. This would generally be a function of the connector between the two systems, but the CMS API needs to support it. If not, your production and localization staff will need to manually clean up projects or face a growing backlog of distracting, irrelevant items.
Would you like to discuss your CMS and translation-readiness? Contact me (email@example.com) at Spartan Software, Inc. for a consultation.