PART I

During the last decade, we have noticed some level of homogeneity in terms of software interface and structure. The rise of numerous translation software in the field of Translation Technology along with the trend to migrate translation technology to the cloud has troubled translators who find themselves constantly challenged to buy, learn and use more and more software. Experienced translators who were not trained to use software, students and translators who move into freelancing are the three main categories that could find it hard to learn new technologies all the time, getting trained to different functioning logics and adopting their resources to new systems. These posts (Parts I, II and III) focus on three main areas in which XTM has incorporated features that form its unique structure and allow the establishment of connections among data, compared to other mainstream technologies, while also looking into ways in which they could be approached and utilised in the classroom.

Customer-based resources, refined options & penalties

Although we have seen filtering options based on metadata provided during the creation stage of a project, it is not common to see that defining the client is not optional, as usual, but rather a basic step and one of the first steps of the process in XTM. This way of structuring data in XTM provides an alternative method of categorising information. Users can organise their resources based on their clients. These resources remain independent and can be reused in several projects. Selecting the client for each project causes the system to suggest ideal resources, as well as translators, reviewers etc., saving time and effort from repeated actions that project managers would aim to avoid by refining possible preferred options.

As illustrated in the example above, in the case of sample project A for Customer A, whereby resources are assigned to a certain client/company, A are the resources of the current project, that are automatically created when the customer is created. However, the translator may have already created the customer in the past so existing resources can be used for the same customer, in order to complete similar projects (always depending on the client’s guidelines and request of deliverable files). The translator might want to activate a number of additional resources for reference, for example another set of resources built for a client named Customer C, for whom the translator has already completed legal projects. Finally, the translator can also use data from a field-customer they have created specifically for legal projects, e.g. Customer B. More customers can be added.

In this example, the translator will be able to see results from data B and C in the editor, which can be penalised to allow data from A to show up first in the list of available resources. The percentages for the penalties provided are only indicative. In this case, reference resources can remain as they are while A can be updated and delivered to the client clean. Each customer can have a number of projects. All projects that have been connected to a certain customer will appear when the customer resources are activated, leading to a constant exchange of data within the translation platform.

Teaching a customer-based approach of this type has proved to be a difficult task mainly due to the fact that the trend for translator and project managers in the industry is to revolve around and oganise data per project or project category. However, in realistic scenarios, technical translators come across several hurdles when creating and managing their projects.

Imagine a translator who has to follow different style-guides for three different IT companies with similar subjects, or the case of a translator who translates for three different departments within the same company (i.e. Marketing, Legal and Support). Think of translators who have long-term collaborations with companies requesting translation of similar subjects, yet using different style and terminology. Users can add more than one customers to use their resources and apply penalties to secondary resources which will show results with a lower match percentage in the editor and the search they perform in their databases through XTM. This way, they have simultaneous access to all the relevant data but they know which of the data is to be trusted as primary and which should be treated as secondary.

Tip for learners: You can use the concept of client in more than one ways if you want. You can have clients referring to actual customers or clients representing fields and domains, i.e. Medical General, to build on reference resources.
Tip for trainers: Ask your students to create a diagram with a model company in the role of the main customer with several departments or a model field that can be handled as a customer using resources from different companies-clients.

Emmanouela Patiniotaki
University College London