A Walk on the Wild Side with Continuous L10n!

Igor Afanasayev 00:04 All right, and we are back at Loc from home. And we're back and ready to welcome the next speaker from sunny and warm San Diego. This is Rebecca Ray, who is a director at CSC research. And today Rebecca will share the findings of the latest research they did on continuous localization, my favorite topic and my favorite speaker. Rebecca, Rebecca Ray 00:26 thank you just hope so don't don't stop me if I make a mistake, or we'll just kind of go over it and pretend I didn't. All right. Sounds good. Good. All right, I'm going to share my screen in just a second. And the topic is a walk on the wild side with continuous localization. Are you ready, because I know that several of you out there probably haven't actually gotten, you know, to implementing the model. But we're seeing more and more companies do that. So one thing I just wanted to say before we start the polls, or I bring up my presentation is that back way back in 2013, we did a big dive into continuous, or at that time, what we were calling agile localization. And the reason we did was because basically, the model was broken for a lot of people who were attempting to localize software. And if we fast forward now to the year 2020 2021, the model really is broken again, because with with all of the cloud products, with AI with augmented reality, virtual reality, all of that, it seems that even though these models that went really fast before a lot of people have come to us and said they're broken again. So that's why we decided to take another deep dive, we interviewed 53 people for this. And we included all sorts of different kinds of companies that I'll explain in a minute. So if my friends at SmartCAT, I think that you all will start the poll, I think and then Senator, if not, I'll go on with my slides. I think we've got two polls. Yeah, so the first one is very simple. We just like to know if how many of you have implemented what you consider to be a truly continuous localization model for one or more of your code or content workflows. So it could be for software code, it could be for marketing content. So I'll be quiet in a second, the code is 382022. And you can go up to www.mente.com. So we'll give you a second to respond. And we'll see how many out there are involved with these. What we found is that more and more people obviously are adopting this model, or at least trying to speed up what they consider to be agile localization. So we don't have a lot of people answering out there, but I'll give it another second. Put it up there one more time. What we found is that as I started to say, more and more companies, so obviously, almost any company has some kind of software. Now and and, and documentation, customer support stuff that they can put into this. So we're seeing more and more companies do this, you don't have to be just a software developer, you know, to be able to do it. That's fine. We don't have a lot of answers to this one. But we'll go on to the next level give people just another second. People might still be drinking their coffee, which is just fine with me. I spend most of my time in Turkey. So I understand what when people need their coffee. All right, let's go on to the next poll. And we'll see if a few more people answer. On this one we're asking you, we're curious to know what your number one challenge is related to continuous localization. And so it could be that you haven't started yet, you're not sure where to start. It could be that your engineers, and other content creators aren't taking 100% responsibility for what they're supposed to be doing for World readiness. You're trying to implement continuous localization with a traditional mindset, you might be you know, having trouble supporting the right level of context. That's the fourth one there, balancing continuous localization with the quality of produces or compensating language partners equitably. And I know that there are other challenges besides this, but we found these to be the top ones for what we were doing, as we did our research. So again, some of you are just trying to figure out, Oh, where do we start with this? And the second or third people taking responsibility for the code, and then trading, trying to support the right level of context. And those really are the two biggest challenge that we found we found as well. Leave it up for there for another second. Yeah, still a three and people taking responsibility. It's a big one. Okay, all right. With that we're gonna close it and we'll jump into this and what we'll show you what what our interviewees thought, and let me share my screen here. And let me make sure Are my way they should give me just one second here. And I'm gonna flip back over and make sure. Now you all still aren't seeing what I would like you to see. So hold on just one second. Let me just get out of here. And I actually do practice this. So I apologize. All right, let me see again. All right, we have the same issue. I know during practice. So you see, I can bring up what I need to I'm so this isn't working, Igor. Igor Afanasayev 05:38 No problem, I think I think right now we see your screen. And at some point, we did see your slides. So Oh, my Rebecca Ray 05:44 goodness. Okay. Let me flip back over. Because that's, that was not what I was seeing. All right. I'll give it a second. Igor Afanasayev 05:51 Yeah, and if you Yeah, absolutely. So we do see the the first page of your slides the Rebecca Ray 05:57 title slide. Okay, sorry about flipping back and forth. Prior to that. I've been working with software developers since the 1990s. Anyway, all right. Okay, so let's go on past the polls here. And just 30 seconds, I wanted to let any of you know, who are not familiar with CSA research, where do we get this research from? We're totally independent. So people don't pay US companies don't come and pay us for research. Obviously, people who subscribe to our research do help to pay my salary, so we can keep going. But there are 20 there are sorry, there are five full time analysts such as myself, plus a new data scientists. And we basically breathe, sleep, eat, drink, you know, global business all the time. So we also take a look, we obviously look at the the language component of global and going global, but we're looking at everything else. So similar to what Talia was talking about today, during the keynote about the strategy about how to enter markets, when you do if your back end infrastructure is customer support, doing what they're supposed to our financial colleagues tracking revenue the way they're supposed to, we cover all of those issues. So we obviously talk to people on the people who buy language services and Strategic Services, as well as language service providers, technology providers, such as SmartCAT, who are very important in this ecosystem. And freelancers, even more important than linguists who put all this together, and then global consumers, we also run big panels for the research that we call can't read won't buy so that we get up to 1000s of people. I do. We do both quantitative and other words, surveys, numbers and qualitative research. Today, what I'm going to be showing you is actually based on qualitative research that we did based on interviews. So that's enough about us, I just wanted you to let you know where we get all this stuff from. All right. So for what we did is we went to 53 Different companies, and most of them were on the buy side. But we also talked to language service providers and technology vendors, because they had a lot of really important information to give us about how can they see continuous localization either being implemented successfully, or not so successfully, you know, in the companies that we talked to, so they had a lot of really good insights, actually. So that's where this research is coming from. Now, to make sure that we're all on the same page, we decided to ask people their definitions of what they consider agile localization to be, versus continuous localization. And what we found is there, every one had a slightly different definition of each one. But basically, when we took a look, here, the two definitions we found, the first one for agile localization is basically automation that runs on a schedule. And it's normally tied to some kind of a deal development cycle, whether that's for software for content, and there's going to be some kind of a barrier, whether it's hourly, daily, nightly, weekly, whatever, when stuff is handed off to localization. It's basically I mean, a very simple definition, but that's basic ly what we found for continuous localization, people tended to use the words like instantaneous, continuous obviously, in other words, the content or the code source is coming all the time. There's no barrier in terms of when it's handed off, we're not waiting two days to get a hand up. This stuff is all coming to us and we are integrating things back in with no schedules, no artificial delays. So that's basically the difference although you will hear people use the two terms interchangeably. Let me take a look at my notes because there's actually two other definitions that I liked. One person responded and said yes, waterfall which is we consider to be the old older way of doing software development or you have a release you tested. Then you go back and make fixes then you have another release in other words, it's not really a circle it's more of a linear process. So this person said that they defined water waterfall as Wait wait wait go live. Then continuous or I'm sorry, that was waterfall Wait, wait wait go live. Agile was more Wait Wait go live Where's continuous was no wait, always live. And then my favorite was actually from a person who's been in the software industry for quite a while, and she described it as continuous localization is like buying or like baking cookies, because you're constantly putting new cookies on the sheet. At the same time, you're taking off the cookies that are done, but you never have time to clean the sheet. And I know that's really how, you know, on the localization side, that's how people felt as they describe it to us. Alright, enough about definitions. Now we know what we'll be talking about. Let's take a look at some challenges. So what I wanted to share in this presentation, we came across 11 major challenges whether a company is taking a look at implementing a continuous localization model, or if they're trying to optimize there, so I'm going to share five of those with you. And the first one we found was really, people need to define how continuous they really need to be. And it should be based on customer needs, not on the needs of your own requirements for developers or for your team. So you have to figure out so to give you an example of this, what we found is talking to companies that are still involved, especially with providing enterprise solutions, and that could be software, it could be other kinds of content, that the feedback they often get is stop. We don't need a release from you guys every week, every day or maybe even every month. And the reason is because they have things that have to happen on their side, when they get you know, even if it's a simple upgrade, sometimes they may need to train people, they may or may need to roll out software, even if it's just on mobile phones. So again, to really concentrate and focus and see, okay, what are our customers expecting, then that's how we need to take a look at what our model looks like. Also, the people we talked to on on the language service provider side had several war stories about how they had customers coming to them saying, Okay, we're not continuous, but you need to be to make up for the fact that we're not continuous. So obviously, that's not a very workable model. And there are way too many, I think, you know, companies, enterprises coming to language service providers saying that, so you want to make sure that you don't turn out to be, you know, a customer like that. The second challenge is to be on the lookout for the Spotify model and all the find that for some of you, you know, who might not necessarily know what that is, or research, this is important, because our research revealed that more and more companies are looking at this model. Originally, it was applied to software, and I'll explain it in a minute. But it's being applied to all types of content and all types of business functions within organizations, especially big ones now, so it's not necessarily just software development. So at a really basic, basic level, it's that developers on whatever kind of software, and now we're talking only about software, they're divided into very small teams, and they're called squads. And these roll up into chapters sometimes or guilds or tribes. And what's important is that what it means is that even more so than with Agile or with continuous deployment models, that these people are switching around on their team. So one week, they're working on something else, a couple weeks later, they may be working on, you know, whole different parts of the software. Now, if it sounds like chaos, it is. However, engineers love this, because it allows them to be more creative, because part of this model is allowing the developers that they don't have to hand off stuff and have, you know, such a official, you know, planning on their side, so they can be more creative. They feel like they're getting stuff done faster, and all that. And that's all fine and good. It means for example, if they miss a release train that they think jump on the next one, it the model allows the developers to hide certain functionality. So that the functionality doesn't disappear, you know, people can come back to it, but at least it's not getting in the way of what they're trying to develop. Now, the problem is that this causes really even for Spotify itself. We talked to normally I don't reveal that, but I don't think they'll mind. We did talk to them for this research. And they said, Yes, it is chaos. And we've been working on this for several years. You know, here are some recommendations we have. But yes, it's just as chaotic as it sounds. If some of you want more details, actually on the model itself, from the point of view of localization, listed at the bottom of the screen, here is a blog entry that we did a couple of weeks ago, where we provide a lot of details. It's called implications of the Spotify model for localization teams. And we talked a little bit more in detail about the model and how it applies. So what I want to point out is that with all this control, chaos going on, what's really key from the localization side is that at this point, if you know who's ever creating code, and if you started to apply the Spotify model to content as well, the responsibility for World readiness for this stuff to be designed in the ways that Talia was talking about during the keynote has to be the responsibility of engineers and content creators. There's just full stop. Because the problem is if you if this isn't the case, then every so often, you're stuck was going to stop and you're no longer continuous as you have to back up and retool, or re architect it again. It's totally toxic. out today. So I know this is a hard one. But certainly a lot of companies are a lot further along the line today really getting the responsibility for World readiness back where it needs to be. And I know in the next panel that we'll be talking the next group, they're going to talk probably quite a bit about this. So I do want to warn you that again, repeating myself, even if you haven't heard of the model, and you haven't heard any rumblings at your company about this model, I would recommend at least reading the blog entry. And then this source here where this cartoonish thing comes from some of the developers at Spotify, who first not that they necessarily first came up with a model, but somehow, they tended to be more active in terms of evangelizing it. And so you'll find quite a bit on the web and different YouTube videos that you can watch about, actually, that are further entertaining, explaining how the model works, you know, from the point of view of development, as well as the rest of the company. And I think once you take a look into it, you'll see why so many companies are actually taking a look at it in terms of trying to get their people, you know, to move faster and to be more creative. So enough on that just wanted to warn you, if you haven't heard about it, just make sure that you, you know, go on ahead and try to educate yourself about it. Now, in terms of back to talking about the continuous localization model, in general, you need to be ready for the model to proliferate, all of our interviewees told us. So in other words, you know, even though it may only be used right now, within software, you can expect, especially at newer companies that tend to move faster than some of the older ones, you'll see the model proliferating out to cover oops, sorry, didn't bring this up beyond software strings, especially to these areas, marketing content, technical documentation and knowledge base knowledge base content, and it's even being applied to others. But those are the major ones right now that we see. So you need to plan accordingly on that one. All right, the next big thing that people when they were talking wanted to talk to me a lot about. And I should back up a second explain to you. When we do interview intensive reports. And I do a lot of them for common sense. I really, statistics and data are really important. In many times we combine the two will do well, you know, obviously run the survey and then do interviews on top of it. But what we find with the interviews, even when it's a topic that maybe we're not as familiar with, normally, by the time we get to the sixth interview, eighth interview, certainly by the 10th interview, it's like we're really hearing a lot of the same things. This is the first time in my over a decade working for CSA research that every single person I talked to, had a different take, not only had something different to say but something they felt really passionate about. So it was really quite interesting. For me as a researcher. The reason I'm pointing this out is that when I say that people were talking a lot about, for example, the localization, the continuous localization model requiring more than just automating processes. That meant that a lot of people were talking to employ them, this isn't working, you know, we had to find a better way to do this. So what I'm talking about here is that obviously, when, when many of us, I mean, even those of us on the outside, maybe not running a model like this, we tend to think okay, automation, continuous localization, a lot of focus on the TMS on the translation management system, you know, how do we automate our processes, and that's part of this, that's important. But that's not the biggest part. What people told us was, even though these words are somewhat overused, rethink reinvent re architect, that's really what's happening here, that you can't get away, you know, with trying to shoehorn this into an old way of doing things. And I'll point out that it may happen to on the development side, even though your company is claiming, you know, we're doing all this stuff continuously, it doesn't mean that developers catch up, we're content creators catch up with the new model as soon as they should. So many times for us within localization, we, this stuff comes to us and it causes problems for us that we have to deal with. So you need to be vocal about that. If you see, you know, if you're if your executives are claiming we're continuous, this is what we're doing and you're finding parts that are not, then you need to speak up and make sure that people know about that and that you collaborate with, you know, people within your company to to fix this. So back to shoehorning. So in other words, what we were hearing is one of the worst things that you can do is to try to put this into an old model that goes slower, it's just not going to work. The other thing in terms of rethinking, and reinventing and re architecting is really, this will turn you into a product manager or at least for that part of your day that you're focused on this model. Again, whether you're trying to implement it or optimize it, you really need to think as a product manager. And I know that we're talking more and more about that within this industry that really a lot of localization is being the product manager. So because you're working with all sorts of people outside in the company the same way a product manager would you're not only looking at language or looking at a lot of other things. So as you look at the continuous localization process for yourselves, you have to come at it from a much more holistic view. Obviously industry Search, we have more, you know more comments about how to do that if you need any help, we're more than glad to have some calls with you. And to help you kind of reset your thinking in this area. The thing I want to point out, this is one of my favorite things, because I have to admit, back back way back when, when I was an international product manager, when Silicon Valley still had those, I used to engage hapless engineers to do my bidding, because that was sometimes the only way I could get things done if I couldn't get to the software architect. And I know that that's still somewhat done. It's done on the content creation side, too. But I want to encourage you not to do this. And here's what I mean by this. What we see localization teams doing in this area oftentimes, and even interviewees brought up the issue as well, is that they'll go out to an engineer and say, Okay, we have a new TMS or a TMS, we want to upgrade, we need to catch up with software development, you know, here are the API's, the application programming interfaces, please help us put something to cover. And the poor engineer who usually isn't really versed in localization may know some stuff about it still doesn't have an idea of what it could really be, if you really rearchitected took into account what you could do with AI and all of those kinds of things. And so what happens with these projects is that yes, something will be developed out of it, but it probably won't be totally successful, it may even fail. And then people try to figure out, Okay, what did we do wrong? You know, why did we end up spending money, and we're no further than we were. So I'll get off my soapbox. But I just want to encourage you that that old model of bribing the engineers doesn't necessarily work that well for this, because they really, they don't have enough background in terms of of what they're doing to be able to do what you're asking them to do, when it comes to reinventing all this, it doesn't mean you don't want their support and that you don't want to collaborate with them. But you shouldn't put full responsibility onto them to try to figure out how to do this. Now, the next one is probably no surprise to anyone in the audience, even if you're not really familiar a lot with continuous localization. And that is the issue with context, especially when it comes to software code. I think most of us would agree that automation almost always decreases the context available to linguists. And again, I'm generalizing. But certainly I think it that happens a lot. And and the real reason is because context isn't ever built into content or code flows. I mean, it's the same issue for people who tried to test software, or even to test websites, even if they're not, you know, responsible for the multi lingual versions or the international versions, they're still looking for context to help them go, Okay, well, how many different CANCEL buttons do we have? should they all be translated the same way in every single context? And that's a really simple example. But but, you know, still affects a lot of people. What we would encourage you to do is that as you're thinking, Well, as I should point out, this becomes a balancing act, right? Between going okay, how automated do we get? How much context can we provide to people, you know, that kind of stuff. What I will say is that, and this is an older solution, it does work if your company is large enough, and has enough resources to do it. And we talked, I think, three or four very large software companies that are doing this, that they have, they have had, they have the resources, and they have built their own proprietary system to match their strings, you know, and put them into context, the problem becomes is that you can provide context for, for software strings. But, but a lot of times, because of the way the software works itself, there's no good way to actually hook it back into show context in every situation. And that's the problem, there's no off the shelf, you know, package that does that for every single software package, you could do it with content, it's much easier to do these days with that with Cloud versions of TMS systems out there. But in terms of really being able to match everything up, most companies can't do it. So, screenshots are used in the research, we talked about several different solutions based on that those solutions provide context, but still, you know, require a heavy load, you know, either it's gotta be on the developers or somebody and test to do that. And I will say, well, we'll talking about screenshots, responsibility. And I was Kelly felt strongly about this, coming into doing the interviews tried to keep my mouth shut, but did find you know, that most people did agree that if you're going to go the screenshot route, then it's up to developers to do that. In other words, they need to be providing them they need to be providing the comments, you may need to train developers to do that, but you don't want to take that on yourself. And so if you've already taken that on, you need to look at ways to take it off of you because again, that way you actually get back to what the root cause of the issue is with developers they have to take on more responsibility. It helps them write clear code. And I will say, I don't have a separate slide on This, but we go into quite a bit of detail in the report as well about how to train or you know, to provide ongoing training for developers because it's just crazy. But I guess I'm thankful because it means that I still have a job. But basically, I think all of us know, if the if software coders, at least those who choose to, you know, get a computer software degree and go to school, you would just need to take off a couple of days teach how to teach them how to do this, show them the examples, and I wouldn't have a job, for example, and some of you wouldn't be there probably. But that's not the case. It's still where, you know, we have to take care of it, someone on the back end, so the more that you can push upstream, the better the, these models for continuous localization will, will work. Okay, I know I've been on my soapbox for this particular issue, but it's really a big one. It's the one that keeps us from really getting to the point where stuff is smoothly automated. And you can basically handoff stuff, you know, without worrying about. So since there's no good solution off the shelf for software right now, what we're encouraging companies to come to us to do is to reframe the challenge. So not so much looking at it from the point of view as Oh, my goodness, it has to be high velocity content or code creation, you need to be taking a look at okay, what does it look like from the point of view of high quality, you know, customer use of what we're trying to get out there. So what that might mean is that maybe instead of investing so much in continuous localization, you might be investing more upstream, you know, to improve your content, you might decide maybe to do more video. In other words, there are lots of different ways you could go, depending on what you think should be done with this model, and what actually needs to be done with your content and code. Now, I know for someone like me, as a research analyst, it's really easy to give out this advice. But we're here to help you with it, we know that this stuff works for the companies that have done it. And we understand that many of you on both sides on both the buy side and on the supply side of this industry are always running, you know, 18 hours a day, 12 hours a day to try to make sure everything gets done. But it's really important. Sometimes the backups sometimes go okay, what as Talia said, you know, what are we trying to solve here, and what would be the best way, maybe producing more content faster is not the solution, maybe we should be producing less content or less code, you know, in a different format, you know, for our customers, at least internationally. So again, we know it's not easy, but we know this stuff works once companies take a look at doing this. Alright, enough on this sorry to spend too much time, but it's a huge one. So I want it since I've only shown you some of the challenges, I wanted to give you an idea of what's in the rest of the report. So you have an idea of what what this stuff looks like. So we take a look at the issues whether we're talking about agile, continuous, we talk about four drivers that's really pushing continuous these models. And then we take a look at 11 challenges, as I mentioned. And then probably the more interesting part of the report is that we talk about better practices. And of course talking to all of these people have lots to share. And we divided them into governance and into strategy, evangelization implementation, process, organizational structure, automation, context and quality, what I just talked about, and then language supply chain. So we've got tons and tons of advice that people shared, whether it was here's what we did, right, here's what we did wrong. Here's what we would do differently. If we were to do it over again. And we've divided it into these areas so that you can just jump into where you need to talk about trends. And then of course, as we always do with our research, we provide recommendations for it. So I just wanted to give you an idea of what was in there. And of course, your even if you don't subscribe to our research, please reach out to me what we're always happy to share this information with and whenever we can. So here's some other stuff in the report so that you know how we broke things down there, there are several workflow samples that we have in there. This one happens to be marketing content, not just the software. So we tried to say go look at the International part of it here in terms of design, and oops, come back here, design and authoring and the automation that needs to take place here. And then as it comes into the different code repositories and content repositories, and then obviously the translation issue over here. So a b testing, all the query stuff that has to happen, but we provided lots of these to give an idea to people so as they're thinking, obviously, this is extremely simplified, but at least to see okay, what's possible these days to put in as we're trying to automate either all of it or certain components of it. We also included lots of tables here with lots of questions. This happens to be on implementation to driver give. Obviously, we can't include everything in the research but to give people a good place to start. There are a lot of questions here. So again, categorized so that people can take a look at them and go okay, this is what we need to do and to think about. So there's a lot included, threw out there to to help people with that. So I know that I've ended early, but I wanted, I want to riff on some different areas. But I also wanted to give all of you a chance. If there's some of you in the audience, either you're just starting on this journey, and you're not sure exactly where to go, please feel free to ask your questions as well. And then any of you who are either supporting this kind of model from the LSP side, or from the buy side really involved in the model, we'd love it, if you would, you know, share a few things with the audience to tell people Oh, my goodness, this is what we should have done differently. Or I wish I'd known that before we started. So before I continue talking with anyone, I think, Igor, we're fine if we unmute people, I think and allow them to speak. Igor Afanasayev 30:44 Yeah, so right now, we don't have any questions so far posted in our q&a tab. And I encourage everybody to actually go ahead, I do have questions. And we can talk about continuous localization pretty much forever for you there. But I guess, and this kind of ties to, yeah, it ties to the, to the poll that you had at the beginning of your of your talk about what are the main challenges with continuous localization people do not know where to start? Sometimes people do not know how to ask the right questions, because it's a really challenging topic from the technical perspective. So as we will be waiting for for for q&a, or questions to go into go in, I believe you wanted to share some gifts, some book? For the best question, I have a one to one Rebecca Ray 31:37 and I have other things that I'll jump up on. Okay. So the I can't, because I know I have it here, just give me one second has to do with meetings, I wrote it down so that I would have it and the name of the book is The surprising science of meetings. And the subtitle is how you can lead your team to peak performance. So a typical title out of Silicon Valley, but since so many of us are in so many meetings, whether it's virtual, or whether we're physically there, I thought it might be something that that would be valuable for people to have. So encourage any of you to ask questions, if you want to. So actually, Igor, if I may ask, because I know that you and I talked about that we SmartCAT was in to provide I suppose I can, you know, reveal that that we interviewed you as well as some other people at SmartCAT, about this. So what do you find eager when you go into companies that either you know that have a model that you wish they done differently? Or if the if you wish that they come to you sooner and ask certain questions, what do you struggle with, with your customers to get them up to speed on a continuous localization model? Igor Afanasayev 32:43 I believe it's something that you already covered in one of your slides where there has to be a mind shift. Right? Sometimes people are coming to, to us and not to us, because I speak to people who are not our customers, specifically, but we I love to talk about this topic. And people think about continuous localization in so many different ways. So it's really hard to start the conversation before actually defining what a continuous localization means for each and every person in the room. So yeah, defining defining the goals that people have, and then trying to understand how continuous localization can, you know, improve the quality of their life, their, you know, work within their organization, is something that people want to know and want to understand for themselves first, before diving deep into the technology side of things. Rebecca Ray 33:40 So yeah, sorry to cut you off. But I think a lot of times, you'll find, too, that you have a certain definition, you've worked with the customer, and then you go into the next customer is like, Oh, they're like talking about waterfall, and they're calling it continuous. And, you know, if you have to kind of go, that's not quite what we're talking about. So that's a big one, for sure. Okay, Igor Afanasayev 34:00 we've got some some questions, and I will be going through the top of the list, because you everybody in the audience can upvote the questions they want to have answered. So the first, the first one goes from, etc. Hi, how do you recommend trading the engineering team for continuous localization? Rebecca Ray 34:18 I'm sorry, in which which teams teams in general or Igor Afanasayev 34:21 engineering team, how do you approach engineering team? Yeah, sure. Rebecca Ray 34:25 And at you feel free to jump in, because I know that you work a lot with engineers to try to bring them up to speed. A lot of it has to do with kind of where they are. And if you're in a company, and almost all of us are where you've got more than one, you know, one developer group, you're going to find, you know, different groups at different levels. So you have to kind of figure out where they are. And then what I think what a lot of us who've worked with engineers, no, and Igor, you could probably confirm this. It's like, you guys are really smart, and you're creative. You just want to know what you're supposed to do a lot of times and what the goal is, so that's part of it, just making sure that that engineers are aware of what the bigger picture is, and that you have some kind of ongoing program that as engineers come on board, or they go to different teams or take on different responsibilities, that you've got some kind of a program to back them up. So whether you have to think about it from your corporate culture, right, do you use, you know, some kind of an internal wiki? Is it more on you know, social media that need to communicate with them, whether you get in front of them for a Loke, you know, lunch, whatever it is? Well, we found too, is that, and I was surprised that this that more companies don't actually take a look at the and I'm talking specifically about software, take a look at the strings to see what the quality of those strings are, and then start to track them. Because with the technology we've got today, you can track the kinds of strings that work and the ones that don't, and that you can actually give remedial training to people as well. And we have to remember that many engineers at many companies they're writing in a language, that's not their first language. So some companies even go to the point of actually having someone edit those strings. Other people simply make sure that this stuff is reviewed. So again, I we know that we don't want localization to be looked at as the gatekeeper, although we found that some companies actually have implemented a system where they are the gatekeepers. So in other words, that they have to sign off international signs off on what the original designs for the product are, they sign up during certain, you know, times within the international development, too. So again, it kind of depends on your culture, and what you need to do there. But I think the most important thing is to make sure you've got some kind of ongoing program to settle those engineers in, so that they know what's there. You want to have champions on your teams, if you can have your big enough company, and you have people who cooperate, the biggest thing is to make sure you've got internal champions on those teams, you know, when that makes sense, and when you can develop them. So I'm sorry, I've kind of skipped all over, I can certainly write up something on LinkedIn, we have pieces of research related to this, you know, specific things you can do for engineers, but Igor, and anybody else in the audience who comes from the engineering side, jump in, you know, tell us what works for you guys, maybe we're doing this totally wrong, to try to, you know, communicate with people. Igor Afanasayev 37:12 I don't believe there's any single way to do it, right. And people in the industry, the whole trying to figure out what continuous localization is, and like where we're heading. So this is we are on the verge of, you know, like, changing the mindset and technologies. So the other question, that's the good one, comes from, from Nick. And he's asking, how do you justify an increase in the workload for engineers, and asset creators and product owners? If the proceeds result is that an asset is localized either way? Rebecca Ray 37:45 Oh, so in other words, hey, we're getting it done. It's being done well enough. Why do we need to improve that kind of thing? Right, I assume is what Nick is asking? Yeah, Igor Afanasayev 37:52 well, you need like, and I guess I would probably reframe it differently. Do you have an answer for people who think that continuous localization is actually not improvement of the process, but an increased burden? Rebecca Ray 38:09 Got it? Yeah. And either way, it's sometimes it is, you know, sometimes maybe it isn't, what the company should be doing. I know, we worked when I first joined CSA a long time ago, I was called in for a huge consulting project with a really big hardware software company in Silicon Valley. And so it was to, you know, kind of to wrap things up with engineering will also involve content. But I finally told the person who called this a that was paying us a lot of money and said, Look, your engine, you know, engineering is not the issue here, you all are generating more than 50% of your revenue from English right now. And it's stuff that customers want. So yes, at some point, you're going to push those engineers but now's not the time, we need to focus on some other things. So I just want to say that it's not always the best way, even in today's world, it's it's not always that you want to move faster, and get the engineers on board, you may want to do other things first, but back to those back to situations where you are convinced that it needs to go faster. One of the things and this is kind of outside the engineering thing, though, is to have the numbers to prove. And we can help you with that, to actually prove you know, the return on investment. And I know the last panel, that's a that's a bad word, dirty word to be using. But it really is. In other words, should we buy toilet paper? Should we invest in more localized content? Should we invest in a new product team? Or should we invest in a faster model for continuous localization? So the thing is to make sure that you have your numbers on the international side, so you could say, Okay, this is what we're earning. This is what we think we can earn. If we do more localization, and we get to market faster, you have to take a look at your competition. So it's not just the thing of taking a look at the engineering piece, but saying, Okay, what's the overall again, what's the overall challenge here? If it's to increase our revenue from these seven markets this year by 10%? What do we need to do? And if one of those Things means getting to market faster, or iterating. And always, you know, sending our NEW MULTILINGUAL versions out immediately, then you have to take a look at continuous localization. It's not an easy one, and it's not cheap. But again, you're where will you be in a couple of years if you if you haven't kept up with your, your local or regional competition. And again, as I pointed out with the example I gave at the beginning of answering the question, maybe it isn't always the right model to put into, you know, to execute, but then what you have to decide is Wow, okay, Eagle and SmartCAT came to us, they've got a good model, what happens if we don't implement it this year? You know, what is likely to be the effect on us? So all none of these decisions are easy, because if they were, none of us would have jobs. So the question is to, you know, get the right data, as was mentioned in the previous, you know, panel as well, and to make sure you're getting it to the right people at the right time. Igor Afanasayev 40:59 Thank you. They want to segue and kind of like provide a little bit of an answer to that question that you just answered by asking another question. So during the poll, I believe the second top thing that people were concerned about was balancing contextualization, and the quality for uses. And this by itself, to me, is an indicator that people do not really know how to implement contextualization and what it can bring. So do you, during your research, did you hear any insights from from people who you interviewed about how conditional zation could improve the quality? Oh, Rebecca Ray 41:39 very good question. And one of the big things that some of the interviewees brought up and then if they didn't, I often ask them about them is okay, how are you defining quality? How are you? What's the criteria? Is it based on customer input? If so, how did you get that input? Is it the right input to figure out if you want continuous localization? So first of all, you need usually companies have to back up a little bit and think about how they're actually defining it. But then once you figure that out, as you said, Igor, many times this does improve quality. Because as we know, those of us in this industry, we know that when we have good processes in place for localization, that it also almost always say the things that engineering and testing should be doing anyway. So what people said was yes, that it actually has ended up I mean, we I didn't do a sign, I didn't do a survey in this case. So I can't present the data to you. But in general, for the people we talked to on the buy side, I think you would find that in the end that they said that the quality was either basically at the same level as they had been able to provide it or had improved, because they actually were starting to focus on the areas where they needed to test. Because I think, Igor, as you know, many times a lot of the testing that's done, it doesn't really need to be done, it doesn't need to be tested three times, it doesn't need to be perfect. Even in software, you'll have a chance to fix it. And by speeding up the process, it's really focused people on going, Okay, some of this could be automated for testing, some of this quality is just fine. And some of the stuff that we thought was not in good shape is actually in good shape. So again, a rambling, very long answer again. But I would say in general, people find that the quality linguistic wise actually improves. Because if it doesn't, they've got to find a solution to it, right? Or if it doesn't, they'll often go, oh, the problem is not the continuous localization model, we actually had other structural issues, that we're affecting our quality. And I'm sure that you see that a lot when you go into companies. That would be my guess. Igor Afanasayev 43:42 Thank you. So the next one would be from Kate, what is your forecast on what is potentially next in store for continuous localization? Rebecca Ray 43:53 I mean, this is not so much Next, a very good question. This is not so much next. But we're already beginning to see it with some of the companies that are kind of out there, so to speak in the vanguard, and that is that they're applying much more machine learning to this and they're going, Okay, here's, we're going through an analyzing code, and we're realizing that you're making mistakes in these specific areas. Okay, we're going to either come in and train you on that, or we're going to have scorecards, and I forgot to mention this one EDS question as well. You know, here are the scorecards, here's what we're going to be judging and sidebar and scorecard, you have to make sure that you develop those together with engineering or testing or content creators. But that's the big thing is applying AI to this and going okay, where specifically do we have issues, you know, when it comes to quality, then another area that we're hearing more companies talk about so far? I mean, again, I didn't talk to hundreds of companies I only talked to around 50. So both of the examples come out of Silicon Valley that we heard of, but they're beginning to apply our P ai, which basically is robotic, Process automation. So this is where you actually go Then take a look at your processes and go. We think that this is taking us too long here. Why is it taking a project manager so long to put in their JIRA ticket, you know, not their work, but the elapsed time? Why does it take a few hours? Or why is the project or product manager even having to, you know, do it through JIRA. So those are the kinds of things that RPA will take a look at. And then once you figure out what your criteria is from that, then you can go oh, this is where we need to solve stuff here. Now we can take a look at quality versus turnaround time, we can take a look at you know who we're assigning to work on this on the on the vendor side. So RPA is giving people a lot more areas to take a look at. And it also gives you a lot of good data to take back to your executive to say, oh, did you know it took our project manager six hours to get those tickets through. And in fact, one of a company, you'd be very surprised that shared that during the interviews and immediately got executive support to fix that issue. So again, had nothing to do the project managers, it had to do with a lot of other people, and they had to wait for elapsed time. But I would say rpa, and then applying AI to the linguistics side, or to the things that we're seeing coming out Igor Afanasayev 46:07 so far. Thank you. And I would like to actually expand on this question, what is what is the future for continuous localization, and you had something about that on one of your slides, where you say that continuous localization outside of software is something that is emerging? Right? So you want to be like prepared for this next step? Now, my question would be, is it that, you know, you're the people you're talking to, during your research? Were they just aware that this is happening? Or were they actually trying to actively implement that so is that actually the future or something is happening. Some examples, or like some interesting insights from Rebecca Ray 46:50 the first one, I heard it out, and I was like, Oh, my goodness, this is gonna be big, was actually a huge consumer goods company. So people that are manufacturing stuff. And I interview both localization people and developers out of there, I wasn't able to talk to anybody in content. But what they explained was that the model was being implemented throughout the company, you know, to get things, you know, going faster. So everybody was taking a look at this continuous model, and how to apply it. So I think when it comes to marketing material, I think sometimes marketers already think they're kind of continuous. And on their side, they are right, they just keep producing more and more iterations and expected it to be translated. So I think some of the, the challenges there are to go back into marketing, and especially those people tend to be kind of add, with no offense meant to people in marketing, I've been on that site as well, that their attention to detail or their attention to what they're doing, oftentimes, you know, jumps around, they've got different people assigned and that kind of stuff. So it's also getting into them to say, Okay, you guys are continuous. Let's see how you're defining it. Alright, here's what we're doing, or what we think we need to do, how do we coordinate not only with your content repositories, and your tools, but with how your people are working. So that's the big thing, Igor, that as it spreads out among the company, again, it will mean that localization people need to get out there to talk to people to find out how other people's processes are working. Because at the end of the day, even as the localization team is integrated further and further upstream, all the way into content design, still part of it will be people knowing, okay, you helped us with the design, but we also know down at the end that you guys have to finish this. So if there are any problems, you know, you'll end up dealing with them. So that's the kind of mindset that we all fight against. And that you know, the further people can move, the better it is. But there's nothing easy, you know, beyond communication in terms of finding out how other people's functions work, and then how you can integrate into that. So it's difficult. We're going to have jobs, I was thinking we can all retire, right? This has gotten pretty easy, empty stuff better. Companies like SmartCAT kind of have us automated and now this whole thing is like broken again. So so none of us can can leave it yet until we get into a little bit better shape. That's kind of my my perspective right now to talking to everybody. Igor Afanasayev 49:13 All right. Thank you so much. I think we're out of time for questions. But we had some new, some really great questions unanswered. So we will try to connect you on LinkedIn. And I personally will be happy to share because I do have some answers for those questions. They just don't have time. Feel free in a position to answer them right now. So what do you think about Julio, what was the best question? Who you give a book? Rebecca Ray 49:37 Where do I go to I go to q&a, right. Igor Afanasayev 49:39 You go to q&a, and you can Yeah, I can. I can give you a few seconds to watch. We will start you didn't Rebecca Ray 49:46 make Talia do this. Okay, I got I have to do this live here. Okay. Igor Afanasayev 49:51 Yeah. And well, once while you're doing that, I will give it a little bit of announcements. So at SmartCAT we created a space A short guide for people who want to get some first answers on how to approach continuous localization. And it's called Automated versus continuous, where we compare the approach of like usual standard waterfall approach with for continuous localization for agile, and for, for continuous localization. So you can see the slide and you can scan the QR code to get that PDF. And this will probably answer some of your first question, so you will be better prepared for the next ones. Rebecca Ray 50:32 i It's hard to there too, that it's difficult for me to decide between but I'm going to go with Nick's question of how to justify an increase when other teams will pay it's going to be translated and localized anyway. Why do we need to make these changes? Why do we need to invest in it? So I'm gonna go with that one, Nick. Igor Afanasayev 50:49 Okay, cool. Congratulations, Nick. Okay. Again, thank you so much, Rebecca, for being with us today. It was really insightful, and I'm looking forward for my copies since you promised to give me okay, Rebecca Ray 51:00 I know. I know. I'm like a month late, hopefully. Yeah. It's just because all of you gave such great feedback that it's turned into a novel but you will get your coffee or your coffee, I promise. So bye, everyone. Okay, bye. Thanks so much.