Beyond technology: How continuous localization makes your organization faster, stronger, better.

Bryan Montpetit 00:00
And what we have coming up next is another session, which is beyond technology. How continuous localization makes your organization faster, stronger, better, presented by our very own ego. So I'll introduce him momentarily. But with that, the poll should be over. And we'll have Igor hop into us with us in a few few seconds. So we'll wait for him. And there's the man who's coming in. All right, just waiting for him.

Igor Afanasayev 00:32
One second. Let me spin on my camera real quick.

Bryan Montpetit 00:38
Yeah, sounds good. You're coming through loud and clear. Once we get the camera on, we're all ready to rock. There's the guy. I know him.

Igor Afanasayev 00:47
Okay. Hello, hello. They have a similar background as yours.

Bryan Montpetit 00:53
It's not bad. I think I was gonna go with the black too. But I think here's his I like yours better, I think. So, everyone, this is Igor. He's the greatest gift to CICD. You know, since the the cronjob. But you know, and puts the lion in localization. And he's just wonderful and knowledgeable and a wealth of resource. So yeah, coming to you from the West Coast, we have Igor, who's going to carry on with the presentation. And, again, Igor, I'll pop in, you know, towards the end, so use me as your time queue. And if you need me to fill in the rest of any jokes, just let me know. I'll do that

