June 2020 saw one of our biggest achievements in this young company’s journey, as we implemented the first translation package roundtrip, introducing a new workflow engine into BeLazy. When launching the company, the original plan was to develop the functionality required to automatically create projects in business management systems via BeLazy. But to our surprise, the market has shown there is even more interest in comprehensive automation.
In our pursuit to achieve end-to-end automation, we carry out two exercises:
Of the two, the first one is definitely the bigger challenge. When conceptualizing automation workflows in translation project management, we often run into the problem of assigning linguists to a translation project. We regard this an essential part for automation and we will explain why further along this article.
What is linguist assignment and why is it complicated?
At first sight, it looks quite simple. All you need to do is select a translator and a reviewer for your project. If any of them are unavailable, you select another one.
This was actually enough for our scenario 1 with the project packages, because business management systems like XTRF come with a feature that makes it possible to provide access for the vendors to files attached (online) to the project.
However, it was not that straightforward with online translation management systems where the translators need to be selected directly in the online system. Achieving a similar kind of automation in this environment demands extra efforts:
What is mapping all about?
In every translation management system there are linguist users. If this happens to be your customer’s translation management system, you may have named them as Vendor001, Vendor002, Vendor003, etc. In your business management system, however, these people appear with actual names, such as John Smith, Katie White, or Isabel Rocas. Mapping contacts means establishing the linking between the TMS vendor names and the BMS vendor names.
What if the vendor is not registered in the TMS?
That makes things more complicated! Imagine that you have 700 translators, how do you know who is registered and who is not? If you created users via XTRF or Plunet’s memoQ or Memsource integration then this is good news! In such cases, there is probably a way to match these users as these systems store the username equivalents per vendor. But what if they were created manually? Our best shot is that you followed some kind of naming convention, for example: JSmith, KWhite or John Smith, or john.smith, or John, Smith… it’s not always so straightforward! And we certainly hope that all of the users were created using the same rule.
How is this represented in BeLazy? A screenshot tells more than a thousand words:
First, you need to detail if there was any kind of rule used for naming users, and whether you want to keep using it in the future. This is done by the checkbox above. If you don’t enable this checkbox, BeLazy won’t generate new users for you if they are not available in the system. If you enabled this checkbox, you have to select a naming convention – there are a few options.
The lower part you need to use if you only work with a handful of vendors for a customer. For example, suppose only 5 people work for an enterprise, and you know who they are. There is no reason for BeLazy to create users, and you just get a list of your users on the left side, whereas you can assign one or more BMS users on the right side. The right side lists all your BMS users, but you don’t need to assign all of them. If a sixth person is assigned to the project, you will get a red flag from BeLazy, and you simply have to go to the system and create a new user, and assign this BMS user to the new user from the red flag.
Why is it not enough to use the BMS integrations?
What systems are supported and how does this work?
We started with a relatively simple scenario: Memsource and XTRF. Now you can map your Memsource users with your XTRF users, and if you select a translator in XTRF, it will be mapped automatically in Memsource.
If a customer sends you a project in Memsource (e.g. a CMS integrated project), it can be picked up into your XTRF, assigned to the right vendor automatically, and when the vendor accepts the project, assigned also in Memsource to the right user.
This takes us to scenario 5 in our vision, which refers to translation work with online translation management systems. With each release, we are one step closer to fulfilling our vision.
What’s left to be done?
When developing a solution, we always start with a general plan and then move on to the specific tasks. Right now, every business management system is able to communicate with BeLazy whenever somebody is assigned to a certain job, but not all of them are able to notify BeLazy if the vendor changes. The first task within our plan was implementing the polling method first, and we now have to develop the specific capability of XTRF to notify about events within the system.
If we succeed, we are going to be able to pick up any changes on vendor assignment in less than 30 minutes. For the time being this process takes more time, but it will become part of BeLazy’s core functionality within a few months.
If you have been following our steps, you have probably realized that we have made more progress with XTRF than with any other tool. The answer to this is quite simple: XTRF’s APIs support experimentation more than other APIs so far. However, we do not want to leave the rest of the BMS’es behind. We plan to implement this functionality also for Plunet and the other BMS’es soon.
At the moment, this solution works only with Memsource, but stay with us because the BeLazy-Globallink integration is coming soon, and it is going to support similar functionality. Currently, Globallink is not supported by any of the business management systems, so this is going to fill many gaps. Besides Globallink, we also see the need to do this in Welocalize Junction and Moravia Symfonie.