Modern translation pipeline starts at the end user

Max Morkovkin 00:09
So here we're Rickard angles is the founder and director of CVO. He started the company in 2004, and led the company to become an international organization with over 40 employees. CDR has developed a powerful content integration platform as a service for content integration projects. Gartner awarded it cool vendor in 2017. With this technology and its content migration services, serial helps organizations worldwide to free their content and get the most value out of it. Regardless of where it resides. We help enterprises working in the localization and translation industry to solve the connectivity and automation challenges. They are facing. recordset Hello, record. Are you with us?

Rikkert Engels 00:57
Yes, I'm here. Very pleased to be here.

Max Morkovkin 01:00
You're welcome. How's it going?

Rikkert Engels 01:03
Good. Very good. Very interesting. So far. I've enjoyed it.

Max Morkovkin 01:07
Yeah. So you're also checking these messages in chat. And the previous presenter was so good in timing. So you have several minutes extra.

Rikkert Engels 01:16
Perfect. Cool. So

Max Morkovkin 01:18
are you ready to share the screen and start the presentation?

Rikkert Engels 01:21
Yes, I am. Ready. Okay, cool.

Max Morkovkin 01:26
So just remind to the attendees guys, and ask your questions in this QA tab, and join our Slack workspace. So Richert, give the mic to you.

Rikkert Engels 01:39
Thank you very much. I like an interactive, kind of, I always like the interactiveness of a of a of a webinar. So if there are any questions, please fire them off. And, and I will try to include them during during the presentation. So you don't need to wait with all the questions until the end, they can also come during the presentation itself, or you allow me to interrupt you. Yes. If you think there's a really good question, which is related to the topic that I'm talking about? Absolutely. Do the Yeah, I will

Max Morkovkin 02:11
do my best. Okay, perfect.