Igor Afanasayev 01:30
for it. Okay, thank you. Thank you so much, Brian. Okay, let me share my screen. All right, I hope everybody can see that. So of course, continuous localization is my cup of tea. And I like to talk about continuous localization and technology at every corner at every webinar. And but today, I'm not going to talk about technology specifically. But what comes next, after you have this continuous localization in place, how it can improve the quality of your communication of communication between the language team and other teams in your org. Let's start about like talking a little bit about the evolution of continuous localization and localization in general. So first, baseline is manual localization that we all know and love. And we did this in the past decades, I would say, it is still being used in software localization as well. The thing with with manual localization is it's slow, it's inefficient. And it's okay to use manual localization, if you have your release cycles probably every once in a while, every several months. But once you are venturing into multiple times a month really cycles, when your localization becomes a factor that slows you down. So this is where automated localization comes in place. In automated localization, I'm talking here about like partial automation, when you are able to do some, some of the tasks like sending files over for translation automatically or by a press of a button. And this automated localization is something that many companies nowadays have that the same time it still has its limits. It's okay, if you have releases every couple of weeks, or probably even like once a week. But once you're going, you want to move faster, you still see that automated localization in the way it is currently implemented in major, like, most of the time, it is still becoming a limiting factor. The thing is that automated localization is usually done by like sending the new strings for translation. And if you try to send your strings for translation, multiple times a day, you see that you are, you end up having a lots of small jobs with just a few strings per job. And this becomes manageable. So continuous localization differs from automated localization in in the way it works, so that it's fully detached from a release cycle. When you are implementing continuous localization. properly, it means that you are able to send your your new content for translation pretty much immediately. You can do this multiple times an hour, you can do this every every minute, every five minutes. So the question now is, why are we chasing this speed? Isn't that enough to send all the new content for translation? Like once a day, that should be that should be enough, right? The thing is that we want to achieve two things here. First of all, we don't want localization to be our limiting factor. We don't want localization to be a thing that slows down On our software development, our content development. And at the same time, we do want to improve the localization quality, we want to ensure that the multilingual experience is great across the board. When we're talking about those two aspects, it's usually either or, if we don't want localization to slow us down, this means that we want localization to happen faster, we don't give it enough time. And with that, it's really hard to talk about quality. If we want to improve the localization quality, this means that we are consciously increasing the amount of time that is allocated to localization. But this usually slows us down. The thing about continuous localization is that it allows you to actually achieve both of those things at the same time. So how can we shorten this release cycle? There are different ways to approach that, first and foremost, I would suggest moving away from the waterfall methodology. And we will talk about this about this in a minute. We want to go to work and shorter and smaller iterations, when you have continuous localization in place, when you have everything automated, it is natural, to get your content as soon as possible, and to be able to translate it as soon as possible. And even, like iterating, upon upon the second item, you actually can implement the scenarios where you can pre localize content, where you can localize content in a different form, not in the final form, that it will be there in the product. And we will cover that in a minute as well. So let's see how localization function typically evolves in in an org. Here, again, I'm talking mostly about software localization. So you have some release cycle here. And typically, it consists of three phases, which is the design phase, once the design is done, and like all the UI screens, all the copies repaired, it is moved over to the implementation phase, where software developers are creating the actual code. And in using those design designs in this code, once they are done with this initial implementation phase, now we are doing the full functional key, this functional key, identify some issues. So we're back into development phase where we're fixing those bugs, we do another round of key, and then we're doing the release. At this point, localization is basically like a slap on thing, it is mostly an afterthought, we don't want to slow down the release, because of localization. We don't have any buy in from other teams, that localization is something that is necessary in this release cycle, so localization at this stage happens after the release. And in subsequent releases, the global audience gets the localized experience with those new features. As you can see, we cannot really talk about quality of localization here, because localization is fully detached from the rest of the release cycle from the rest of the process, it cannot like really influence all the decisions at the design and implementation implementation phase. So it doesn't slow us down, but we cannot talk about quality. Now, as the company as the understanding of localization evolves in the company, at some point, we decide that localization should be actually part of the release, we want to wait for localization, so that our release happens in multiple languages in parallel. And with that localization becomes this final step in the release process. But we all know how things are working. When it comes to development. We're planning for certain time for implementation and plan and give some time for QA. But in fact, we're slipping dates here, implementation thing takes longer, we are shifting the QA phase a little bit to the right. And then localization takes what is rest before the release. Again, nobody wants to delay the release because of localization. But everybody's waiting for localization now. So localization becomes a stressful process. And we always are in a rush in translating all the new content. But at the same time, we'll see the same picture where localization is pretty much detached from the rest of the process, and it cannot influence any design or implementation phase. So again, as our understanding of localization and importance of localization evolves. At some point, the company decides that localization should be like a proper citizen in this landscape, right? And we want localization to happen even before the QA so we can do multilingual QA. So here we have this waterfall approach. Watch where we have, again, the design phase, we do the implementation. But once the code is ready, we now start the localization. And only after localization, we do the QA process in multiple languages, this is much better because, again, we are ensuring the quality of localization here. Now, we're, again at the implementation phase where we fix some bugs, we can tweak some, some string, some translations, some localization in translation issues, we do another round of QA, if we're lucky enough, we can even have a little bit more rounds of like final, final final key in terms of localization, and then we are doing the release. So here, localization is recognized as a as a part of the process. But at the same time, it really slows down our release cycle. So how can we improve that with continuous localization? The thing is that here we can really paralyze localization and implementation. I'm talking about this part of our chart here, with continuous localization. And when I'm talking about continuous localization is basically a two way synchronization between your code repositories with your content sources with your CMS, and your translation management system. So if you you are able to get the content from those sources as quickly as possible, and deliver them to your translation management system. This means that you can start early as well. Now, what you can do is you can ask your developers, when they're getting those designs and your copy from from the designers and copywriters before they are implementing any any code that that implemented features they can do, what they can do is they can create resource files for old new strings and commit them early to their repository. With continuous localization plays. This means that almost immediately, we can pick up those changes, and we can send them for localization. Now, localization can take much more time. So it's no longer a last thing in the process where we rushed with all the translations. And most importantly, we both both us as localization managers, and all the linguists, all the teams that are working on actual translations, they can see the new content as it appears on developer site. This means that we can find all the internet correlation issues early. And we can channel them back to the to engineers. And this is really important, because it's really hard to make engineers fix things after they're done with the feature. They're kind of like mentally detached from it, they are already focused on something else. And then we go back and say, Hey, there's a problem with this string, we need to we need to redo this all over again. Now, since we're starting to localize things as early as possible, we can go back to engineers and provide our feedback. While they're still working with this feature, probably they didn't have a chance to write any code that uses specific strings. So it's really easy for them to make the suggested changes, and improve the quality of the product. So now, with continuous localization, once we are done with the initial pass when we are done with the initial translation of all the new strings, and we have them with, with the help of continuous localization integrated back into source code repositories, and we can have those internal builds where we have, we can preview the current state of the multilingual product, we can already start doing our part of the job, which is linguistic QA of the product even before the formal functional key starts. So once we have implementation ready, and once we already did multiple passes of linguistic QA here and we have everything ready for translate, already translated, we can continue doing the functional key, but at the same time, we have plenty of time to still tweak our translations and see how everything goes. And do this again, like in parallel without waiting for, for engineers. And then we can have another round of like fixing fixing bugs that are uncovered in functional QA, again, tweaking some localization in parallel with development, doing linguistic QA and doing formal key and doing the release. Now we can have the release at the same point in time as we did before we even thought about localization. But localization now is an integral part of the development process and language teams have better visibility and they can influence the implementation process. So, but is this like the end goal can we do better? Actually, we can. The thing is that if we look at this, at this bar here, we still see this kind of like small waterfall approach, where design is still done as a separate step and only then it is being kind like flowing into the implementation and localization phases. This means that we cannot influence design here, but we want to because otherwise, we will see some, like aftermath of this approach where we still have in other release cycles, we will have to tweak the designs to better see you the, the localization. So we what we can do is we can start localization, even before the development starts, we can start a localization together with design, what I mean here is that we can integrate with the design tools that are used in the company, and try to pull strings from our design assets. This, again, allows us not only to pre translate strings that are already there, but we can also do like design key together with localization key. And again, multiple eyes will be looking at those new strings. And we can provide our feedback about copy about typos about some language specific issues that were not taken into consideration. And we can channel them back to designers. Now, at this point where designs are ready, not only we already have something pre translated, but we already are getting a much more like much cooler quality design, it will have less internationalization issues with implementation. And again, we have lots and lots of time for localization. So this is the ideal scenario, which continuous localization unlocks for us. How can we improve the localization quality in this in this process? First of all, we are providing more context. And again, when I'm talking about like proper, continuous localization setup, we're not talking about sending smaller chunks and smaller translation jobs often for translation, we're talking about a fully synchronizing what you have in your content source with your translation management system. At any point in time, you want to have full context, all content that you have there in resource files in your CMS, you want to have it exposed for translation on your TMS side. This means it doesn't matter. If you're sending new strings every minute or so those strings will be shown in the context of full documents. And when your linguists are working on those new new bits of text, they understand when where this text comes comes from, where what is the text above and below those new strings. As they as I mentioned a couple of times already now, we give much more time for translation, much more time for translation just means less stress, you can balance the load of your linguist better. And this alone can significantly improve the localization quality. In traditional approaches when you don't have much time. Linguists simply don't have time, we went to ask us questions, and you don't have time to channel those questions back to engineers and to fix something because you already have like very tight deadlines. But here you have plenty of time to properly communicate all the issues all the questions back to the content creators. And finally, and something that I already mentioned is that you can discover all the internationalization issues early. You can plug in pseudo localization in your process. And you can discover all those issues with layouts with string concatenation, although small bugs here and there as soon as you see all the new content exposed for translation. Now how can you improve the how you work with content creators. And now again, I'm not talking about engineers specifically, but about copywriters, about your marketing teams, about support teams. Now that you have a fully integrated, fully automated experience in terms of sending content, from from content sources to your translation, memory system, and integrating it back, you no longer want to wait till the entirety of the new content is ready. You can proactively reach out to the content creators and work with them and ask them to split their work into smaller chunks. For example, if you have a marketing campaign, and it consists of like a dozen of different emails, you don't have to wait for all of this emails to be ready before you start translating. You want to split this into phases? You want to translate a portion of those emails, and at the same time, the content creators will be working on the on the rest of the bunch. You can also translate intermediate Contin forms. This is what I mentioned what I called, like pre localization. Even before, for example, engineers yet the final resource files, again, like talking about the same marketing materials marketing campaigns, you have some copy somewhere where you're comfortable working with it, for example, is Google Drive or Google Docs documents. And engineers have to take this copy, and then create certain assets like JSON files or whatever they have in order to start this like automatic campaign. But before you have those JSON files, you can actually start localizing your content right from within the from within Google Docs. And you will use your TM on your translation Management site. So that once you have the final format, somewhere else in the version control system, you will already have all the oldest content pre translated. So the next phase will be much faster, just because it will be automatically substituted by using your translation memories. And now, if you have this like full, two way synchronization, you have everything on autopilot. It enables you to do some interesting self service scenarios to just make sure that you don't spend too much time on managing those small things. What I'm saying again, like if, if you're using Google Docs, for example, it is possible for you to create a synchronization and continuous localization of your Google Docs documents, and allow anyone in your company, your legal team, your support team, your marketing team to drop in Docs there. And they will automatically pick for translation, beautiful translation, and they will see localized documents appearing in the same Google Drive folder, for example. So this allows you to just show how things work. And let people use your continuous localization infrastructure without being distracted on those small management tasks. Now that you have most of the things automated, your new role as a localization manager becomes much more interesting. You're no longer doing those tedious manual tasks. And you can spend your time on things that are much more valuable. And again, they improve the quality of your, of your localization and of your product. You get more time to provide proper support to your linguists, you provide additional context to them, you answer their questions, you collect their feedback and channel that to the content creators and to engineers, you have more time not only to report issues to developers, but actually sit with them and discuss how they can improve things. In order to support localization. Same with designers, you have more time to talk with to designers, and improve the quality of, of your product at the design phase. And again, you have more time to actually sit and plan the localization process with other content suppliers. And as I mentioned before, you can split things into smaller pieces, making sure that you can smooth and load on on your linguists. So I hope you enjoy this presentation. And it will give you a better understanding where you are currently at in terms of localization, maturity, and the processes and how to improve them further. Thank you.

