Traps of Continuous Localization

Max Morkovkin 00:00
So the poll is almost over. And I will be introducing our next speaker who will join us very soon. It's Samir Minaj. Product Manager focused on continuous localization system at info beep. And his presentation will be in engineering track. And the topic is traps of continuous localization. Hello, Samir.

Semir Mehadzic 00:30
Oh, man, hello, everyone. A nice to see you here. Thank you for joining us. Yeah. Thank you for the invitation. It's a pleasure to be here. Especially after an inspiring presentation like the one from Harvey. Hi, Harvey. Great job. Great job.

Max Morkovkin 00:44
Yeah. So you're on the good wave right now. So

Semir Mehadzic 00:49
I have no Red Bulls, as some suggest in the chat to be as energetic as Harvey, but Well,

Max Morkovkin 00:56
same. You're just be yourself. It was another advice from no problem heavy. Yeah. Good. So you're preparing to share your screen right. And I can give some insights about the presentation. So Sameer will be telling us a touching story about a company looking to revamp its continuous localization workflow. And be it's based on the true events really, and Samir will share three tips for selecting the right technology, and translation provider. So stay tuned. And Sameer is sharing his screen right now. We are waiting for your questions in today's session. And I'm turning off my camera now and give the mic to summer. Enjoy.

Semir Mehadzic 01:41
Okay, thank you, Matt. Thank you, Max. Hi, everyone, as Mark says, briefly announced this we needed, the topic of today's talk is continuous localization. And our experience with it now, don't worry if that the title does not seem relevant to you, it actually might very much be relevant to everyone. That's a typical attendee of such conferences because it can apply to buyers like us, you can apply apply to linguists and freelance translators to know what kind of clients are emerging out there. How you can maybe snatch some business from their side. And also it will be hopefully useful for some of the TMS developers or translation system developers to see. What was the overview of the status of this industry? Because we've actually gone through all of it, I would say, so yeah. Without further ado, let me just skip, and try to make it as as as relaxed as possible, it won't be any typical complex talk, then it won't worry. Yeah. Let me just give you a second. To minimize this. Yes. Let me just give you a brief overview. So about about this and the metaphor, major traps that we encountered, and then the rest of the story will follow as this way. So about continuous localization now, don't worry, I will not do any technical explanations for you out there who are not engineers or in development world, don't worry. I will also not show your any graphs, any any images, any workflows, because that's really, too much for for nice presentation, and the next conference like this one. I will however, try to explain to you how, what is continuous localization, why does it matter and why all of a sudden, people are talking about this. It's been on for a long time, but it's been really in the buzzword lately. So continuous localization is actually just the consequence of business of the business how it's done today, how software is created today. business requirements of any company from Google to the small software created somewhere out there is doing is new or features often, and today's market pushes you to release them fast. That's that that's it. That's how it is today. So it kinda looks like this. If you see my screen, it really is. It's like burning wheels going uphill and all in a rainy you have to take care of your business up here too. So this is how it looks in a more let's say funny way now, in reality, making products software products in today's world is not one image like this one. It's this is this is this. multiple teams are working in parallel. You see one company that giant this LW blue vehicle up the hill, but in reality in the background, there are multiple teams, multiple development teams and other teams of course, but multiple out, when teams actually doing stuff creating pushing stuff every day, and they have to work in parallel, no time to pause, they really need to improve things release new things as soon as possible to be the competition and to cater for the needs of the users. So that's how it is in the background. So literally, you have multiple vehicles running at the same time. So because of these business requirements, you had the development, or just the development departments in any company had to adjust. So the requirements became quite different from what it was 20 years ago, the way they deploy their release, what they've coded, had to be automated, it really had to be automated, to be set up to be, so that they could enable parallel work, like I mentioned in the previous slide. Companies need to minimize manual work. So if something is released every day, then you have a lot of work there. So you should probably automate it. And of course, automation helps prevent errors, mostly human based errors, because we're all humans, we will always occasionally make an error here, they so the developer development had to automate the way they work. And what they with time, this Vinnie got perfected so much that now any company can release things to the production to to users to end to you and me, even 100 times a day. Most of them don't do it, they do it maybe weekly, some of them do it monthly. But anyway, they can do it as as often as 100 times a day. And this means that we know that everything in development had to be adjusted. This is this is a very nice image. Take a look at this. This is the old you know, Microsoft Office desktop publication type of product, how it used to be, you had years or months to create to develop a big update for your product. With agile, this really got squeezed and post more frequently. Now with this continuous development, or continuous delivery, this is really gone, gone much faster than it ever used to be. So this, this is the challenge because it'll be the requirements, the development requirements changed. And of course, the localization requirements also have to be changed. They cannot possibly be different from what what was what's being done in the business part or in the development part. We in the localization part have to follow it. So if you have if your company has continuous integration and continuous delivery, the thing that I've just explained explained, you will need continuous localization to it's not really given a choice, you have to have it. Why because manual approach that we all got to use to solve before cannot work anymore. You cannot have people sharing out files, thinking them change them checking them know, what won't work, because of the sheer amount of changes done daily. So there has there has to be a switch, there has to be a change in how we, in the localization industry and in the localization parts of companies. Think about this. So it had to be automated, certainly has to be right now, unlike before, there is no clear start and end of the project translation project. You don't have Okay, now you have two weeks to translate this, these strings from a user interface. No, you will have every day got new content, sorry. And this content, it has to be constantly translated in a continuous flow. Here's one appropriate image. So yeah. What does this what does all of this mean? I'm actually done with the introduction. I hope it managed to shed more light. But we will go of course into more practical details later. So what does this mean all of this continuous stuff and new new way of building products and software mean for validation? Business, you've already certainly seen this and some of you experienced it. Projects have the size of the project changed. It went from large projects to small ones, days a week, slight fertilization now turned into hours or days. Errors needs to be fixed slowly. Now they can be fixed within a day. Lots of pre processing here now the dreaded pre processing of files normally that you just get text only mostly now. The API's are not any need for complex project management and processing stuff. So that's really different, but that's just what's different. Those are not the traps. Let me tell you about the traps. Here's a nice image to rainy with a rainy Proper trap like this. So the four traps the perfection trap, when you switch to if you work in a company that has continuous delivery and then the localization, translation must be released as quick as quick as possible, as good as possible. Really, in these words, this can be done because errors can also be easily fixed within a matter of a day not wait for the next release in one year to fix it tomorrow. So that's okay, even if you need something suboptimal. In terms of perfection, let's call it lunatic, it still can be fixed at any time, it's agile, this is a real challenge for all of us, especially with us, for us with a linguistic background, we really tend to, to, to lean to the perfectionist side. But anyway, this is a challenge for us. And we need to look at this localization should feel really the global expansion of a product not hinder it. So that's why we have to accept the planned imperfections and fix them along the way with their for the business, not vice versa. So the second trap is actually replace words with words may have oversimplify this, but she you usually get point, this may be observed often with those managing continuous localization or localization general with technical background, mostly development, because that's where all of this came from. Continuous local localization nowadays is usually managed by those who actually integrated it into the development pipeline. So it's mostly run by engineers, believe it or not, which is actually a I think it's a great thing, not not bad at all, because it brings a totally different perspective, totally different way of doing things. However, with this, the only drawback, from what I've seen, maybe that the focus is on automation and process to get things in software out of software, get it to translators, and then merge back into the code. But the focus is not so much about the language quality, that the nuances of the language, it's not because it's, it's, it's too abstract in one sense. So for developers Happiness is when the code works, really, that's what makes their their day needs of the translators are not really often addressed in the way that the translation localization community is used. When we talk about maybe treasured memories, terminology, giving, giving them context, and that kind of stuff. So that part is slightly overlooked. There's a third, that was the second trap. The third one is formed roles in a new suit. And that's, that's a very, very hidden, like this trap. Like a localization manager job job description, cannot just be tweaked. And then, okay, you will now have continuous deployment will have continuous localization, you just adapt what you are doing for the last 10 years. And no, it's not just two items on on the job description. This was so far done by mostly business or language people. Localization as such was managed, of course, exceptions, there are exceptions, but the average profile is either business or language. And the focus is, of course, on the language and the quality. But continuous localization needs the tech side, that's why it's tricky. You need You need this side of things do to manage the engineers and who are building this infrastructure and getting what you're, what the localization part, translate, getting it into the product and back. So this requires a blend. This is something that must not be overlooked. It requires a blend of language and software, both types of thinking, it can be one person, still, don't get me wrong, you can have two people working side by side, or can be one person, but usually that person will need to learn how to stuff. This person happened to me, I had to really learn how the product management side of everything, how software is created to be actually able to juggle with this, but it's all fine. If you have two people handling this. It's an excellent thing. Okay. Now that the false trap is actually it is the last one we want to mention. But we will expand into this a bit more. I was actually surprised with what was hidden in this trap. To put it in that way. Continuous localization is still localization with a different perspective share with a different flavor, but it's still localization. And this, this different perspective requires also different tools and different processes. Just like the job description, you also need different tools and different processes. It's manageable at different times. So my objective subjective opinion is that the translation industry is not really ready for continuous localization yet, really not not. At least not The way you would think. So be prepared for it if you're looking to go to start with when we talk about continuous localization your company or trying to get into a role that handles that, be prepared for the mismatch with the industry. What I mean by this actually, this will be the other part of my presentation. But what does organization industry trap mean in practice, as told by us, so not to leave you hanging with these traps, we'll share our experience with this trap number four, it contains some general observations and tips about the industry to be on continuous localization. So. So one warning, one word of warning that events are not products of my imagination, it's really a true story. Really, none of it was made up or enhanced. It really happened like this. So it's a true story, but we will not be naming any names, because it's not the point of this presentation anyway. So let me just tell you briefly about my company. Why? Why, why we wanted to achieve what we wanted to achieve. So we are a European company. We are communication platform used by Facebook, Uber, Viber, banks and all sorts of major tech companies. We mostly allow them to engage with their customers to send content messages, information to their customers, and get back and engage in conversation. But I won't go into detail is really not the point of this presentation. What is important for this presentation is the three, of course, is agile. We have around 70 development teams across European India. This is the image of our developer press conference two years ago. So I think our number a number has increased by 40% by them. And for us, because of this global distribution, and everything. Ci CD was a necessity. So continuous delivery, delivery was a necessity. So we also we also, of course, we had to solve the question of authorization. Before our product UI, our products, which was add internally, by EU, we use volunteers from our 65 offices. So you see the geographical dispersion. So we were lucky enough to have people all over the world, early enough stages. So we actually did what was for the business perspective, the most sensible, we use their local experience. But this process, of course, was difficult to scale. And it was difficult to prove the quality. So we also we had some basic materials localization, but not recession technology. So we wanted to change this. And the step one was actually choose the translation system. Because we didn't use translation system as such an external information system, we had something developed in house, but was far from a proper translation, we ventured out to find one, because it really got to that level that we needed. So the step one was to choose a TMS and then choose a translation provider that will work within the system. So I'm here to be no problem. Okay, they're all easy. Yeah, not really, not really. So let me tell you the story about choosing a TMS and choosing the agency. And then with some final notes. We have Preet had say pretty simple yet pretty wide requirements for TMS, we needed an online system, with API with WordPress integration, of course, and easy to use Cortana for people to use order sufficient and monitor the progress and a solid translation editor to make things easy for the translators. Both internal people, sorry, and the agency of course. But beyond the product UI was what was with in our request, what we wanted to have a TMS it could also work, not just through API, but for our marketing, and documentation and other content, you know, the traditional translation content, no continuous integration. And that was kind of tricky. So we started with 10 candidates and TMS is the process was exhausting. It was slow with unexpected time unexpected findings. Here's our top 40 participants. Some of them are expected some of them not so much. So the first one was usability and functionality. Some tools were simply just too complex. I have experienced with a tokenization industry in the tools, and I was unable to make my way through it. Really not acceptable in 21st century. One tool was not even possible, we will not be able to test it without the assistance of the salesperson alphabet to impossible, which is quite weird again in 21st century. One tool had a great translation editor but a very basic TMS so great later, but very, very simple and not scalable transition management capabilities. And one was very expensive, but surprisingly, would rather broken or poor functionality, in our view, you know, things not working as they should. But reviewers not receiving an email invitation to join the platform or later to review a project. It's really it was really an eye opener for us. So one tip, I'll be throwing out tips along the way, have the tools tested by future users too. So don't just rely on business or tech people's feedback that you know, the primary stakeholders get the users from your company to test it to see if it works for you, because otherwise the return on investment will be really degraded. And now the secondary price for TMS is was the cost in the pricing models. One, TMS literally hid their pricing, literally no commentary that no one changed pricing on the fly. So what was the some some details that were presented to us in the beginning, after a few months, when we narrowed the few weeks, actually, after we narrowed the number of candidates, it actually changed without us being notified? One set an incredible, but really incredible price tag just to use it and start using the system. I mean, we're looking into online tools, it's a cloud based system. So it doesn't matter if it's business to business, really, the cost does not justify the features offered. And this is how this is acceptable. It was surprise for us. But maybe it is the reality of the tools out there several charts for the system by the number of users, which is kind of difficult to predict if it catches on how much you will be paying in one year or two. And we are hoping to have the system catch up. It was quite traumatic for us. So please insistent pricing, always have it written down and asked about the cost of the other comparable clients. The things process. Now this is really shocking. Something's really bad demos, but really bad. I have average expectation, but this was really on the other hand, there was one tool that never said no to anything, whatever you ask them, do you have this feature? They will say yes. Although the actual explanation is something a workaround of a workaround. But they will say yes to everything. One thing to reply to after five days, five days to some very good news that they were shortlisted, actually, they failed to reply after, I think five days, we had to reach out through other channels to them. One had fantastic sales, but really disappointing product, really disappointed. So tip, ignore the sales pitch, I have been good or bad, just ignore it. Keep your focus on the product and the things that you need out. And versatility. Some didn't support occurring, continuous projects, some didn't support ordinary find like Doc kicks on PBX. That's a problem for us because of the marketing side of the users. And some interestingly had no idea what TM alignment was, let alone have it now or maybe too long in this industry, but some had no idea what it is. So tested system without departments if they're supposed to use it because of these file formats. But in the end, it took us three months to narrow down to one TMS. But we survived. We needed a few weeks more to test integration, but that was okay. Next Step Find the LSP client. So the LSP was work even simpler find the global LSP that would work within this selected TMS should be okay. We talked to five ISPs or through recommendations research and that kind of stuff. It went faster, but again with some unexpected findings, this time play surprise pricing model. Again, lack of Lesvos privacy policies minimum fee is a no no in continuous localization. If you're working on the LSP side, find a way around the minimum fee because clients with continuous localization will not be able to work with you. If there isn't enough, the automation may help. So also bring someone if you're talking about pricing. Bring someone who's dealt with this kind of stuff already. In the industry. Now test results. One premium tier LSP has spelling errors in the destination, no comment, one use the forbidden term from the glossary in the desulfation. Again LSPs and TMS is now this is this was unusual. One LSP was offered as a verified vendor through through a tool, but they openly admitted they were outsiders. So that was the stent, of course to lure you into their primary TMS that's good for their business. There's bad idea for you if you have continuous localization because you get detached things to pay attention to the process that they want to use. We finally of course took a few months to choose it signed the contract we negotiated a deal around the minimum fees and we're done. Now, we still have some few or some questions to answer. We are actually only beginning I've recently taken over this, we're only at the beginning, we need to answer the question, are we providing adequate adequate context for the translators? Just giving us strings? Never gonna be good enough? How should we do the alquiler? Review the final review of the rock IV? Why should we do it at all? Some people are saying it should not be done. How do we measure the quality? And that does not include the KPIs and metrics that are from the 90s? How can we collect feedback from the users? Because what they say is what matters the most? Should we switch to using the freelancers? When exactly should we use machine translation now for of course, for which content one engine or have them different language? And finally, how to integrate with design tools, you know, this, there's the shift left approach to what the designers so helps you reduce costs if you integrate with design tools. So we have yet to look into. So some final thoughts, I'm actually more or less on schedule. So we'll have time even for questions. Of course, some final thoughts, just, it's obvious from what I've said before, localization is the means meet common, given the title on the conference. So living organism, and continuous localization is just its latest form, it will change soon, there may be something hugely different, which we never know. But things are speeding up. But in any case, reinventing is really needed. own metrics, workflows, rules, simply do not apply. Deals, localization is technically the most advanced niche and industry. So it's a mismatch between what some parts of the industry during this is really in sync with the development and tech companies and what they are building. And one great, great contribution of the involvement of engineering minds into localization is that they have brought with them the the best practices sharing. They really have. They're open sourcing stuff, they're sharing their experience, they're creating communities in a way that developers do this that was not so common in our floatation industry of the old days. And that's a great thing. So it's safe to say, really, based on what we've heard so far, it's we really have some very exciting times ahead. So yeah, thank you. Thank you. I think we have some room for questions like two minutes.

