Translating a website can be a very easy thing to achieve, or a very hard one, depending on the infrastructure behind it. However, one thing is for sure: it's not about simple word count. We need to take into account which (if any) CMS is being used, whether files can be easily imported or exported, what kind of access we as service providers will be granted and if any engineering or development time will be needed.
Step 0 - Find out the "age" of the website
We need to know whether a website is being planned, if it's being tested or whether it's already in production. If we start a project in the very beginning, the changes of us being able to help are much better!
Step 1 - What is the Content Management System?
The first question that needs to be answered is whether the website is hosted using a content management system. Common ones are:
- AEM (to which we have a connector)
- Pure HTML
- GitHub/Jekyll websites
- Website copy in text or Word format - triggers a simple translation workflos
Each CMS will offer its own challenges and advantages, for example, Wordpress usually relies on plugins to export data for translation, as well as Drupal. AEM uses a modern project-based and plugin-enabled translation management system. Once we establish the framework used, we can explore the options available.
Step 2 - Responsibilities
If a CMS is in place, we need to define who is responsible for exporting and importing the translated content. Usually website owners will have developers or webmasters taking care of the health of the website, and they should be able to determine the suitable plugin for their CMS, and how to export and import translated files once they are delivered.
We at Bureau can tackle these engineering problems, but in this case we need to go through a discovery session and decide the best strategy to follow.
Step 3 - Workflows and File Types
Once established who's responsible for each tasks, we need to decide on the workflows. The website owner should be able to provide Bureau Works with a set of "workable" files, the actual files that contain strings related to the site pages. Normally, the CMS systems will export this content in XML/XLIFF or other structured format, such as JSON or YML.
Step 4 - File Engineering
In most exports, the text and strings to be translated will contain placeholders, to support templating languages and variables, as well as HTML elements for styling. We need to find out if the exported content will contain such elements in order to properly tag and protect these, to avoid them from being removed or even translated in the process.
Step 5 - Delivery Mechanism
In this final step in the analysis process, we need to specify how the content will be delivered. For most CMS, an Import mechanism will be available. Some connectors, however, will behave differently in accordance to their architectures.