Bryan Montpetit 23:43
Thank you so much for that was fantastic. I'm sure you know, there's a few people that have had questions, and I have a few questions on my own. Hopefully, we can go through those.

Igor Afanasayev 23:53
I'll stop sharing.

Bryan Montpetit 23:55
can indeed. And basically, I'm not sure if you're going to be able to answer this. but I'll ask anyway, with respect to the continuous localization, how do we actually ensure the the pricing for for translators? So obviously, if we're using a freelance model, and its continuous localization, there's content continuously being generated and being dispatched? In one of the earlier sessions today, we talked about, for example, how the minimum fee doesn't really apply in these in this context. Do you have any insight on how companies pay out to translators in that situation?

Igor Afanasayev 24:31
So my personal experience, and this is what we did at my previous company, where we implemented this continuous localization process. We had translation and review rates for each of the linguists, and these rates were obviously different. But then we basically use those to calculate the actual amount of work being done in a specific period payment cycle. We pay them once a month, and we collect it like every time they hit a button to turn Sleep or to review a string, we calculate that as a paid task. And then we accumulate that and, and do the payouts at the end of the cycle. So this is this is really, really simple. And when it comes to actually like for the linguist to actually work, who actually works within the TMS when they do the review, and when they do the translation, we will calculate the similarity between, like TM, that they see the similar translations that they see whether they use the machine translation the future, if they press the button to like pre translate things through the machine translation and then edit that. And we use that base rate that we had and then calculated, like percentage, like a usual thing that we usually do to calculate like different different similarity between, like to matching and in the actual source. And then we use those as like coefficients to to calculate the final payments for for each of the submitted segments.