Max Morkovkin 27:36
So we are Thank you very much. Yeah, we have some time for the questions. And there are several questions already. So let me help you to read them. Yeah. Haven't read any windows.

Semir Mehadzic 27:47
Yeah, actually,

Max Morkovkin 27:49
some equations were already voted. So let's start with them. Josh, I'm sorry, exact Josh Wojcik. So the question is, can you provide more details on the deal you made with LSP, about small jobs, minimum fee, there are a number of hours you pay for etcetera.

Semir Mehadzic 28:10
Just in short, we negotiated the day we would automate the stuff. So the small jobs like less than 300 words, which would fall under the minimum fee usually would go straight to the Freelancers pre default pre pre assigned. So they don't have any project management to do. And we would give them 48 hours to translate. Even if it's 10 words, they have to bring have some rule because they made a deal to cater for our needs. We gave them 48 hours, at least working days to get the athlete, even the smallest project back. That's what might work for us. We are yet to see how it develops in a year. But that's what where we are right

Max Morkovkin 28:48
now. Cool. Then there is another question from 18. First week, what is the difference between CL and CI CD can CL be done with Jenkins, which is the best tool for CL

Semir Mehadzic 29:05
CL CL crystallization is just the contract with a CI CD, which is usually powered by Jenkins and that kind of stuff. So we can last at the end. So doesn't matter which type which tool is useful for CI CD pipeline. More or less, the open source architecture for continuous localization can handle so it's localization might be detached from whatever tool you are using.

