Note 1: This blog entry is actually a request for feedback. We will utilize your input when developing the v1 APIs.
Note 2: If you own a proprietary business management system, it was either developed in-house or by an external team. Please ask your development team to read this blog entry and ask them for comments and check if there is anything they don’t agree with in principle.
Working with the automation tools
For a long time, I used to work mostly with local Microsoft Office files, so it was an eye-opener when I started using Google Docs. Many people use Google Docs because it provides amazing real-time collaboration, but what surprised me the most was the integration possibilities the system offers: somebody fills in a form and it gets stored in Google Sheets, you add a person’s data into one system and it gets automatically added into multiple others.
Some of these features come from Google’s own development efforts, but many others come from external integrations, either through third-party systems or via automation tools like Zapier, Automate.io or Cloudwork. These integrations are available mainly because companies like Google design and develop extremely open platforms and provide robust, easy-to-use APIs.
Lack of APIs in the translation industry
“The translation industry is lagging behind because everybody works in isolated silos with no connection between each other.” I am quite sure you might have heard that line more than once. And sadly in a way, it’s true. We have gone a long way with BeLazy, but it already shows that even if there are APIs for many tools, there are still two basic issues: missing functionality and restrictive pricing.
When studying the APIs in the translation industry, we identified that most APIs connect systems in the same company, rather than systems between different companies. The thing is, if you are programming an integration between different systems at the same company, there’s usually no problem giving full administrator access over the system, which is what most APIs do. However, for the APIs connecting systems between different companies, there is usually permissions management issues.
This where BeLazy comes in. We facilitate connecting systems in different companies to enable information flow.
The eco-system, provided by a middleware
In an environment like this, it is no surprise that integrations are a big investment. Probably only the largest LSPs can afford them.
To create successful integrations, you need to formulate your requirements clearly, you need to be listened to, and execute the development work. But the main issue is that most developers do not have the skillset to speak as product managers, and translation companies don’t employ product managers. At BeLazy, we have taken the freedom to represent all of this for the translation and localization industry to facilitate a completely extensible platform.
The first APIs: to business management systems
For the past month, we spent quite some time surveying translation companies to learn about the different types of business management systems (BMS) they employ. Plunet and XTRF seem to be leading the pack (at least in our data) while developing a proprietary system came to be the third most popular option.
We understand it: proprietary systems are customized for specific types of works and workflows. However, there is no way we can develop integrations to all of them. For this reason, we are drafting the first set of APIs, to allow creating the projects you approve in BeLazy in your proprietary BMS.
Technical considerations
The BeLazy APIs will be REST APIs using the OpenAPI (swagger) framework. The API will have two modes: push and pull. The push mode can communicate to a URL when there is a new project approved in the system. The pull method can be used to query the list of projects approved and download the already-transformed project as a JSON representation.
Metadata
Different systems have different ways of naming things and metadata is no exception to this rule. However, converting metadata values from one system into another is expensive and time-consuming. With BeLazy you don’t need to worry about this anymore. You can easily convert and map metadata values from different systems in a single interface.
Our projects contain the following metadata:
- Language codes represent languages in software systems. The customer may come with a French (France) language with the code of fr-fr, but you may only be handling French, i.e. fr. Or you may get a Spanish (International) language from the customer, but you may only have Spanish (Latin-America) or Spanish (Mexico). Language code issues are bound in most cases to sublanguages.
- Specializations are the subject fields in which translators gain expert knowledge. The customer may come with Civil law, whereas in your system this is categorized as Legal.
- Rate cards are match rates provided in the analysis of computer-assisted tools and translation management systems. Most tools operate with a set of rates such as 95-99%, 85-94%, but Across uses a slightly different one: 90-99%, 80-89%, etc. You may only store one set of values and want to do a mapping.
- Services is basically what you do for customers. Other systems call these workflows, templates, or also services. For example, a customer may ask for Quality translation, while it in your system that is represented as Translation-Editing-Proofreading.
Your system has metadata which is probably stored in a database. To make the integration process easy, we have decided to offer the possibility of uploading metadata to the BeLazy interface manually — rather than automatically. Why? Mainly because these values hardly change. Each metadata item will contain two values: an ID to make sure your side of the integration can instantly use the reference to the correct metadata, and a text field to facilitate mapping on BeLazy’s screen.
So, what’s the good part about it? Now suppose a new project comes in through BeLazy but your client has assigned a never-seen metadata value to the project. You will be able to perform the mapping of values within BeLazy in a matter of seconds. At this point, no further development is needed to your APIs.
Does your system support these four pieces of metadata? Is it enough to give you back the ID and the text field?
System authentication
How will you authenticate your system? This is a decision not yet made. It is possible to use an authentication token but we could also go for the username-password approach. The first alternative makes development easy, but the projects may not be assigned to the right project manager, or when a new project manager comes on board, you will need to assign a token to them. The second one can allow the PM assignment, but requires more development work on your end.
Which authentication approach do you prefer?
Push or Pull?
As mentioned earlier, we are planning to push information to a URL so that you can listen to it and immediately start generating the project, or you can query the information in BeLazy.
Which option do you prefer?
Handling exceptions
The first version of the BeLazy APIs will not include handling exceptions (when something goes outside the automation scope and needs to be handled manually) and approving projects. That will still need to be done in BeLazy. Why is that? The overhead of developing this functionality is bigger than the hassle of managing not only your own BMS but also your BeLazy instance.
We will open up project creation and the interface later, however, we believe these (deep) integrations will be mainly beneficial for commercial systems, due to the costs.
Are you happy with this approach of only automating the creation and not the monitoring and error-handling of projects in your custom BMS?
Dreaming about the future
Sometime next year, we will also open up the vendor portal APIs. This could be used by your clients to allow their vendor portal to directly connect to BeLazy. You never know what workflow management systems customers can use, and there may be business cases where it does only make sense for one single vendor to have integration.
Our dream for BeLazy is to become an open platform — like Google! A platform that facilitates third-parties to contribute and cooperate with us but also to benefit from our success. I am confident that in a couple of years when a company decides to create a vendor portal, they will include BeLazy integration in an early version.
The key to this future vision are APIs! They are growth drivers. So we won’t be happy with just “decent” APIs, we want to develop extremely good APIs. We would like everyone with a proprietary BMS to integrate BeLazy’s service without much cost or effort. This is why we need your feedback! Please help us by sending the answers to the questions above or any other suggestions and comments you might have (you can send them to my email istvan.lengyel@belazy.cat).
Thank you,
István