Rikkert Engels 02:13
So we are relatively new to the localization industry. So let me give you a little bit of background where acceder comes from, and, and what our role is in in the localization industry. We started in 2004 16 years ago, as a migration services company. So we did primarily migrations into three do migrations into Adobe migrations into Sitecore, etc. Then, in an end, we used basically, our own software to do that. But we only used it as a services engagement. So we never really sold software, we just provided migration services. Now, then, in 2010, we started with the, with the with Canada partner program. And we had partners like Capgemini, use our software to do their migrations, and which of course, widen the spread a lot. Then in 2017, we, we saw that the ability for enterprises to migrate everything to let's say, SharePoint, or migrate everything to Adobe, or migrate everything to Sitecore, was nearly impossible. And from a program point of view, from a technical point of view, from a business point of view, it is incredibly complicated with so many content sources around and so many different use cases to migrate everything to a single platform. So we started with the development of our unified Content API. And basically what the unified Content API is, it's an interoperability platform between content management systems, which would allow enterprises to migrate what they want, and to leave behind what they what they do not want to migrate. So let's say you have a very specific site in WordPress, but your migrate but you are trying to consolidate everything into into into Adobe, then it might be smarter to leave that single website in WordPress behind, but you still use some of the publication and the and the analytics, etc, of the of the of the Adobe platform. So that was the initial goal of the development of the Unified Content API. Now then, Gartner for this was very cool. So they awarded this cool vendor in 2017. And, and we started to offer the software to other to other to other software vendors, so that they could integrate our interoperability platform in their offering. And one of the first we approached was STL. But it actually did not approach STL I reached out to Twilio. And because I thought that this content interoperability software as part of the 3d on product would be a really good use case. And 3d on said thank you very much. That sounds very interesting, but we're not going to use it for 3d on yet. Spoiler alert now they actually also do so now. It's also used in 3d on but we are going to use it for translations. And I said, Okay, that's fine. And so they use it for translations. Because at the end of the day, it's all about, it's all about connectors, basically, and the ability to do certain things in those connectors, we didn't really look into the localization industry a lot more. But then in 2018, we did a deeper look into the localization industry. And we found that there's a huge opportunity for an integration platform. Basically, what we saw was there was there was, there was a lot of, let's say, custom built connectors, a lot of let's say, all technology, so we decided to offer our connected platform more for for the localization industry. And we did and we partnered up with with flexor Capitolio, etc. But still, it was a technical partnership, where these relatively large LSPs with their own technology, used our connector platform under the hood, to offer their connectors. And then in late 2019, we released the localization hub, because the localization hub has the has kind of the main difference between the underlying connectors and localization opposite the localization of doesn't require technical expertise. And it's really a specific translation middleware that allows you to send content from any content management system to any translation provider, whether that machine translation, whether that is terminology management, whether that's a TMS, or whether that is directly to, to and to an LSP. So the localization app is basically the middleware on top of that connector platform. And, and right now, we, we released two days ago, actually, it's very exciting news, we released the market space. And with the marketplace, we really want to provide an ecosystem approach, so that any translation technology can reuse all our connectors, and the Integrated Technologies, but also become interoperable with each other. So that's a very cool, new, exciting, new, cool, exciting initiative. And I'm very pleased to inform the audience hear about it, and I welcome you to check it out. Now, let's go further on what the modern translation on then a little bit actually a little bit more about, about the self promotion. So the clients that we serve, we are based in, in the Netherlands. But we've always served a lot of international clients because of our specific migration expertise. So there are big lines like Moody's in the states and calls and the Financial Conduct Authority. And but also smaller clients, of course, where, where there is not such. So it doesn't need to be that complicated. But the the primary kind of the most clients of ours have a relatively complicated content landscape, and really profit from the fact that they can automate certain things. Now, let's get back to the to the presentation at hand. My my statement is we live in an ecosystem economy. But if we and and and as I still consider myself an outsider, I still consider myself more from the digital marketing world than from the translation world, because of course, we're in the digital marketing for 16 years, we still do those migrations, and and we're only in the translation world for about three years, I want to take you on a little bit of a journey, what happened in the digital marketing industry from a software point of view. Now, from 1990, to 2010, it was all enterprise suites, it was all Oracle, IBM. And basically, it was enterprise suites, relationship sales. The slogan, of course, was nobody gets fired for hiring IBM. And that is how sales was done. So it was basically give me big check, and I solve all your all your problems. Then in 2010, with the rise of the internet, it was much more important that things became open. So it became platforms. And sales was mostly driven by solution engineers. So you needed to do a pilot, and you needed to show that your solution could could be integrated into into the into the architecture of the of the enterprise. Then in 2015, with the rise of the clouds, it really became API first, it really became it really became a developer sales, where developers were trying the products. And it was, of course, still the business that was deciding. But the developer had the right to say no. So it really became a developer product, because of course, in the marketing world, everything needed to be integrated with each other. And if a developer couldn't integrate it, if it wasn't an API first, it was kind of pointless. And the rise of the API has led to the existence of ecosystems. Right now we're in the in the in the age of ecosystem sales. So my My point is here, that in the localization industry, nearly every event, the rise of machine translation is the predominant factor to actually talk about. And what I'm saying is, machine translation is just an acceleration of the existing process. It's the same process just done faster, of course a lot faster and has massive impact. But in fact, it's the same process, what really is changing and will change the localization industry is cloud, because cloud favors API first and open. And clouds triggered the start and possibility of ecosystems. And that changes business models. And that has a much bigger impact, much bigger impact. Now, if I then look back at the translation ecosystem, then I think we can all agree that translation is still mainly driven by relationship sales. And as a result of the relationship sales driven model, it is also offering enterprise fix, if you look at the end, and the problem is then the following problem or problem kind of it looks Of course, it all depends on your on your on your point of view. But because the top wants of PIF in the world, all offer enterprise suites, they all have everything. It's all in my view, not the best technology, because of course, if you are everything, it can ever be really good. But it is seen as the road to success. So the top six still 30 of following that path. So in essence, the translation technology is still in 9090 to 2010, it still has the roads to go to a platforms to API first two ecosystems. And I think that is that has to change that has to change. Because there are more things happening in the world. If you take a system like like SharePoint, now I have done migrations or we have done migrations for the last 15 years. And so we know all these all these content management systems inside out, I can tell you that office 365 that everybody is using has absolutely not a single line of code or maybe a little bit of line, but hardly anything to do in the core architecture compared to SharePoint 2013. Nothing, nothing. SharePoint 2013 is a is an is an evolution from SharePoint 10. From from SharePoint 2010 is an evolution from SharePoint 2007 is an evolution of SharePoint 2003 is an evolution of Microsoft complimentary server 2002. It's all an evolution built on the same codebase. office three, office 365 is rebuilt from scratch. What I'm saying is here is that if you want to build an API, first cloud solution, all top enterprise application vendors have rebuilt their application framework or their their their their application, their their their products from the ground up. And that is why it is capable to deal with an API first ecosystem. And that is why because it's made for the cloud. Now, I don't want to judge the current translation technology too much. But putting 9095 technology on someone else's hardware, and call it cloud is not what is meant with cloud. It is really just old technology. With a little bit of shiny features on top of it deployed on someone else's hardware. You can approach it through the clouds, but it is not API first, it is still so all the top 90% of the top 10 enterprise application vendors have rebuilt their technology stack from scratch. So this is the biggest difficulty that the incumbents technology players have and where the where the new players have a huge advantage because new players of course, by default, have used the latest technology to build their application and we do not have to worry about old clients etc that we that we still need to support them. So it is it is incredibly difficult. But they're such a different way of building products now than it was in the in the past that it has a massive impact. That's why they started all eight nine years ago with the rebuild of their of their application framework. Now, there's a second Sorry for