Max Morkovkin 29:35
Cool. And another question from adding files like this topic seems very odd. Okay, sorry. Yeah, another one from Peter lipoxin. Concerning no minimum fees. How do you find engaged, enthusiastic and willing translators to participate and seal projects if there is no minimum fee until they have bigger clients and projects to work on, they will be quite reluctant to waiver their minimum fee and work for a couple of

Semir Mehadzic 30:08
I see when it's a good question, look, at this point, this is why we opted for you to use an agency, the beginning, continuous localizations seems to be working the best with freelancers directly pipe in the pipeline. But then to avoid the problem you have people have retainers, they give some guarantees, some to the freelancers to be at their disposal. And I believe that that model is the best one. I know some great tech companies are using precisely this morning. But we are right now in the stage of setting up for continuous localization properly. And we couldn't afford just at this point to look around for freelancers and engage in this relationship. So we left it up to the agency to negotiate how they're going to take the translators in how they're going to retain them at this point. But it's a very, very tricky thing. And we will be seeing how this develops. But our end goal in a year or two is to move to Freelancer because it's it's logical because of the lack of processing, and no need for pm for the software part we can we can do with freelance directly.

Max Morkovkin 31:13
Somewhere is getting hotter and hotter, more questions coming. So let's answer probably the last one. And then we will ask you to answer the rest of the questions in connected translation community. So the question from Katherine Hossler, are there already some ideas for your LPR reviews and how to measure the quality?

Semir Mehadzic 31:36
The greatest shift mind mental shift for myself who was working with being actually the accurate reviewer for tech companies for my native language? And they all use, you know, counting types of errors and that kind of stuff. And if there's three errors of the source, the translation fails, that does not make so much that sense in such a precarious environment. And it makes it does not make sense. In the long run, why the quality is not what we linguists say in software, of course, it's what your users say, if they are okay with the translation, whatever it is. And that's good enough. That's the answer one more question that was in the chat. How do you define good enough? If your users can use and you have, you see that users argue again and using your product and loving it? If there's an imperfection, I would even say doesn't matter. And that's that's a heresy for myself, a linguist by education, but it is it's if it's good enough for the users, then it's good enough for us. And that's why we mentioned we need to figure out how to get that really get and collect feedback from the users about translation, not just some random support or survey, really enable pipeline to get the feedback or corrections based on something that's not perfect.

Max Morkovkin 32:51
Simulate, thank you very much for this great presentation and bringing this topic to our audience was really interesting. So keep in touch with you and we have to move forward now.