Bryan Montpetit 26:01
Alright. Wow, that's really good information. I think for all the all the viewers, thank you for that. The other question that that I have, is when you're actually looking at a continuous localization scenario, a lot of the times it's the for example, language buyer, or the end client that's putting it in, so the corporate entity, right? They're putting this into place. Now, on the LSP side, I mean, how do you actually talk to your customers about getting this, you know, put in place so that you can benefit from both continuous localization and get them tied into?

Igor Afanasayev 26:33
Well, I did not have a chance to work at an LSP side, but I definitely see the benefit of LSPs promoting this to their customers just because with this tighter integration, they have less friction, and they can again, like they can take, they can acquire this new content as early as possible, they have more time to deliver quality content. And like the overall experience, the customer is really happy when they have this continuous localization in place, everything feels like a like a magic black box that just like does its thing. And you don't have to worry about the quality just because you have much more time for that. So less stress on both sides. Continuous localization is like with the tools that that are there on the market, including some open source tools, it is possible to set up those continuous localization plays, processes much faster. So you don't have to go back to your to your client and say, okay, yeah, you can, you can do this continuous localization. It's a fun thing. But you need to allocate, I don't like several months of your engineering time to actually implement it, right? Instead, it is possible to implement those continuous localization practices by using like ready to use tools. Like literally within days, it's easy to do this from like, if you are like a technical savvy LSP, you have some engineering resources on your side, you can help your clients implement that. And again, like your clients will be happy, and you'll have a steady inflow of the new content, and without any friction.

Bryan Montpetit 28:11
Fantastic. Thank you so much for that. I think that provides great insight to not only the the corporate entities here that would want to actually explore the continuous localization, but also the LSP side as well. So thank you for that. I don't have any additional questions. And we're just about at time irrespective. So