Max Morkovkin 14:39
interrupting you I believe for there are two good questions to answer the moment. The question from Rowell high regard Can you please explain the application of your product services for us? In simple words, we usually receive requests from customers to translate and app WordPress ecommerce platform in a number of languages with your technology can we easily Do it.

Rikkert Engels 15:01
We are focused on content management systems. So, GitHub GitLab ecommerce systems like Magento CMS systems like like like Sitecore and Adobe file management systems like next day when SharePoint, that is our forte, we could do software as well. But it is not the best for that.

Max Morkovkin 15:24
Okay, good. And there is also a question from Enzo, can you develop the concept of ecosystem? Sal?

Rikkert Engels 15:33
Sorry, can you repeat the question?

Max Morkovkin 15:35
Can you develop the concept of ecosystem sale?

Rikkert Engels 15:40
Yes, that's what we're trying to do. Yeah, I will come back to what an ecosystem actually is in in in less, I think three or four slides.

Max Morkovkin 15:47
Great. Okay. So let's, let's move forward.

Rikkert Engels 15:51
So why why is API first so important? Because without API, first, things are not interoperable and information cannot be exchanged. And I was at a Gartner conference in November in 2019, so a couple of months ago, and there were 7000 CIOs in the room and Gartner towards the 7000. CIOs reject any norm API first notion, no matter the price is that you have to simply renewing software, which is not API first, hit you in the face. So it might take a little bit of extra money. Now, it might be painful to to say good bye to your old buddies, but you must not renew known API first technology. Now, I think the localization industry is quite lucky that it hasn't raised board level approval yet. But of course, this board level imperative can also go down in your organization. So it is incredibly important to have API first technology, it is not something that is simply assessed by this technology organization. No, it is really incredibly important. I cannot stress it enough. And enough. The gardener Of course, as you know, as the CEO kind of was the CEO whisperer. So they so these people listen to what Gartner has to say there. Now, if you're if you take these trends, and you look at what the current translation technology landscape looks in the this is of course, not for all translates technology. Of course, there's also a lot of new ones. But I'm talking kind of in general, in general, there are kind of two ways to solve automation. Within the localization industry at the moment, you either get a spaghetti solution with all kinds of like custom integrations between each other. So you kind of glue the solution together, and everything is kind of custom. Now, with from 2018 to 2020, we sold connectors as an OEM offering to the language industry. So I have had the previous of hidden under the hood look in almost like I think 40 LSPs, I can tell you, it is spaghetti. It's a custom spaghetti. So this is one piece of the solution. Or the other alternative solution is offender login. So you buy everything from a top layer. And then of course, you it might be automated, but you're completely locked in. And you can really leave or adjust it just like this is the box and you need to deal with that box. It might be more automated than the spaghetti. But of course it comes to the price. And the price is that you're no longer flexible, and that you're dependent at the mercy of the large of the large provider. Now, what is modern API powered digital ecosystem? What is really an ecosystem and I think this was actually three slides. So the a model, API power digital ecosystem has three characteristics, three main characteristics. It is the main one is it is easy to work with. So for developers from any party, they can integrate with your solution very easily. Good documentation, self service, easy to discover, etc. So it's very easy for developers to work with the second part, which is also incredibly important. It offers new business channels for all providers. So if you have ever translation, if you have an ecosystem in a translation world, the actual new business channels might not be the options, but any ecosystem creates new business channels. And I actually see it see it in front of our eyes because we launched the marketplace but we had a soft launch already a couple of months earlier, where we integrated already a couple of translation technologies and new opportunities arise where in context review is combined with a capital etc. So there are new business opportunities. Where you modernize the whole technology stack. So as part of a modern cloud ecosystem, the second main characteristics is it offers new business channels for every party in the ecosystem. And the third value equation, what is essential about an ecosystem is that it gives me access to unique data and content. Because by combining different data sources, there will be new insights for the end user, which is of course, the enterprise clients, and more access to unique data, more customers, etc. So it basically triggers new insights and new automation because of that API powered ecosystem. So the three characteristics that's how the sales is built, easy to work with for developer, new business channels for for for all providers, and new and unique insights for the enterprise clients. Now, if I if I didn't go back to the to the situation, how are actually go back to the topic of the discussion, which is like a modern translation pipeline starts at the end user. This is another observation from from from from us that I that I see actually time and time again. If we if we every seller migration, we always talk directly to the digital marketeer or we talk to the IT department. If a translation is sold, even though the end user is the market here, in 99% of the time, it is actually the LSP selling to the localization departments. And if it's not the localization department, its global procurement. So how it works in kind of reality is that the market tier comes up with their requirements. There's an RFP and the RFP goes from the localization department to several translation providers, and the translation providers are then offering that are then basically answering the RFI and and hoping to win. Now with that relationship, sales driven model, or with a price sensitive driven sales, because of X also because of the global procurement. The the market here is actually never really included in any in any discussion. So automation is more like more like a tick box to win. And instead of that it is used as a as a key enabler to drive the translation process. Now, and that has resulted, because because of the ignorance of the market here, that has resulted that kind of the best case scenario for a marketeer is that he or she has to do 10 clicks to upload content for translation. So the common best use case is kind of a plugin within the CMS and then within the plugin, which is usually very clumsy, he can he or she can do like 10 clicks. And and then the content ends up at the localization department localization department, forwards it to the LSP, etc, etc. So then the process actually starts. That's the best use, that's the best case. Best case is 10 clicks. And very often, very often, there is actually not there's actually not not not not a not even a plugin, and content needs to be uploaded into a portal, or it needs to be sent by email. I once spoke to a client to a localization department. And I asked him if there was any need for automation. And he says, No, we have everything automated. I said, Can you be more and more specific? And he said, like, yeah, and I mean, I just received the content. And then I pass it on to my LSP, I passed my content to my to my to my internal LSP. And once the content is translated, I publish it back into the portal and the end, the end client can actually download it there. I said, Oh, but how about the automation for the end user? How do you receive the content. Now the end user uploads the content into a portal enters 12 metadata fields. And then when the content is translated, they can copy paste it back into their own system. That is automation between the localization department and the translation provider. But that is not automation for for for other markets here. Or another example, which I think is actually the strangest. There's a big car producer that has 20,000 websites. And the only way to get contents translated for them is to send a Word file. Because the only format the LSP understands is a Word file. That is not automation that is not the having the end user in mind. So and within most enterprises, it is still the end user that has most budget and that is still a key influencer. And of course we are seeing this over and over again. So I would I would say It can be a lot better, it can be a lot better. I think that 10 clicks is absolutely not easy at all. Easy, in my view, is 00 clicks, absolutely zero clicks, that is easy, because it is nowadays, very easy to determine the automation rules etc. So in my view, what is modern and what is a what is a modern translation pipeline that starts at the market here. The rules between the market here and the localization department are basically as follows. The market here discusses with the localization department, the translation requirements, the localization department sets up the automation rules, as a one one click activity. Basically, what this means is that based on content type, or based on folder hierarchy, you determine what needs when it needs to be automated, and in which quality and in which languages and the required turnaround time. And then you just monitor if there is new content or that the existing content has changed. So you will deploy the automation rules once and that's it, you don't need to do anything or the market here, doesn't need to do anything afterwards. If there's something changes, the market here would simply inform the localization department and localization departments simply deploy to new automation rule. But it's all rule based automation. With zero clicks, you deployed once, and you're done. Now, what does the localization department then do, they provide, of course, invisible translation for all for all their end clients for all their end users within the organization. And they then take the project scheduling the content automation, and they simply select the right provider based on content type turnaround time and quality requirements. And what they can do is they can try new innovations to optimize the process. And, and then the translation provider, of course, what happens in this scenario, they simply receive the content. And, and actually, this is a little bit of marketing, then, because of the marketplace, within the marketplace, you can actually offer your services at the marketplace, which then acts as an innovation, of course, for the localization departments. And so this is where the localization departments can basically browse for additional innovative services. And, of course, for the translation providers, it offers the ability to offer this type of automation to their clients. So there's no needs to develop your own connectors, you would simply offer the automation through the localization up at at your at your clients. I see, I see quite some questions. And this was my last slide. So I would like to go to the questions.

Max Morkovkin 27:51
Great, very good timing. Thank you regard. You're welcome. And thank you for providing real examples from your practice. It's very appreciated. And also for your enthusiasm in pushing this automation. It's helping all of us. There are a lot of work that we can focus on. Since these manual things are automated. So yeah, let's take a look at the question from dark straw gets a bit blown message here, but it looks interesting. So would you like me to read this? Are you see?

Rikkert Engels 28:27
No, I don't see it, but maybe I can try if I can see it as well, because I don't see it right now. Okay, yeah, it's in chat. I see it. Is it in? Okay, well, maybe I can see it.

Max Morkovkin 28:36
Yeah, so let me just let me know if you want me to read this, or you will read it. Oh, yeah.

Rikkert Engels 28:42
Can you please explain application of your product service for us? In simple words, we usually receive requests from customers to translate WordPress ecommerce platform in different languages.

Max Morkovkin 28:50
We've already answered that one. No, no, we've already answered that one. Okay. So here it is. Let me read it. At glta. See, we have an API and are tightly integrated with Namaka. But the clients struggle with their own internal processes that are barriers to true integration. source content errors also prevent more automation. In a perfect world. Yes, zero clicks is an admirable goal. Always exceptions in automated processes that break the process. How does the platform handle that?

Rikkert Engels 29:24
Yes, very, very good question. So, the main thing from an architectural point of view between the current way connectors are working and the way we have developed the connectors is it's an it's an we have we have decoupled basically, the actual connector from the translation technology. So it is it is split. There is no direct connection between memo queue and connectors. Now we have connected Then we have middleware. That's where the content resides. That's where the content ends up. And then you have entry and access points to integrate with memo queue or with any other custom solution that you have, where we basically have three left three lessons three ways to integrate your, your translation technology into into into the localization of so as a result of that, there is no problem that certain information needs to go to memo queue or something like that. That is all possible because there is no, it is decoupled. So you have basically an entry point and that entry point you connect with your Mimikyu instance. That's the first part of the of the question. The second part of the question, how do you deal with exceptions? That is, that's a very, very good question. Do the reason why connectors break? Why custom connectors break? Is because they're built as a one off assignment. I have seen every connector that has been developed by as I said, 40, LSPs. I can tell you, it is it's not software, it's custom code. It's custom code it's not supposed to last is there's no automation in it, they build a connector and five days, 10 days, 15 days, 20 days, whatever. We build an application framework. And to be honest, there is one top layer that has also the same quality connector. So it's not only awesome, but it's about it's about how much emphasis as an LSP do you put on your connectors, if you think you can build it in like 10 days, and you worry that it breaks afterwards, you already started on the wrong foot, we have 27 connectors, we have not built a connector on the 1300 hours, I would have wished we can do it faster. But any product is connected that we deploy takes 1300 hours. Now because it has taken 1300 hours, we made the abstraction on the metadata level. Which means that if there are exceptions handled, it is probably actually already taken care of because of the different layers of integration. So that is the technical answer. I hope it's not too technical, but it is just it just kind of business logic. If you build a TMS tool, you do not have the product capacity to spend 1300 hours on a connector development, you simply do not have the time because you sell the TMS you don't sell a connector. So when you have a connector, you simply send a consultant quickly to the client, deploy something, hack something together, put it on your website and say I have a connector. And then you worry why breaks to two years later or two months later, or why it cannot handle the exception, because of course it's not been designed like that. Now. So that's the technical part of the answer. And now on the functional side, how you deal with it. It is you do not assume you can automate everything, what you try to automate is that you try to automate as much as possible. But within the localization hub, you actually have access to all the systems anyway, that are visible through a very easy to use interface. So if there is an exception needed, you simply navigate and select that content and send it for translation. So you cannot exclude exceptions, you just what you have to do is you have to provide a framework that the localization department can quickly implement that exception in the same fashion.

Max Morkovkin 33:54
Very detailed. Thank you very much. By the way, guys, we are recording the entire conference. So you will be able to listen to record answers carefully later. And we are going next. If you allow me I have a one small question from my side. And he plans to make a connector to smart get.

Rikkert Engels 34:11
Yes, actually, it's already in the works.

Max Morkovkin 34:15
Nice. So we can

Rikkert Engels 34:17
it is already in the works. And yes, no SmartCAT is is already in the works is a fantastic tool, and will offer a lot more automation possibilities that were unseen before. I mean, I think that SmartCare will be probably one of the proof points of an ecosystem model. Because by combining LACOB with SmartCAT we can probably offer more automation that was seen now.

Max Morkovkin 34:48
Record Thank you very much, guys. It was not planned. So it's just the question came from my head. And thank you for this answer regard. Let's look at another question from David. What If the marketer works in Excel spreadsheets, word docs, and not any CMS marketing department in my company allows preparing contents in Excel spreadsheets.

Rikkert Engels 35:11
Yeah, that's fine. So that we have actually all connectors as well to file storage systems like SharePoint or Dropbox or Box, or even network drive. So you can so you can include it in that it follows the same principle is just files and content that is, that is stored somewhere. So as I in the beginning of the webinar, there was a question like, What kind of content do you translate? And I said, like, we're not, we're not, we're not the best in software applications. So but it needs to be some kind of content repository, where there is a structure around the content. So a content repository is a simple box folder or network folder, or, or it can be a more complicated system, like a content management system. For us it is, it is still kind of a file stored somewhere, either an HTML file, PDF file, a Word file, Excel file that needs to be retrieved, and it needs to be sent for translation through an automated process.

Max Morkovkin 36:16
Great. So folks, any more questions to record? fascinating insight. Thank you came back. It might have been Mike. Okay. Some issues with the sound on Okay, debit is saying thank you for the answer. Looks like. Yeah, we're good. No questions so far? Then let's wrap up record. Thank you very much for this insightful presentation, and very good timing. We appreciate it. Looking forward to seeing you again. And stay tuned and let's wait for the next attendees and speakers and panel discussions like very much.

Rikkert Engels 37:07
Thank you very much. Enjoy the rest of the conference.

Max Morkovkin 37:12
Thank you. Thank you.