35 items found for ""
- Pushing for change in big orgs with Gilad Almosnino
How much change can you really create in big organizations? What can we do to help integrate localization from design to development? How much of an impact can localization teams have? And what does it all have to do with standardization? Listen to the full interview with Gilad Almosnino to find out. Audio Text video Key takeaways Mentoring and consistent engagement with feature teams can significantly reduce bugs and improve the quality of localized products. Implementing systems like champion programs helps in integrating internationalization from design to development. Larger companies often set trends that smaller companies follow, making standards adoption critical. Standards like those from the Standards Institute of Israel can drive consistency and better UX in bidirectional language support. Modern advancements in technology and AI can now make gender-specific localizations more feasible and cost-effective. Overall, continuous improvement and adaptation to new technologies will be crucial for the future of localization. About Gilad Almosnino Gilad is a creative innovator in Localization and Internationalization space with a proven track record of driving local market requirements across product design at Microsoft, Diligent, and Tinder. He excels in providing user-centric international product leadership, leading multidisciplinary design and development programs, and producing targeted market research used for strategic, industry-changing decisions. As the head of the Standards Institute of Israel Hebrew Support Committee, he is leading first-of-a-kind industry standards for UI mirroring and developing more inclusive gender-related Localization standards that aim to improve user scenarios across the Middle East region. Gilad is currently developing independent AI-related Internationalization market research and GPT-powered solutions that will challenge AI technology to become more practical for products seeking to build locally relevant experiences for users across the world. Enjoyed the Localization Process Pod? In every episode, we'll be learning from one guest about the way they do localization for digital products. Subscribe here, on LinkedIn, or on the Localization Station website to get notified about the next ones. Transcript Michal: Hi everyone. Welcome to the localization process pod. This is a podcast where we focus on different localization processes and different companies. We talk to different localization program managers and product managers and project managers to kind of learn what everybody are doing and what is working and what is not. So we can all learn from each other and kind of find the best processes that work for our specific company and our specific team. Today I have with me for the first time in an actual live recording, Gilad Almosnino. Hi, how's it going? Gilad has worked for 19 years at Microsoft in the international space in different kind of various positions, as well as a product manager consultant at Diligent and Tinder. And a chairperson for the Standards Institute of Israel for standards for bidirectional languages. I hope I covered all of it. Gilad: Yep, you got it all. Michal: But it's quite a bit. Gilad: Yeah. Michal: So, thank you so much for being here. And, from what I remember, most of, a lot of the work that you've been doing in the past years has been around kind of internationalization. Gilad: Yes. Michal:So, do you want to tell us a little bit about that? Gilad: Wow, yeah. I was fortunate to actually get into the international space by accident. Michal: How did that happen? Gilad: So I was a student at college at Bellevue College, learning communications and multimedia and the team at Microsoft needed software testers for the international version of Windows. And so they needed native speakers. And I was fortunate enough to get in on a really fun job as an international tester. For, the localized Hebrew version of Windows. It was kind of a funny $15 an hour job. And I did enough of an impression that they, after a year, took me as a full time employee. And that's where I started my formal journey at Microsoft as a full time employee on the Windows international team, which was quite fun and taught me a lot about how the software actually worked. I later on became a Program Manager in the same team. So I transitioned into that role after we did some reorganizations of things. And later on, I actually hopped on and became product planner, which basically helps the product managers plan ahead and think about some of the features that they want to build into the operating system. So it's quite a fun role as well. So that's the Microsoft part. Somewhere along that timeline, I moved back to Israel and also left Microsoft. Which then I became a consultant for both Diligent and Tinder for the international space as well. Mostly focusing on bidirectional languages, Arabic, Hebrew, anything from right to left. Kind of the same thing I did at Microsoft. And then I wrapped that up I think a couple of years ago. Today I volunteer as the chairperson for the Standard Institute of Israel, the Hebrew Support Committee. So we basically are building standards for a few things. One of them is a brand new keyboard that's supposed to come out in a few weeks, hopefully, when Microsoft releases their next version of Windows. It's a new keyboard layout. It's not going to be the default keyboard layout, so nobody has to worry that we're changing keys around, but it's a keyboard that's more compatible to the English layout. So it makes typing a little bit more efficient. There's a great guy named Yuval Rabinovich that worked on that. And we're also working on a very exciting Hebrew UI layout standard for bidirectional languages. So, how to design a right-to-left UI in the most natural way. So, quite a few things, yeah. Michal: So, as a chairperson in the Israeli Institute of Standards. Gilad: Yeah. Michal: So essentially, you're the person looking out for us as Hebrew speakers or bidirectional speakers, Arabic speakers in Israel, trying to kind of find better ways for us to access digital services. Gilad: Right. We're trying to basically standardize the way software providers lay out the UI and support these languages more naturally. And we also have on the committee one of the members is actually doing a PhD to see how, from a cognitive perspective, how that impacts the user. So it's quite interesting. It's the first of a kind, I think standard that's actually backed up by usability studies. I don't think there's another one in the world that does that. Michal: Okay. That's amazing. And do you find that companies. Are kind of happy to collaborate with you and make those changes, make those adjustments where... Gilad: We haven't reached that point yet. I think once we have the standard fully baked and approved and we could reach out to some of the companies. We do have members from those from the big tech companies working with us. So we do get input on the standard. It's, it's kind of an interesting game, you know for bidirectional languages. I think no company is fully invested in making those research and development investments. So basically, even during my time at Microsoft, it was very hard to convince teams to And management to invest in bidirectional languages because they don't see the ROI. Michal: Yeah. Gilad: And it's, it's a huge overhead. And from my end, I always wanted to be super professional and try to get usability studies to justify some of the design decisions that I made along the line. And so what I do see for companies as an opportunity is to have clear guidelines or a standard which they don't have today. So basically today what you see across the industry, especially around bidirectional languages and UI layout is that some the smaller companies will many times look at what the bigger companies are doing and then base their design decisions on that. Their assumption is that somebody in that company is actually... orchestrating the entire UI design for those particular languages. Michal: That's not a correct assumption. Gilad: And that's, and that's an incorrect assumption because no company, not that I know of, not many have somebody, for example, that looks at the entire end to end story for those languages. And so you may see inconsistency, and you may pick up the wrong element and lay it out incorrectly because you assume that Facebook or Microsoft or Google knew what they were doing. When the reality is the y probably Googled it. Michal: Yeah, okay. They asked Gemini or ChatGPT. Yeah, there you go. How do I a right-to-left layout. Gilad: Yeah, something like that. So I think we're trying to at least eliminate the idea of assuming that those companies know what they're doing. It also is going to help those companies to kind of figure out, hey, this is what the requirements are for the Israeli market. The idea is to, to create a Israeli standard, but I also am a liaison member at the Unicode consortium, which is the intersection where all the standards kind of get baked into Microsoft, Facebook, Apple, Google, they all sit there and mostly deal with text handling. And the idea is to maybe use the Unicode standard to kind of make sure that we're reaching out to the big tech companies and also regionally. We're not looking to just make a standard for Israel. We're looking to reach out to other players in the region that require the same requirements and kind of work with them to ensure that everything is kind of integrated together. Michal: That actually is really interesting. And it brings me to my next question. How much collaboration? Because. For Israel, bidirectional language is really critical, but also we're a very small market. Gilad: Right. Michal: And Hebrew speakers are a very small subsection of like global users of digital companies. But Arabic speakers is a huge market. Gilad: Yeah. Michal: And they have a very big need for bidirectional language. And I think in many ways, Hebrew speakers kind of get the benefit of that big market. We... if bidirectional language is available, if bidirectional layouts are available, so... we kind of benefit off of that, but no one is doing it for us. Gilad: Right. Michal: So how much collaboration can you really manage? Gilad: So currently what we're working on is a local standard. We are hoping to make it good enough so that the adjustments that are needed when we reach out to the regional players is gonna be minimal. The differences between Arabic and Hebrew is very minimal in terms of text handling and certain positioning of certain characters. Like the percent symbol or the question mark. You know, there's minor differences or digit handling. And so for us, we know that at least the big load is the UI handling, the directionality of the UI. Most of that is gonna have consensus. And the rest of it is going to have to be market specific adjustments. The biggest challenge in front of anybody that we have to present this to is that they tend to group everything together. And so, to a certain degree, that's right. But to, to other degrees, it's not. So, they basically, what I've seen along the lines is, like, the Israeli market leverages the Arabic user base around the region to make sure that the investments are made. And that's very correct. That's what I did at Microsoft for years. Yeah. You know, you're not going to be representing a smaller market and forgetting about the, the larger user set. More so, the Arabic market is less inclined to use English. Michal: Okay. Gilad: So it's a more pure Arabic market. We see that happening quite a bit which is great. Michal: Yeah. So bigger ROI as well. Gilad: Right, right. So when you represent the region, you have much more leverage to kind of ask for changes or improvements or investments. So that's quite nice. So the idea is to, when you approach some of these larger bodies and corporations, they tend to group things together and when you say, hey, you know, Hebrew needs the question mark in a certain way and Arabic needs the question mark in a different way, they tend to tell you, why don't you agree on it? Why don't you, why don't you go and figure out what... Michal: Sit together and agree, why not? Gilad: Figure out what direction you want the question mark. It's like their, their failure to see that different markets have different requirements, right? And I'm sure other markets have, like, basically some European markets may speak ... there's differences between them. Nobody is asking the two to sit down and kind of figure out what the right solution is, because they just kind of respect each market for what it is. And so when it comes to the smaller pieces where we have to do market specific adjustments, the idea is to actually present that in a way that says, you know, 95 percent of the things are the same. And then there's 5 percent differences between markets. And that's just a market specific adjustment. Michal: Yeah. Okay. Gilad: And that's something to bake into the engineering. Which is what we're gonna be asking for. Michal: Do you find that it gets easier with how technology is advancing and development technology is advancing? Do you find that maybe there are kits or scripts that make it easier for companies to utilize right to left. Gilad: So I've actually, you know, in recent months, I've been thinking about how things turned out at Microsoft and was it sustainable? Basically the weakest link in this whole equation is the person. Michal: The user or the developer? Gilad: No, no, the program manager that has to make design decisions or planning or whatever for internationalization. There's two reasons for that. The internationalization foundations that were put at Microsoft were put around Windows 2000, and they were very good. They were very robust. People accepted them for what they are with all their limitations, which for many years made sense and for many program managers it's easy to be in the comfort zone. So they're not looking at the foundations and saying... we need certain adjustments. I've never had that tendency, which made me a bit of a nuisance to certain people because, you know, you can look at certain limitations and say, you know, we need changes. So that we can progress forward, so we can enable more localization scenarios. So when the person leaves, the knowledge leaves. And so the idea is these days when it comes to engineering systems is to be smart enough to bake the requirements and the robustness in the engineering systems. So that when you build software, you're not going to have all these bugs. Michal: Yeah, kind of like a design system as well. Gilad: Yeah, a couple weeks ago, we sat with a company that's trying to bake localization into the design space, which is quite exciting. That's what we did at Microsoft after a few years when we figured out that that was the better way to go. The idea is to strive to get upstream into the design phase, but also strive to have the engineering systems kind of have the requirements baked in to a certain degree so that developers, for example, that want to build a media control, just get a media control that's mirrored correctly, you know, Yeah. Michal: They don't have to think about it. Gilad: They don't have to think about it and they can't screw it up. Michal: Yeah. Gilad: We're noticing with the initial usability studies that when you don't implement UI mirroring correctly or consistently, we're seeing impact to users' ability to be productive. Michal: Yeah, I have to say, I do find that there is kind of a hunger in the industry from the people who are actually creating the interfaces. So maybe not companies like top level directors, but designers, writers, localization experts, developers for guidelines that are very clear and that they can just take and use as is, right? I think a lot of people, they work in this vacuum and they do what they can, but nobody tells them exactly how it needs to be done. Gilad: Right. Companies have to put themselves in a position where they grow subject matter experts. I think in localization teams in the international space, you see... just my, you know, unofficial view of things across the many years. What I saw is that people tend to stay in that space longer. It's, it's a full career. Michal: It's a comfort zone as well. Gilad: It's not a comfort zone as much. Well, for some people it is. Sure. There's some people that, for others, it's just exciting. You know, I'm able to bring my skill set to a new feature, a new release, a new whatever. And they grow. Like.... I didn't come in into Microsoft as a subject matter expert. I came as a 19 year old college student that needed a part time job. It took me about 10 years to become a subject matter expert. It's not something that you, you, you develop over a year. Michal: And people don't stay for 10 years at a company these days. Gilad: It depends, right? Like in the international space of Microsoft, you saw people that are 20 and 25 years. Michal: Yeah. Gilad: And in certain years, it had, you know, accelerated growth and different technologies and, and the localization team was actually contributing to the core product product. And then working with international standard bodies to make sure that we're with better interoperability. What we see today is like, You know, with iOS and Android and PCs and Macs all working together and... they do it rather seamlessly on the international aspect of it. Nobody should take that for granted. That's a lot of work. That's a lot of people that I think have less visibility have done over the years. By the way. They're the coolest people have conversations with. Michal: Well, I think that's a lot. That's usually the case, though, right? Gilad: I had one experience at Microsoft with with person that developed the Unicode algorithm. They took that and they moved it to Unicode, so that becomes a standard. So one of the things that does is select text. Everybody knows that when you try and select bidirectional text, it's a bit of a problem. Michal: Yeah. Gilad: And I think during my first few months at Microsoft, I approached that person and said, this isn't working correctly. And again, older Microsoft people were less politically correct. And so he did not appreciate, he did not appreciate the way I initiated the conversation, "this isn't working correctly" because he worked on it very hard. I got yelled at again. It brought me to a point where I was able to think about why I approached that person in a certain way and what impact that had on the international space. Does this area need change today? It does. That's probably the next standard we're going to be working on. In fact, when Microsoft just heard that I was going to be working on a standard like that from the Israeli Standard Institute side point, they immediately contacted me because they knew that would cause them to have to make... Michal: Did they contact you in fear? Gilad: No! Michal: No, no, they were happy. Gilad: Sure, yeah. Michal: They were excited. Gilad: No. I think what they wanted to put together is actually Microsoft and Google and Apple together. So we're able to put a user experience that is good for everybody. That all three of them would implement because if you look at today's platforms and software on top of that, you have Microsoft running on top of Google and Google running on top of Apple and all kinds of stuff. The international space is one of those places where things are not competitive anymore, like these teams have to strive to work together. Michal: Yeah, well, I mean, because at the end your goal is to have everything the same, you know, as, correct, I guess, as possible. Gilad: The issue is that everybody's maintaining everything now. So you have to demand that they make a change because as long as Microsoft and Google and Apple are concerned... those are three big platform companies from the operating system perspective. They'd leave tech selection as is. Right? But that being said, Microsoft changes its design systems all the time. So every five, six years, they tend to kind of keep going. And so you have to rebuild this. Michal: Yeah. Gilad: Things don't, don't kind of come together automatically. And so, it's quite interesting. I'll give you a very good example of how, uh, we can impact localization as internationalization PMs. So today I think there's like 15 or 16 different languages that require masculine and feminine form. And so the solution that the localization industry provided is to go gender neutral. Make gender neutral localization, which makes a lot of sense. It's very inclusive and and strives to get to the broader set of users in a direct way. But nobody asks why did we get to the point where we only have one version of the language, right? Like if I want to translate a certain application to masculine form and having the same application in feminine form. I'm not able to do that today. Michal: Yeah, so explain a little bit about that, because I remember you told me about this a few months ago, and I did not understand. Gilad: Okay, great. Michal: So, how do you mean we can't? Gilad: So, we can go way back. There's something called the resource loading technology. It's something that Microsoft came up with in Windows 2000. First of all, it separates the strings out of the code. And then also, it basically says, hey, for every language, here's where all the resources fall, right? And then you can basically swap around. So if you want to use French one day, you can use French, then you can swap it to Hebrew, basically changing the UI language. That's something that in the past you couldn't do. Because the resources were baked into the code and it was very hard to localize and they had to compile it and send it on a CD or whatever. Michal: Yes, and now it's very common to keep the language kind of separate from the code. Gilad: Right, and all of that is basically based on what they called at the time MUI technology, multilingual UI . That's something that Microsoft came up with. A few years went down the line and Microsoft passed that on to Unicode and basically said, whether it's Android or Windows or anything, we need to have this language system. It was a great invention, it pushed things forward. One of the mistakes they did is they didn't have variations per language. Like for Israel, you have Hebrew Israel, that's it. You also have Arabic, Saudi Arabia, you get the point. But if you have one version of Hebrew, you're not going to be able to adjust it per user setting. Michal: Yeah. Gilad: And so what we do have today is a gender neutral translation, which is a compromise. We should strive to give the users what they want. Like, if I want to be referred to in masculine form, I should just be able to pick Hebrew masculine form. I don't know, give it a better name, or you could be selecting Hebrew feminine form. Because we didn't think about the internationalization aspect of it to the full detail of things, we're not able to provide the localization industry with more variations of languages. Michal: But do you think that companies will like more variations, because it does add a cost if you have to create two versions or three versions of each language, it does mean you have to invest more money. Gilad: I actually proposed this to, at Microsoft when I was working there at a very early stage and I was thrown out of the room. I was just thrown... Michal: Like that meme, exactly. Gilad: Yeah. Yeah Michal: Through the window. Yeah. Gilad: Yeah. It was a very good conversation, but it was thrown out of the room. And actually the person that I sat with was the director of the team at the time. And he invest, invented MUI. He's quite a fun person to talk to. Very knowledgeable. Always an interesting conversation. And he, at the time, basically said, look, me and my wife, you know, we didn't have cell phones back then. Me and my wife, we use the same profile on the computer. How are you going to solve that? Right? Michal: But that's not the case today. Gilad: But that's not the case today. Nor was the case at the time, also, Microsoft at the time was investing about a million dollars per language for localization. And you can multiply that by 120 languages. Michal: Yeah. Gilad: It's quite a bit, even for Microsoft. At the end of the day, no division manager wants to see a 120 million bill for localization. And so at the time, what they did is they actually came up with another set of resource management, and they basically say, we're gonna extract and localize only the first level UI and localize that, and that's 50, 000. Michal: Mm hmm. Gilad: And so It was a cost issue at the time. And I said, Hey, why don't we take the first level UI and use that technology to translate into masculine feminine form pick which one, you know, you want to translate for a million dollars and pick which one you want translated for 50, 000, I don't care. It was a cost issue and a technology issue. They did not want to invest in the resource loading technology. They were too scared to touch it because it was working. And also from the cost perspective, they didn't want to... They didn't see the inclusive wave coming in. But moving forward 10, 15 years, we have a very different scenario. We have cell phones, you have smartphones that basically are all yours. You don't share them with somebody. Localization cost has dropped. Machine translation is increasingly more accurate. And now with the AI revolution I think you're able to take a set of strings and turn them into feminine or masculine form rather easily. And so we're at a very different stage right now where maybe now this idea is more mature to the point where it's cost effective and easy to implement. Michal: Simpler and cheaper. Gilad: Yeah. Michal: And so maybe it's worthwhile. It's a good point. Gilad: Well, what's stopping us today is the same thing that stopped us 20 years ago, which is the resource loading technology. And so today Unicode is responsible for that. And that's one of the items that I tend to or want to bring up with them. Because there's 15 or 16 different markets that require translation to, in the case of gender, to different genders. The Japanese team, by the way, when I proposed this idea, had a very different idea around it. They basically said, you know Japanese children from age, I think, 7 to 12 aren't able to read Japanese as adults. They basically need a simplified version of the language. Why don't we use this to create, you know, Japanese kids variations so that they're able to use computers more easily. Michal: Yeah, it's true. And you can take that in different kind of, like, formality levels. Gilad: Yeah. Michal: On different variants of languages, I would guess. Gilad: Right. The gender is what I started with at the time, because that's what I thought about. It's probably the largest piece of cake, right? Michal: Mm hmm. Gilad: But if you look at the ability then you're able to, to do all kinds of variations. Michal: Yeah. Even age variations, maybe, if you want to explain something in a more detailed way to some people, but then have a simpler explanation. Gilad: And so that's a perfect example of internationalization. At it's very core fundamental version it can impact localization scenarios. Michal: Yeah, amazing. So I have another question. But I'm taking you back a little bit because you said... You mentioned that to get Microsoft, to implement some kind of fixes, you worked on usability studies. Gilad: Well, at the Institute of Israel that's what we're doing. Microsoft didn't want to invest in this. Michal: Yeah, so that's exactly my question. How do you convince your employer or a company they work for to actually invest in usability studies, to actually prove that localization or better localization is worthwhile? Gilad: I don't know that you need to invest in usability studies for everything. I think once you have some certain established standards and industry industry knowledge that is fairly stable, then you're able to make design decisions. So at Microsoft, basically what they used to do is you get the English UI and then you make design decisions for Hebrew and Arabic based on that. You say this has to be mirrored in a certain way. You give the requirements and... I think the biggest advantage that I had is that I was very senior in that space. And had a lot of years behind me, that people that I worked with along the years counted that my decisions were correct. And I used to tell them, I take full responsibility for any design decisions that I make and ask you to make. Because I had to influence without authority across my entire career at Microsoft. I never had a team with the exception of the test team of direct reports. I was a subject matter expert. I was able to scale at a certain point because we put in a system. I think the windows organization was a few thousand people in various positions, and we were a team of the international team localization and internationalization and quality assurance was about a hundred people. So you had to scale. And you have to pick and choose who you engage with. But the idea is once you become a subject matter expert and, and make yourself available , and prove that you're able to basically make the investments more time efficient, then teams tend to come to you for help. They tend to say, Hey, I have a question about X rather than going and figuring out on myself by myself, I'll just reach out to the right expert. In the international team, we, we actually put in a system that was very good for that. Michal: What kind of system was that? Gilad: So we basically suffered from total chaos in localization for many years. Michal: Mm hmm. As localization experts do. Gilad: Yeah, right. More so on larger scales and bigger corporations. I think because you're working with more players. Resources tend to be problematic. More so if you're building a platform, platforms like operating systems tend to be interesting, every once in a while there's a reinventing of the wheel to a certain degree. So that never makes anybody happy because you have to bake in again, everything you just did on previous versions. Michal: Yeah, and I would imagine that this position is a free agent kind of where you're connected to all the departments, but not connected to any of them... Gilad: Right. Michal: Does also contribute to that chaos. Gilad: So that kind of brings to the, you know, the career story at Microsoft. When I was on the quality assurance team I filed a lot of bugs Michal: They did not like that. Gilad: No. Michal: No. Gilad: No. Some were localization bugs where the reading order is bad and you have to insert Unicode control characters, very straightforward issues. Michal: This full stop is not in the right spot. Gilad: Yeah, I mean, you just say, you know, the reading order is incorrect... and so the localization issues are less of a problem because you're dealing within your own team, right? That's on the localization layer. The more complex bugs are the code issues. Something that isn't mirrored correctly. Something that doesn't function correctly when mirrored. Design change requirements for internationalization. Hard coded dates, hard coded fonts for localizability. Hard coded strings for localizability, all kinds of things like that. Not thinking about international users at all and how they might use this specific features. Those are not just code bugs. Those are what they call or classify as design change requests. And I had many of those. Michal: Okay. Gilad: And most of them were taken. None of them were taken easily. So it was always an ongoing conversation. Some teams were more receptive, some teams were less, depending on the design change. But it was basically selling. Selling. And I think it tends to be an easier job when you're not afraid to step out of your square. Michal: How do you mean? Gilad: People tend to go into their comfort zone and say we have internationalization support. Why don't we just build on top of that? And then somebody like me comes and says, well, I'd like to have Hebrew in two forms. Michal: Yeah, it needs to be a little bit better, right? Gilad: Right, it needs to be different. And so for me, it was easier to go to those teams and say, you know, we need certain design change requests or certain design changes to make this happen. And work correctly across all markets. And you get all kinds of responses. Some of them were just PMs shaking their head and going, I didn't think about this. Others were, oh, we just shipped to like 16 markets, and then you have to explain to them there's no such thing in Windows. You can't make language decisions on a feature basis. Certain teams might assume that they're shipping to a set of markets and then realize that they're shipping to 120 languages. And that they're being localized. And so that's really interesting because it's a very big eye opener. Michal: Yeah, how does that happen without that team actually knowing that it's going to... Gilad: They hand off localization resources. That's a battle on its own. The localization PMs have to sit there and beg them to send the resources on time. More so on a waterfall-type release. More so with the Technology that was a little bit older where you're sending it to the vendor across the seas and you're getting it back every two weeks or every week and you have to integrate it into the build. And then 20 things have changed by then. And the feature team changed the string and it's just one of those things where you're like, we're being... there's shots from all directions, there's shots from all directions. What do you do with this thing? It's just a back and forth exchange. Again, if you invest in the engineering system. I think you can avoid a lot of these things, and it just goes to show that at the end of the day, even today, the AI revolution is going to be very helpful, but it's not going to replace the human nature of not making things very organized sometimes. Michal: Yeah, and not wanting to change, make changes. Gilad: Right, right, right. Michal: So let's say that you have your system, you have your standards. Mm hmm. You still have to inform people. Gilad: Right, so.... Michal: And kind of get them to actually use them. Gilad: So the journey at Microsoft was really funny. Because... One of the releases, we had a fire drill. The last three months of the release was just fire drill, fire drill, people working 16, 18 hour days just to fix bugs, just to prioritize things, just to get things out of the way. It was a very stressful release. The senior leadership team really didn't enjoy that. And then, you know, after all that was done we basically sat down and said, how do we avoid this moving forward? Because what happened here is that we, for persistently for two years, we said, you're delaying things too much. We're going to have requirements. We're going to have bug fixes. The international build is broken. It's just not working. The quality assurance team isn't able to even install it. How do you make sure these things don't pile up at the end again in the next release? And so what we developed at the time is a system that basically... we called it the international walkthroughs. And it basically goes hand in hand with the feature teams to design, develop, and localize features with internationalization baked in across the entire life cycle from the design phase. And we also had to divide the team so that... we couldn't handle all the different teams at Microsoft or at Windows. And so what we did is a champion kind of program where every feature team had to give us. a person that was responsible for internationalization in that team. They would pair up with somebody like me, and I would mentor them. But not only mentor them, I'd do the design walkthroughs with them, with the features and the specs and everything. I'd go shoulder and shoulder with them across the entire life cycle. If they had questions, if they were triaging the international bugs and they had interesting questions around those, we would help them triage them and make sure that their priorities are set correctly. And I actually have really interesting numbers around that. The bug life cycle dropped in almost 15-20 percent, the bugs disappeared a lot quicker. The number of bugs was a lot smaller. 10-15 percent bug count drop. And so we actually saw a persistent drop in every m that we could think about by engaging very early, having very direct conversations with the feature teams around what we'd like to happen, baking it into the specifications and working with them across the entire life cycle, across the design, the development of the different milestones to make sure that we're making the right decisions along the line. It made their life easier. It gave them more visibility into internationalization, and it also grew the internationalization aspect of things across feature teams because the tenant champions that were responsible were not direct reports to the international team. They're inside the organization. So now you have, you know, 100 people inside the organization that are able to speak about internationalization more naturally. Michal: So did you find that it really changed their approach, these champions? Gilad: Yeah. The champions were great. Michal: Yeah? Gilad: The champions just dove head first in this thing. Because you have somebody mentoring you. You have somebody that's shoulder to shoulder with you. You know, the, the classic scenario of localization teams, more so in larger localization teams, is that let's say we have a certain feature team and there's design requirements for bidirectional languages, for European languages, for Asian markets, all those. Each one of us used to approach that team individually and I used to call it the gun to the head. We need X, Y, Z. And so that poor team is coming back to us and saying, hey we have like three of you approaching us. What should we work on? And that's a very valid question. And so when we started the design walkthroughs and actually had meetings where we go through the spec and then have meetings where the UI designer used to show the UI flow and then we give them notes on... Here's what we have to put into consideration. All that kind of started to make the international voice more consistent. And I think that was our biggest challenges. How do you get the international voice to be consistent? How do you have the subject matter expert for Asian language and subject matter experts for Middle Eastern languages sit together and say, you know what, we need to make a priority decision here. What's more important, right? And so that's actually an internal conversation we need to have. When we see the larger picture and say, you know, maybe support for certain bugs need to get fixed for the Chinese market, much larger market, much bigger impact. Maybe we need to put that in priority instead of other things. Michal: So what kind of roles did these champions come from? Gilad: We had them come from all different aspects of the development. So we had developers, and we had testers, and we had PMs, all of them. Michal: But not designers, not writers. Gilad: The designers were really hard to crack. Michal: Why? Gilad: Because the design team at least at Windows, wanted to work in as much of a sterile environment as they could. They were building based on research. And everybody has a design idea. And so it kind of overwhelms them. Michal: Yeah. OK, I can see that. Gilad: And when you want to orchestrate a design change, like Windows 8. Windows 8 was a paradigm shift in design change for Microsoft. A less successful one. Michal: Yeah, I remember. I do remember. But it was a big change in terms of how it looked. Gilad: It was a huge change and the team was siloed basically by design from the higher ups to work on that. Michal: Do you think that was a good decision? Gilad: To silo the design team? I think just overall the robustness of the design was something that we always struggled with because they kind of siloed themselves in. And also wanted to surprise. Every release I used to kind of wait for the last two weeks. Because the design team wanted to surprise with something. In Windows 8, for example, they wanted to... you know when you have long strings and you want to to make them shorter, you usually put the three dots at the end, right? That's called text trimming. The design team decided that they want a fade out effect. Michal: Okay. Gilad: Rather than three dots, fade out effect, make the UI more readable. I don't know. That was the idea. And that's great. I, I can't argue with them on that. You know, they're the designers. The only issue is when you bring something like that at the last two weeks of the project without consulting your international counterpart is that you tend to have bidirectional text trimmed from the wrong end. Michal: Oh, no. Gilad: So the leading edge of the string is being trimmed... Michal: At the beginning. Oh wow. Okay. Gilad: Being screwed up there. Unreadable. And then you approach the design team and say, Hey, you know, unless you fix this bug, we're not gonna be able to ship this. That's where the very, very difficult conversations happen because they escalate very quickly at the end of the project. Michal: Yeah, that's really critical. Gilad: Right. Michal: It's unusable. Gilad: And unfortunately, even inside the international team, some of the entities often like to stay in the comfort zone. So they're not able to have these difficult conversations. And it goes up really fast, really quick. We're looking at minimum director level decisions to take this or leave it. And you struggle across multiple stakeholders. The localization team has their own triage. The feature team has their own triage. Above that, you have the, what they used to call the war room. And above that, you have, that's the feature team war room. And then you have the division-wide war room, um, which I thought was always quite entertaining. It's not a very politically correct place. It's very... you know, there's very strong leaders there that want answers and want solutions very quickly and are not there to hear anybody complain about why this went so bad. And so in that particular decision, I had to go to the Windows war room and, and say, Hey, you know, we've never had a scenario where we trim the text from the leading edge of the string and making the UI completely unreadable. And the design team thought that we could just fix this down the line, which I thought was quite interesting because they basically didn't even understand the impact of certain markets and they didn't want to. They were so fixated on English and the left to right languages that they said, Hey, but these smaller languages or whatever, they can suffer there. And so I never saw it that way. Michal: Well, it's completely unusable. I think if you, if you think about it, even in English, if you cut the beginning of a sentence. Gilad: You always say, you know, if we're not able to reach an agreement, we're going to have to have this escalated to the... I've never escalated things in hostility. I say, why don't we write an email together? We'll say, here's the two kind of viewpoints on this thing. And we need a decision on this. And have the directors make a decision on this. And so that's, that's always quite interesting because that brings a very different dynamic into the game. Michal: Yeah, I think it's more of a shift of perspective because if you say, okay, our interests are actually shared, you're not two competing teams where we have two competing kind of arguments and one of us gets to win and the other gets to lose. It's like we have a shared goal. Gilad: It's more... how do you not burn bridges? Michal: Yeah. Gilad: Right? Michal: Definitely. Gilad: Because you're going to be working with that same feature team in about two days. Michal: Yeah. It's not even not to burn bridges as much as if you empower, I think, localization teams to understand the impact that they can have. Gilad: Right. Michal: And then come from this from a point of confidence. Gilad: Right. Michal: So they don't come into this defensive. It does not become as much of an argument and as much of a fight as it could have been. Gilad: Yeah, exactly. I think it takes a certain set of elements to put that in place. You have to have a leadership team in the international space and the localization space that enables their their direct reports to go out of their comfort zone and engage teams upstream. Put some sort of engagement framework across that. Make sure that you translate some of these things into engineering systems down the road, so you don't have to reinvent the wheel every time and not have developers make mistakes and the quality assurance team busy with bugs that repeat themselves. Michal: Yeah. Gilad: They have to convey that to senior leadership and they have to engage with them in the same manner on a almost weekly basis. Michal: Yeah. Gilad: So that everybody knows that everything is going correctly and that we're able to kind of clear the road for the release. And also recognition is a huge thing. That's the other part, by the way, of that program with tenant champions, is giving them recognition. You know, managers always struggle to find new opportunities for their direct reports. Internationalization is great. Localization is great. You know, if you're able to convince the leadership team to bring these champions in and provide them with value so that at the end of the day in their, I don't know, annual one-on-ones or evaluations they're able to say, Hey, you know, I grew as a internationalization expert, right? I helped the team steer around the international space. That's a growth opportunity for individual contributors within the feature teams that normally don't deal with these things. Michal: Yeah. It's like an added skill that not a lot of people have. And it's very easy to add on. Gilad: Yeah, I think that's a thing for us in the space to acknowledge that we want to enable more people to care about this and be knowledgeable about it. Michal: Yeah. And definitely find that when people start learning about localization, specifically people who are not from the space at all. Gilad: Yeah. Michal: First of all, they get really excited. It doesn't matter... Developers, designers, writers, anyone who's not in localization, they learn about localization, they get really psyched about it. Because they like, Immediately understand what impact they could have on lots of people around the world that they've never thought about. Gilad: Right. Michal: And never considered. And then they get really excited. They really want to be part of this and they really want to be able to help make it better. Gilad: Mm-Hmm. Michal: And it's something that I've been seeing. Once they hear about and they really understand the impact of localization, it gets them really excited. Gilad: Yeah. It's it's clearly that. Enable people to make the right choices and be part as an active contributor. That's been the, I think the strongest thing that we were able to do with these design walkthroughs. Across the entire windows division. By the way, one of the teams that got really inspired by this was the accessibility team. They said, wow, we're struggling just like you. And we said, why don't you just hop on the train because we already have a system in place and we can just have you go into these walkthroughs and put your requirements. And find the champions, of course, that can champion accessibility across the board. Again. That was, I think, one of the better investments we've made. Because if you look at the impact of making inclusive products at the last, I don't know, 10 years... the timing was perfect. You enabled the right team at the right moment with the right kind of mindset for the entire market. Michal: I think there's also a lot of similarities between accessibility teams and localization teams in the sense that they both make content more accessible to people and the adjustments that are needed are sometimes very similar in terms of font sizes and font types and colors and whatever. Sometimes the changes are even the same changes. And so I think there's a lot of value to be brought in that collaboration. Gilad: Yeah. All that is one of those things where when brought together in a very efficient way brings value to the organization. Michal: Yeah, absolutely. Gilad: Right. So... yeah. Michal: I mean, I understand the value of making it more usable, but I'm not sure it would actually add profits. So they don't have any interest in making it better, in that sense. Gilad: Right. Sure. Yeah. That's the long going conversations of... what's the return on investment. Michal: Yeah. Gilad: I see it very differently. If user X in country Y is paying for software and user Y in country X is paying for the same software and they're both paying the same thing. Why is one of them getting a different user experience than the other? Michal: I mean, I understand what you're saying. As a person preaching for better UX, I am supposed to agree. And I do generally agree, but it sometimes feels like companies are more focused on value to their bottom line than they are on value to the UX, even though within the teams, the people who are actually working, they do want to make things better for people. But at the end, what drives. The way the company reacts to things and how they act in general in the localization space is profit, right? Gilad: I think that's why at the end of the day, some of the standard institute work is quite interesting from the UI perspective. Standards are typically a requirement to get into the market. Michal: I see so they have to... they're forced to use them. Gilad: In certain countries, they have to. We're not talking about smaller application developers. Nobody's going to approach Tinder and say you're not adhering to local standards in terms of UI mirroring, for example, or text selection. But for larger companies like Google or Apple or Microsoft that have government contracts. Michal: So they have to. Gilad: Say we're seeing that it impacts productivity in the country, for example, text selection or incorrect UI mirroring. So we come and say, we have these standards, we're going to be working with you on implementing them. And that's going to be something that we'd like to put into government contracts moving forward. And then you have everything trickle down to the rest of the market. Michal: I see. So if Google and Apple and Microsoft are doing it, everybody will do it. Gilad: Well, it goes back to the beginning conversation of, like, a small app company wants to see how to do UI mirroring. They install, I don't know, Android and look at it and go, oh, that's great. We'll do that. You know, so it kind of trickles down. Michal: You just went straight to where you can actually drive change in a way that's going to trickle down all the way to the... Gilad: I'd rather not have to work that entire mechanism. But unfortunately, that's a harder route to take. Right? Michal: So it's a very strong position of influence to be in. Gilad: Nobody puts you in that position. That's another thing about the industry. Nobody puts us in a position to make decisions and say, do X and people go and do X. You have to get buy in. Michal: Yeah. Gilad: You have to show experience. You have to show impact on the market. I was able to change the Unicode standard at one time. It was a group effort, of course. It's something that I spearheaded. It was paired brackets. Anybody in localization for bidirectional languages knows that sometimes with the reading order, the brackets used to be unpaired. Have you noticed that it's been gone for a few years now? Michal: Well, yeah, of course. Gilad: So one of the reasons that it's gone because there was an idea inside Microsoft that Michael Kaplan at the time pushed. And he said, you know, we could make an algorithm that just pairs the brackets in the rendering engine. Really simple. So that's really interesting. There are a lot of very small things that we, as users, or even as... people are involved in this, but not in the very technical kind of aspects of it. We say, oh yeah, it just got better, right? Technology is better. Can you imagine the impact on the localization space? But, basically, so, the algorithm that renders the text had to have another change that basically says, here's a mini algorithm that says, here's two brackets... it took me two years to push it inside Microsoft. Michal: Oh, wow. Gilad: And the reason it took two years is because we had two text rendering engine, three actually, inside Windows. One for the browser, one for the modern UI, and one for the legacy UI. Michal: And you had to implement in all three? Gilad: And you had to implement in all three because each one of the teams used to come to me when I approached them and said, yeah if team X and Y implements them, then we'll do it. And they all knew each other because they all kind of built off each other. And so they're... I always thought that they sit in a secret room and go, don't do it, don't do it! Never! Don't, don't listen to him! And... Michal: They probably did. Gilad: Yeah. They're probably going to be watching this video and go... Michal: Oh, they're on to us. Gilad: But so, but, but it was quite a bit... you know, text rendering engines are very complex things. I'll give them that I, I wouldn't want to touch it. It's fragile. You never know what you're going to get. And it's one of the funnest things to work with... I mean, rendering engines people are really smart people. And so sitting with them and hearing about the different scenarios and the edge cases and things like that... But sometimes you have to just say, you know what, yeah, there's going to be edge cases, but like 80 percent of the time, we're going to see great things. Right? And it's better than not seeing it at all. So getting one team to just build a prototype was what broke the ice. It took them a week. And then they said, Great, well, yeah, it's a fun prototype. See you in a few years. And so again, it took the director level escalation of saying, Hey, how do we move this forward? The reason we moved this forward was actually bug data that we had from a previous release. We had over a thousand bugs across the Windows operating system for paired brackets. Those were a thousand bugs that we had to send back to the localization vendor and say, please insert the correct Unicode control characters to make sure that these parentheses worked. And so one of the key points is have data and have an expert present the data and say, you know, we had a thousand of these bugs. If we're able to change this, we're not only changing it yet for Microsoft, for Windows. We're changing it for any application that runs on top of Microsoft. And so you're able to not only make an impact on the operating system level and avoid these thousand bugs because the next release they weren't there anymore. We had maybe a dozen bugs for paired brackets on very complex strings inside UI that me and you would never see, the device manager or something like that. And so we were able to see the impact immediately. Michal: Wow. Gilad: And we never measured the impact outside Microsoft. Like nobody said, wow, all these bugs are gone. Thanks. Somebody must've changed the Unicode control. Being able to change these things shifts the industry to a better place so that they're able to work less to produce more. You know, a thousand bugs is a thousand bugs. Michal: Yeah, no, I mean, even the time that for us as localizers, that we don't have to invest in copying that right to left character. Pasting it into the editor, and then doing that again and again and again, every time... Gilad: Are you still doing that today? Michal: No, but I used to have to. Back when I worked with Trados Studio, I used to have to. And now I don't anymore. Gilad: Why not? Michal: It just works. Gilad: Oh, it just works. Michal: Well, I'm actually not sure if CAT tools automatically insert that character, or I don't know exactly what's happening in the back end, but I don't have to. When I type a bracket, usually it goes into the right place. Gilad: Right. And that's cost effective. You know, you're able to produce localized versions quicker with less bugs and less engineering overhead and less fixes from certain teams. And so you have to have subject matter experts that are willing to take the risk and stick their neck out and say, something here needs to improve. No matter how big the players, and usually there's three or four big players, we need to take this in and do this. And sometimes they need the forcing function. Sometimes even the teams internally need the forcing function. If you talk to the localization folks at Microsoft and they say, Oh, you're going to have a standard for UI mirroring and it's going to be a forcing function. Great. We can go to the feature team and ask for certain things. But that's, I think... if a company needs a forcing function to improve something, then they're not thinking about their international users as much. By the way, it's true across all big tech companies. You know, maybe I'm picky. Michal: No, but I would imagine because there's turnover and people, you know, retire or leave, and then new people come in that don't necessarily know exactly what things were or how they should be done. And there's no kind of internal training function, I guess, for localization, because why would there be? And there's no standard, so that's what happens. I think in localization in general, there's no training. Gilad: Well, nobody can teach you how to challenge design. Michal: Yeah. Well, maybe that's what people should be taught is how to challenge, not specifically design, but how to challenge the people around them to make sure that localized experiences are as good as they can be. Gilad: I think that's true. I think that's also something that just on a interpersonal level organizations have to enable that. Michal: Yeah. I don't know if that's the case for internationalization, but I find that localization teams... and it's very similar to writing teams as well. They're not expected to make noise, but they have to if they want to actually be able to do their job well. So it is a movement within the industry. Gilad: Yeah. Michal: For people to learn that they need to make noise that they need to demand better design, better decisions, better collaboration. Gilad: You know, one of the things is the risk versus reward equation. Like, is the risk bigger than the reward or is the reward bigger than the risk. And so I was able to say, you know, what's the risk for you? And feature teams say, you know, people from the market might come back and say, this isn't good enough. And so I'd always say, if that's a risk for you, customer feedback or having the market reject this, or... I'll take that risk. You can take the reward. And I'd highlight that, you know, at the end of every milestone I sent an email to their manager and said they did great job because they were willing to take a risk on this. And we're now seeing that this feature is in much better shape. And so being able to mentor your feature teams, rather than just come begging or holding a gun to their head is a much better approach, I think in general. Because it's much more constructive. Michal: Yeah, that makes sense. Also, you come from a place of, again, confidence and kind of, I know what I'm talking about. So people are more inclined to trust you. Gilad: Everybody has impostor syndrome. Michal: Yeah. Gilad: Right? Everybody, even I had imposter syndrome. You know, I'm not the smartest person in the company for certain things. Whether it's design changes or bug fixes or just strategy moving forward. I put together a multi release strategy for bi-di investments. That was a first of a kind. But I had to sit down with some people, for example, that built text rendering engines. And they're, I mean, they're in a different level. And if you're able to identify who the key person is to make that investment, they'll walk you through it. You're going to be learning a lot from them and they're going to be able to get the confidence that if something in that scenario that you agreed upon, didn't go correctly, I'll take the responsibility. I asked you to do this. This is a scenario. I want you to enable. If you know how to enable it better than I do in terms of the technical edge cases and whatnot. I'll work with you on those will prioritize them and anything that goes wrong with this thing. As long as I sign off on it, it's mine. I've asked you to do it, I'll take the responsibility. And I think that's the difference between somebody who's willing to just work within their comfort zone to somebody who becomes a subject matter expert. Because nobody comes and says, you my friend are a subject matter expert. Congratulations. Here's your badge. But that's the way to achieve it. Michal: Yeah, you pick it up and run with it. Gilad: Yeah, and take responsibility. Be able to stick your neck out there and say, I'm making design decisions. Michal: Okay. I think that's a good note to end with, I have to say. Gilad: Yeah. Michal: Yeah. I think so. So thank you so much. Gilad: Yeah. Thanks for having me. Michal: Fascinating. Really. And so interesting. And I really enjoyed every bit of it, and I'm sure other people are going to benefit off of hearing everything that you've managed to achieve. So thank you, and thank you for sharing. Gilad: Yeah, and let's keep pushing forward. Michal: Definitely, for bidirectional languages, and in general as well. Gilad: Yeah, I think we're very fortunate now to have the AI revolution approach us, or is already there. And I am hoping that we're able to spearhead some new ideas around internationalization and localization. B ecause We're really here to see things move forward very quickly. So it's quite interesting. Michal: Exciting stuff. Gilad: Yeah. Michal: Yeah. Okay. And thank you for joining us on the Localization Process Pod. If you found this interesting or any other episodes as well, then feel free to look us up on www.localizationstation.com or on Spotify or on LinkedIn for more Localization Process Pod episodes and more processes from other companies as well. And until the next episode, thank you for being here and have a great day.
- Achieving cross-company collaboration with Aglaia Pavlerou
What's the best way to make progress in localization? Aglaia Pavlerou, a localization expert and manager, joins us on the Localization Process Pod to share how incremental improvements brought on a big change. From better localization quality to a more positive approach towards localization, and even business success. Audio Text video Key takeaways Dedicated localization teams offer more value than just localization. Their attention to detail and holistic view helps them support other teams with unique insights. In-house teams allow more direct management and quality control compared to outsourcing entirely to LSPs. Understanding the processes used by vendors is important to identify areas for improvement. Consistently using the same translators offers improved quality, thanks to their commitment and their familiarity with content and terminology. Showing quick wins can help get support from management for localization initiatives, and enhance collaboration with other departments. About Aglaia Pavlerou Aglaia is a localisation expert passionate about product localisation and translation quality. She has 16 years of experience working for LSPs and advertising agencies, as well as in the travel/hospitality and music/ticketing industry as a resource manager, project manager, account manager and localisation manager, as also an independent localization specialist for start-ups and well-known brands. Enjoyed the Localization Process Pod? In every episode, we'll be learning from one guest about the way they do localization for digital products. Subscribe here, on LinkedIn, or on the Localization Station website to get notified about the next ones. Transcript Michal: Hi, welcome to a new episode of the localization process pod. It's been a while since we met. Some unsettling developments in the world meant I had to take a moment to regroup. But I'm so glad to be back to talk about the best ways to create localized digital experiences for international audiences. So just to quickly refresh your memory, in every episode of the podcast, we meet with someone from a different company to grill them on what they're doing right, what they're doing wrong, and how they are optimizing their processes for a better localized experience. Today, I'll be talking with Aglaia Pavlorou, a localization expert with 16 years of experience in the field. Aglaya worked as a resource manager, as a project manager, account manager, localization expert, and localization manager. So she did it all. And she has some fantastic insights to share with you all today. So Aglaia, thank you so much for taking the time to be here and share your experience. I think we're going to talk today about a role that you have been doing, but not doing at the moment, right? It's a previous role. Aglaia: Yes. Michal: Yeah. So you want to tell me a little bit about it? Aglaia: Sure. I started as a translation project manager for a company. It was a B2B company in the travel industry. So a hotel wholesaler that would then provide a selection of rooms to different travel agents across the world. So I initially started working there alongside the content team, the team responsible for checking all the information attached to the hotels and the rooms and writing bespoke hotel descriptions for these locations. And we would just be exporting all that content, sending it out to an LSP. And then it was just coming back and fed back into the system. So before I joined, there was the intention of having this content coming back, reviewed by internal language speakers. And there were quite a few of them because we had quite a few salespeople responsible for different markets in Europe. However, it was not their main responsibility as it happens in many companies. This is an additional task that sometimes due to the workload, people cannot really pick up. So the company felt that they were investing a lot in translation, but there was no one there to check the quality or ensure that this is exactly what they need, provide some feedback, provide some guidance to the translation agency. So when I joined, I started looking at the content that was coming back. I had a few meetings with the translation agency trying to figure out what their process was, understand how they were approaching these exports that we were sending. I started looking into organizing that content better. So potentially rather than sending any new hotel descriptions that we were writing, we wait and do this once a month and maybe group them by destination or some other form of organization so that there is some consistency in the content and it's not just random things coming in for translation. I also asked that we use exactly the same translators every time and because there was no sort of big time constraint on our hands, we could wait until the team is available to pick up this work again, provide some consistency there. And then I looked into providing some very top line feedback. Everybody who works in localization and translation, they can... if not proofread, at least proof check some of the languages. So sometimes just looking at things in bilingual view, you can already look at anything that can go wrong, you know, punctuation, all this kind of like top line things. So I would provide feedback at that level. But then of course there was a lot of content and there was not enough progress as we would have wanted. So I suggested that we just take some time to regroup. Look into what is the most common feedback? What is it that we're missing? And we realized that it was mainly the terminology that that particular industry was using that we were not getting right. And even if, you know, sometimes the translators would get it right, there would be no consistency through every batch. So I suggested to my manager to bring in some freelancers to help us kind of create those reference materials in the first place. My suggestion was that we bring in a team of translation freelancers, ideally specialists in the area of travel. We just bring them in for three months. They have discussions with internal language speakers. They learn how do we speak to, you know, partners in our local markets, understand the lingo. They bring also in their expertise and we take three months to put together a glossary and some style guides for every market and set the standards that we would then share with the translation agency. At the same time, the best way to put together these reference materials is actually starting to translate the content yourself. That's how you discover exactly what is needed. So, We did this, I think it was at the time when remote working for full time employees was not really an option. So we had to build this team in-house in London and it was really a great experience for me. The company sort of thought this was a great idea, but they did not really want to invest so much in that. So I did the recruitment myself, through translation platforms that I was also using as well, getting in touch with some of the universities in London that I had collaborated in the past. And I put together a team of 80 translators. So that was for French, Italian, German, Spanish, simplified Chinese, Japanese, and Brazilian Portuguese. And the results straight away were spectacular. And that's because when translators come in and they start looking at the content, they don't just look at it from the point of translation. They just analyze it, they double check it, you know, they question it. So we started seeing the results, not just in terms of building up these references and all the translation quality that the team was producing, but also productivity and how that had increased due to putting together this very detailed process. It was really amazing. So we ended up extending the lifespan of that team and the whole thing became permanent. And that was kind of like the first step. And then we continued with a few more, but that was kind of the big first step that helped us to very quickly show the business what was the value of having these people in house and sort of committed and focused to that content full time. Michal: That's amazing. So first of all, what I like about this. We're just at the beginning and you just started telling me about it, but I really like that you kind of took control over what you're doing in localization. I think a lot of the times companies, they relinquish that control to the LSP, to the vendor, to whoever's kind of managing their process. And then you don't know what to fix, right? You know something is wrong, but you have no idea how to fix it because you don't know what's going on. I think... you say that hiring linguists was the first step. I think that was the first step. It's kind of just taking control over it and saying, okay, we need to understand what's going on so we know how to fix it, so we know how to improve it and optimize. That's amazing. Aglaia: I think this is a really big challenge when you join a company, when you're client side and you come in, you have to assess where in the, kind of like, localization journey this company is and find the best solution for them. It's quite nerve wracking. It's a big responsibility, something that you take on yourself. You coming in as a specialist, you're the only person that is specialized in that area in a company where everybody else is interested in something else. That might be hotels and rooms and swimming pools that are closed for the month, you know, causing issues. And you're there thinking about language and terms and things that they're not really important to most of the company. So it's a big responsibility and It's also very difficult to make a decision that would also make sense down the line considering how quickly things change and how quickly companies grow. Michal: Yeah, absolutely. if you were the only person, kind of, advocating for better localization, how did you manage to convince your colleagues, your management, to go ahead with this? Aglaia: At the time I had great support from my manager, who was the marketing team lead. We were set up under marketing. And... not speaking just English, I think that already gives someone more insight into why translation is important and why it is something worth looking at. She was very supportive and we basically put together a business case where we showed the expected return on the investment of just having these freelancers in for three months time. It was very difficult, obviously, because we're making a lot of assumptions about potentially the money saved down the line. But also, and this is, I guess, a topic it's always coming up in discussions about how to influence the localization process in a company is how do you attach a value to translation quality and content quality. Because it is very difficult. And that's how we started this conversation. How can you prove that translation quality has directly affected great results in the market. It's very easy to do it when there is localized content or not, but it's very difficult to say, okay, this exact percentage of increased sales in the market is due to the fact that the localized content reads so much better now. Michal: Yeah. The experience is better and not just exists. Absolutely. I completely agree. So how do you manage to prove that? How did you manage to say, okay, localization is better now because we have invested into this process and hired people who are more invested in the quality and then it led to better results. How do you manage to prove that? Aglaia: It sort of happened a little bit indirectly. So, for myself, this is the thing that I could sort of put forward, that with the same budget that we allocate to translation every month to outsource it, in three months time, I can set up this team. Which obviously, you know, having a team in house, it also has all these overheads, you know, so I took that into consideration. I propose that we can make this investment, bring this team in and obviously get to translate the same amount, but also at the same time, look at all these important quality questions and put together all these references that we think are very, very important. So once I managed to show that this budget would be more or less the same and we'll be getting more out of it, that was the first step. So that was an easy comparison to make. But basically what happened down the line was that... Because the content was organized better before sending it to translation, so putting it together in batches where, you know, we would just work on translating descriptions of hotels around the same area, it was easier for the translators to also provide feedback to the content team. So whilst we were doing this process and we were sitting right next to the content team, we were able to flag either inconsistencies on the content or maybe mistakes in the descriptions, typos... Obviously, whenever you put something through a translation platform and you keep repeating certain words and the typos are even more obvious from the beginning, the moment you open up the file, you see something is 97 percent match and then you see the typo. So they're very easy to pick up. So we started having these conversations, or maybe sometimes arguing about what color is the roof of a certain hotel. Between the content team and the translation team, there were some fun moments. And we then realized, having brought all these experts... because this is another thing that I wanted to do when putting together the team. There were some younger linguists that might have just left university. They were very eager to work and I know how difficult it is sometimes to find an in house translator position. So I know this is a very exciting opportunity. You know, there was a lot of drive on their side, but also I had some more experienced translators. Some of them had actually worked in other travel companies and they brought a lot of expertise with them. So I basically opened up the space and I let them take the lead and influence the processes and bring in all this expertise. So at the time I was actually really young and I was just there as a translation project manager. I was just there coordinating and bringing everybody together and ensuring that we're using a process where all of this work can be documented. As we kept working, I realized that there is a way that we can organize this work because the content, in a way, it was repetitive, but there was no consistency. So, what we suggested to the content team is... why don't we organize all these hotels based on their areas? So, what if we would break up London, let's say Central London, in six or seven different areas that make sense? How people would look for them, you know, when they want to book a hotel, they will probably look for West End, Covent Garden, Liverpool Street, you know, around either transport hubs or areas of entertainment. And then once we have decided how to split this, then we can just write really nice area descriptions. And then whenever we have a new hotel in that area, we just drop that description there. This means that we have this consistency every time, mentioning the same sites and means of transport. And then this means that also the content team can save about 15 percent of their time when they write a new hotel description. Then there was a lot of practical information that was kind of repeated all the time. So whether there was a private parking facility in the hotel, if it was a parking facility nearby, if there was a swimming pool available... So then we said, okay, how about we standardize all the sentences, but we always describe this in the same way. So we prepared this kind of defaults and this is how to describe the swimming pool, the parking facilities, et cetera. So, by doing all this work, the content team started saving about 20%, I would say, whenever they were writing a new hotel description. That, times the amount of work that the team was going through... I think at the time they had maybe six or eight writers that were also doing a lot of fact checking and a lot of other tasks, but that was the main task. That brought huge savings. But also that meant that when we moved to translation, we had translated that area description once, and then that was a match every single time. Same with all the other kind of default description sentences. We translated this once and then it became a translation memory match. And that also kind of brought up our productivity. At some point, the team was able to go through 5,000 words a day. Which was amazing. So the more we invested in the process and looking at the content and rearranging and reorganizing it, there were savings on both sides on both teams. And at the end of the day, this is what the leadership of a company wants to see. Savings, either time savings or cost savings. And at the same time, we're able to improve the quality of the English content and the translations. And then that sort of started coming through. As I mentioned, indirectly – feedback from either the sales teams, receiving feedback from the local travel agents saying how the content is really great. It's very consistent. It's very easy to look at the hotel descriptions and kind of compare and explain to clients what are the hotel's best features, because the rest of the content is kind of similar, so you don't have to read through carefully, you just look at what is different and you can focus on that. That also helped the company secure some partnerships. So bringing in this great quality English content and translations helped them work with some really famous brands. One of them was a very big airline that also provides holidays under the brand. So they would kind of link their flights booking option with. a hotel booking option and that would actually fit through our system. Because it would not only bring the allocation and the competitive prices, but also would bring in our content. So that was one of the pluses in the process. I think the markets where the quality of translation really was shown through was in China and Japan. And I think this is where there were great sales wins because the content was really, really great. And we would get this feedback especially from Japanese sales team, that the content was one of the biggest draws for travel agents to work with that company. Michal: Why do you think it was so dramatic in those markets? Do you think that it was just by chance you had really good linguists, like increasingly better content for those markets? Aglaia: That's a very good question. I think it might be a combination of the two. I think there's also an added layer of difficulty trying to break into these markets from Europe or a brand from these markets breaking into Europe, there's another level of difficulty. In a previous job, I was the person responsible for resourcing translators for a luxury jewelry brand that was aimed at some of the Asian markets. So they had really great, beautiful ads and great content. And we had to adapt these for Japan and for China, Taiwan and Hong Kong. When we won the business, we had to do several tests to see sort of what teams of linguists would work best. So we had a small pool of translators who were specialized in that area. And then we would do tests with different content to see what is the best combination, who should be the editor, who should be the translator, swap the roles around, swap the teams around to find the best match. And what we found out was that the best results we would get was when the translator was based in country. And when the editor was based either in Europe or in the U.S. The translation was always correct to begin with. And then we would get that kind of like final finish from maybe translators who are based in Europe or in the U.S. and have kind of like a better understanding of the marketing and branding nuances that are sometimes sort of hidden in maybe the artwork or the copy. So that was the winning combination and we sort of stuck with that. Which was also making work a little bit different, working with all these time zones. So, I'm not really sure, but I think, and I've also seen it other times, being able to bring the translators in house, even on a part time capacity, and expose them to how the company works, and involve them in different processes. I think this is where, it's not just a job where you just open a file, you translate, and then you send it back. You give them the opportunity to immerse into everything that the company is about. So you don't just see the content, but you also see the values of the company, the goals, the long term strategy. And obviously the more time you spend being attached to a certain brand, the more you sort of...become part of it as well . And I've also seen it for myself when I have been freelancing, when you get a better insight into the company and how it works and what happens to the content before it comes to you, what happens to it afterwards, you get this kind of like full view of how things are working and how small decisions or small details influence the process before and after. Michal: Yeah, absolutely. I want to take us back a little bit in the conversation. You mentioned that you proved the value of the quality improvement in the savings for the company. Which is a really big aspect of it, but I'm also curious if you managed to test how that improvement influenced the way that your users and customers behaved within the website. And were you able to collect any data that kind of showed that improvement in localization actually? Affected the bottom line, the usage rates, any analytics or data in that space. Aglaia: So that was not really possible in that specific scenario because the company at the time did not have their own website because it was a B2B company, not a B2C company. They were sort of plugging all this content into other websites. Michal: I see. Aglaia: It was very difficult for us to be able to get that direct data on this, other than having the information from the sales teams on other feedback they got from the ground or how they use this updated and improved content as an additional tool to get new partnerships signed. That was something that I was not able to look into at the time, but it is something that I'm interested in and I'm looking to different ways to implement it in my current position. And I'm just thinking if it is possible to actually break down feedback on the user experience to look into how the language has affected that. I think it's very difficult to do that because it's not just the language. It's not just translation. It's also how the design interacts with every language and then how far this is localized and adjusted to the local market. The localization process also plays a role, whether linguists are able to look at the whole website page and work on it in one go, or do they get just one paragraph without context that then gets plugged in, and they have no overview of what comes before and after . It is difficult to break that down and break down the user experience between the functionality and the language. So it is something that I'm looking into and trying to find different ways to measure that, apart from potentially including a few questions about that in surveys sent out to customers. Michal: Yeah, it is really hard because I think, first of all, like you said, it's really hard to differentiate what really impacts the user patterns and the way that users behave on your website because it can be a result of a lot of different things, both cultural and design and localization, content... it could be a lot of different kind of things and a lot of different things combined and even the state of mind of people at that specific area and that specific day, it could really vary. So it is really hard. What I find is the best way is to just design tests for that purpose, because otherwise it's really hard to just be able to isolate that very, very tiny aspect and see what impact it has. And so if companies do want to be able to measure localization quality, they need two versions of localization. And no company has two versions of localization unless they're actively trying to create them to actively test the impact of localization quality, which is, you know, it's out of preference. It's not something that a lot of companies put at the front of their agenda. But I do think that if companies were to give it a try and even do just small tests every once in a while, every year. Just to see how much your quality can improve or how much impact it can have. They really do stand to gain a lot. And I think the story that you're telling here is, is really a testament to that. Because I think you took some sort of leap of faith, right? You came and you improved localization without actually knowing that it's going to make an impact. And it made a huge difference for the company. I think it's something that you have to just leap and do. You have to really believe that it works and try it because otherwise I'm not even sure if you can... because the opportunities for improvement that you have discovered during localization, I'm not sure if anyone could see them in advance, or from the outside. Aglaia: Yeah, absolutely. I think something that localization brings in any company and any process that it is involved is... Most of my colleagues and a lot of my friends who are in the industry, we always bring in organization process improvement. We're always looking at ways of improving the ways of working. We're always looking at ways that improve accuracy, attention to detail, improving timelines, reducing costs. I mean, no one wants to do three rounds of review because somebody forgets to send the updated version or the updates on the line, you know, everybody wants to be very efficient and we kind of bring these qualities everywhere we go. So whenever you change roles and you find yourself in a different environment, such as the one where I'm now, you kind of bring all this experience with you and you start asking the difficult questions. Who's going to review this? Who's going to sign off this? And you basically bring these efficiencies together in any process. This is something that always, always adds value. And it's kind of like the start of a journey that you never really know where it's going to go. Because we always look at the content and the copy in a more kind of like systemic way. If that makes sense. We're always looking at the content thinking, what's the best approach for this? Should this be translated, localized? Is this just maybe creative translation? Does this need to be transcreated? So we're always looking at the best possible process for the best possible outcome. Michal: You mentioned that when you made this significant improvement, the biggest thing you did was bring linguists into the team and kind of have them work with you and have them really get invested in your brand and your needs and company's needs. So why do you feel that this made such a difference compared to the way that you worked before? Aglaia: I think it has to do with the brand and the content in question in every case. It might be that if the subject was maybe a little bit more, I don't know, mainstream or easier to translate. I mean, hotel descriptions, it's something that everybody's familiar with. I think this is something that kind of is part of a bigger conversation. What is the quality expected? This kind of ties in with why some of the biggest translation companies in the world seem to be more focused on sales , but they seem to not focus so much on what it is they're delivering back to their clients and also not treating their translators in the best possible way. How can someone get away with this? And I've seen it in practice many times that sometimes the client expectations are not really high. It might be that we, as professionals, we always try to get 10 out of 10. Sometimes for a client, a 7 out of 10 is acceptable. And I've seen it in the past. We would do a very detailed process of translation, editing. Then we had an internal terminology team checking, making sure that everything is implemented, the client glossary, the client style guides, and then we would send them out for review to the local marketing offices and no one would get back to us. I think this is why sometimes translation agencies will deliver things that might not be a 10 out of 10. And sometimes that's okay, because also the expectations are a little bit lower. But the moment that I feel that if I'm involved in something, my expectations are always higher. Michal: I think it's all tied together, right? Because if it's so hard to define quality, and it's so hard to measure quality, then people learn not to expect quality because they say, okay, so it's just impossible. It's just impossible to achieve. So why should we focus on this? Why should we invest our resources or time or effort onto this when it's just not achievable? And I think the more that we put the focus back on quality and how to define it and how to measure it, then maybe it'll become more feasible for companies too. And then maybe they'll focus a little bit more on just giving more attention, if they're not part of the localization team. Like you mentioned, the marketing teams, the product teams. I think once they understand that it's feasible and it's doable, then it becomes more of a priority, because it becomes... Something that's actually possible to do a real possibility. Aglaia: Yes, I think it's also very difficult to be objective when it comes to translations. And I think this is one of the main conversations that we will have all the time, no matter which side of the fence you are, getting feedback on translation saying, "Oh, I'm not very happy with this translation. It sounds like Google translate." This is my favorite kind of feedback for translations. So it's very, very subjective to define quality. Especially when it's not discussed between localization professionals where we can sort of break things down and be more specific. Sometimes it's very difficult to have these discussions with people who are not part of my industry. And I think this is one of the main problems. It just makes things even more complicated when trying to explain why quality is important, why localization is an investment and not just a cost, and why sometimes the end client is not getting what they want because they have not been able to express it in advance. Michal: Sometimes there's also a lot of emotion. You mentioned feedback and how hard is it to get objective feedback. Cause you can't really be objective in language and it's the same in writing. It's the same when you localize. I think whenever you deal with content, there's always kind of subjective feedback and it's subjective not just because it's your own opinion, but also because sometimes you're in the market, sometimes you're not in the market when you're localizing, sometimes you know the brand well, sometimes you're an external vendor and you don't really know the brand and then that feedback doesn't make sense to you because you're not so invested into how the content is written for them. I find that a lot of times when you take the ego out of the conversation and you say, it's okay that there's feedback. Cause it doesn't mean that any of us is wrong. It just means that maybe something is more right for the brand or something is more right for the market. And when you take that emotion out of it and it becomes much more of an efficient conversation because we're no longer talking about what you did wrong, what I'm doing wrong. Or I'm no longer attacking you for something that you did. We're having a conversation about what's best for the brand or what's best for the audience. And we have a shared purpose, I guess, or a shared goal. And then it becomes much more efficient and much more beneficial sometimes. Aglaia: I really agree with this. This is why we need these contributions and the feedback from the local markets to get to the right point. And I brought this comparison up a couple of days ago, discussing some internal feedback. When we put together an English copy for something that will be highly visible, maybe go out to clients, partners, it usually is seen by 10 different people within the company. It will be potentially the copywriter, some of the stakeholders. If it has to do with the product itself and the product managers will have a look to ensure that all the technical details are correct. And then it will probably go through a few rounds of revisions. And we think of this process as a process that makes sense, that it is productive. So why do we feel that once the translator works on this exact same copy, it should be ready, adjusted for the market, ticking all the boxes. But I feel that sometimes the local teams think, oh, this is not what I expected, but they don't understand that they should be part of the process. And this is a very long process. Even if you work exactly with the same translator and provide this feedback, there will be improvement, this is a longer process to get someone to adjust their style to your expectations. It's very easy to say, okay, this is how we'll be translating these terms, and this is how we'll address the audience, you know, singular or plural. These are usually being done. But when it comes to finessing the style, to reach a point where the local team will have to make no changes? That takes quite a bit of time. Michal: Yeah, because right now when people started working with like generative AI for writing, for creating content, then it becomes really expected that you get this kind of rough draft. Then you have to give feedback on it, you have to adapt it, and at the end you get a result that you like. But it takes a while. And it's funny because it is the process that's supposed to be when you write with a human as well, because nobody can really understand everything you're expecting in one go. It's really hard to do. And so you have to have that kind of iterative process of doing something, getting feedback, and doing it again, and getting feedback, and sometimes even bringing it to market and getting more feedback. To get it as optimized as possible, as effective as possible. And it's so reasonable for us when we work with machines, we work with Gen AI. It's not really reasonable for us when we're working with humans, despite the fact that we have more bias and more our own opinions and we bring more of our own emotions to the table. So it should be even more reasonable, but I think maybe we're not used to it still. Aglaia: Yeah, I agree. And it would be great if that was the wider sentiment behind this, but I don't think it is. And this is something that was sort of expecting, that the moment you start this process of putting your translations through local review and requesting feedback, you open up a very big can of worms. You have to be ready for it. And this is also one of my questions when I'm recruiting for translators is how do they handle feedback? Whether that feedback is reasonable or unreasonable. How do you handle this? How can you defend your work? What is it that you fall back onto when people will say, "Oh, but I don't like this. This should be not X, but Y". As you said, it's nothing personal and you need to take on feedback. You need to accept it. You don't have to take it personal and you have to be open to it because this process is not really perfect. It's just, there's always room for improvement, as you said. So it's just difficult to manage everyone's expectations. Michal: Yeah, but I also, I think, because I asked you before, why do you think that bringing people into the team made them better linguists? And I think it's part of it. I think when people are feeling like they're part of the team, it could be the same linguist. I think when they're working within the team versus when they're working as kind of an external freelancer that's not part of the team and not part of the process. They will provide different results. You'll get better work when the person is actually invested into your company. When they actually feel like you expect more of them, then they will provide better work. Even if it's the same person. So I think this feedback and this kind of iterative process, it's also part of it. Because when you do the iterative feedback with a person, then they feel like they're part of the team. They don't feel like... a toaster or something that you put the bread in and you take it away. They feel like they're part of it. And I think it makes them do better work as well. Yeah, I compared people to a toaster. I'm sorry about that. Aglaia: For me, what I consider a success when I join a new company is when I try to come in and bring in a new process and maybe introduce the translators. At some point we reach this kind of benchmark moment when the local team will say, you know what, we don't even need to look at this. We trust that X translator has done a great job. They know what we are talking about. They know how we would like to express ourselves. So we don't need to have this review step. We just go forward and we're going to have a look at the final artwork and then we're ready to go. This is what makes me really happy. We're about one year into having this translation team looking after the bulk of translation. So it's great to see how the translators are also invested on the brand, how they will themselves flag things that we should be looking into or using the product, noticing things. They are also invested because they feel that the output of what we're putting out there is part of the work. They want to feel good about what it is that is available within the market. And they feel that it also represents them. So I'm very, very happy about that because I feel that the responsibility is sort of shared, but also the great results can also be shared across all of us. Michal: I'm curious. Can you share what the previous company was or is it like a mystery company? Aglaia: It's not a mystery company. It's a small B2B company based in London called Travco. It's been about almost 10 years since I've worked there. So... Michal: Oh wow. Aglaia: Yeah. A lot of things have changed in the company. And yeah, sometimes I will pass by and still see the office there. Michal: Where do you work today? What company do you work for today? Aglaia: At the moment I'm working for Dice, it's a music ticketing app based in London, and it is available in a few markets... the UK, the US, France, Italy, Spain, Portugal, Germany, and now expanding to India, and a few other markets. And I'm responsible for the localization of the app and all the partner tools and communications. Michal: So I'm curious... What difference you see from the work that you did 10 years ago, for the travel company, to the work that you're doing today? What kind of the major differences in the way that you work? Aglaia: I think the main difference is that translation technology has really changed and improved since then. And this is one of the reasons why I find what you do very exciting and very interesting because I think all translators who are working on the localization of apps are also UX writers for their language. And this is something that I would like to introduce as a process in my company. So... be able to look at any new or updated features, and work on them for each language alongside the UX writing. Being able to look at the user journey for that particular feature Michal: Or on the localization station email list for updates. Aglaia: and be able to design the content in the best way for the local language. And also being able to give feedback on the design while this is open to discussion and not after everything is finalized and checked and wrapped up. Michal: We touched on so many important topics. And there was so much that you said, I think would really resonate with people. Thank you so much for taking the time to share everything. Cause really, I think there are a lot of lessons to be learned here. Aglaia: Thank you for this opportunity. I didn't think that I would have a lot to say that might be useful or important, but it was a great, great conversation. Really good questions. Michal: Yeah. This was really fascinating and there was a lot of things that people can kind of benefit from hearing. I was really surprised to hear that was 10 years ago, because that felt like a really modern approach. There are big companies that are not doing half of the things that you did 10 years ago. So that's really impressive. And then seeing how you're starting to iterate on UX content and UX localization these days in your company, I'm sure it's going to lead to really great content at the end. And I really support that too. I think that the more localizers are treated like writers in the climate that we have today and the way that we're doing content today, the better content is going to be and the easier it's going to be to create that as well. Aglaia: Yeah, absolutely. I think the conversation that you have started is really, really important, is not for linguists to kind of like put themselves into boxes, because I think this is something that we struggle a lot in the industry. We're very worried about stepping out of our comfort zone and picking up new things and picking up new skills. And I think this is a great way. You see this happening, you know, in other industries and in other areas around what we do. People move from one kind of like aspect of this world to another. And it should be the same of us. The fact that we might be working in a different language, which is not English, should not be restrictive. So that makes me feel very excited and optimistic about the future opportunities for localizers and translators. Michal: Yeah, absolutely. That's been amazing. So thank you so much for being here. Thank you for sharing your experience and sharing your tips and your ideas. It has been really, really interesting. Also, thank you, my listeners, for caring and staying passionate about localization. I was really inspired by Aglaia's take on localization quality and her actionable outlook. I hope you'll take something from this too and try to make localization better at your company, step by step. If you're as passionate about localized user experiences as I am, make sure that you join our community. There's a link on the Localization Station website and it's where we have really interesting discussions about localization quality and technology. There are job postings, so if you're interested , please join the community. We would love to have you there. And if you want to hear about new episodes of the Localization Process Pod, be sure to subscribe on Spotify, on YouTube, or on the localization station email list for updates. I was Michal Kessel Shitrit and this was the localization process pod. I really hope to see you again for another localization process review soon. But until then, I hope you have a great day.
- Localizing success messages: Creating local magic moments
"Yay, you did it!" "Congratulations!" "Awesome!" Little digital affirmations like these, known as success messages, are an important part of making our apps, software, and websites feel great to use. However, these messages aren't one-size-fits-all. The way we celebrate and convey success can differ a huge amount depending on where we are in the world. Picture successfully setting something up, completing a task, or unlocking an achievement, only to be met with a digital response that feels wildly inappropriate. It's a jarring, immersion-breaking experience. As UX experts, getting localization right for these tiny but key bits of microcopy can be the difference between your product feeling genuinely tailored to a global audience, or culturally tone-deaf. Our idea of success is shaped by our culture — and this has a widespread impact on our choices when it comes to localized success messages. For example, for many Western cultures, achievement is an individual thing – it's about effort, winning, and personal gain. Our success messages reflect this: "You nailed it!" or "You're a star!", or in the case of this message from Bloom, "Beautiful work". In contrast, some other cultures emphasize harmony and the collective; overtly celebrating personal success could seem boastful or insensitive. And that’s not all of it. Essentially, we understand and express our feelings about success differently as well. In some cultures, a quiet, satisfied "Well done" might be the most effusive response, while in others a burst of celebratory emojis will have a much more positive impact. Take a look at this Starbucks message - would it work in your language? It's not always about happiness Hang on... I just talked about happy celebratory moments, but success messages don’t always fit into that box. Surprisingly, success isn't always a good thing. Consider the success message you might show after a user deletes data, or unsubscribes from a service. These actions might be necessary, even a relief sometimes, but do they really warrant a joyful message? Probably not. Take a look at this message from Turo, for example. Cancelling a trip warrants some confirmation - but it's very likely we won't be happy about it. And, of course, this is where localization can get even trickier. People from different cultures may expect different kinds of acknowledgment, even if the outcome is neutral or bittersweet. Imagine canceling a service after a negative experience – a tactful confirmation like "Your request is being processed" might be the most culturally sensitive response. Yet, in a different market, that could read as cold or even passive-aggressive. Triggering the right emotions (and avoiding the wrong ones) Okay, so localizing success messages is about way more than just swapping out words. It's about hitting the right emotional notes – but how? Here's where collaboration with in-market experts is vital. And this comes into play in several ways: 1. Work with cultural advisors to adapt the tone of voice: Is it formal, friendly, or playful? Success messages should align with the product's established tone, but this can be flavored with cultural nuances. Cultural advisors can offer deep insights into how successful outcomes are understood and expressed within the target region. These insights are priceless. 2. Allow some creativity, especially in celebration & encouragement: Instead of generic "success" messages, consider ways success can provide value to the user. In our busy digital lives, users often appreciate success confirmations that offer additional value. Instead of just saying "Email Sent!", the message could ask, "Want to send another?" or provide a direct link to the outbox. This blend of acknowledgment and action saves the user time and effort - just like Wise did here, nudging you to add some money to your account while you wait for your card to arrive. When designing these messages, keep the audience in mind - since they could have a different effect than you’d expect. For example, showing the next steps may be motivating for some audiences, while telling users to ‘relax’ might be better for others. Sweetgreen is telling users to "sit back and relax". Will that work for your market, or will it make users antsy and agitated? 3. Think about visual Accompaniments: It's not just about the words! Visuals like icons, animations, and images will help you make the success experience better. They can reinforce a humoristic tone, lighten up a heavy message, or make your content a little bit more relatable. Check out this message from Gojek below - did the illustration enhance the experience in your opinion? Certain shapes or icons may carry positive associations in the region that could be incorporated, making the message feel more familiar, personal, and natural. Some pitfalls to avoid 1. Don’t expect the English copy you wrote to be effective everywhere. Even if you've tried to write your English-language success messages with sensitivity, there are always nuances you'll miss if you're not intimately familiar with the target culture. Seemingly simple phrases might evoke an unexpected reaction (positive or negative) depending on context. Example: "You crushed it!" sounds enthusiastic to a Western ear, but directly translated might come across as excessively violent or aggressive in a different cultural market. It’s a good best practice to run user testing with people from the target region. That’s the most reliable way to uncover unexpected meanings. Provide them with your English message and ask them what feelings and associations the message evokes for them. Remember, YOUR cultural norms aren't the baseline. Test those messages on users representative of your target region. 2. Don’t assume you know better than your local experts. Have a discussion instead Localization specialists and cultural advisors bring expertise that, by definition, you don't have. Overriding their suggestions because something "sounds better" to you risks undermining the entire localization process. Example: Your cultural advisor might suggest a success message that sounds wordy or even a little subdued to your ear. However, that might be the perfect tone for the target market, and pushing back could lead to a message that comes off as culturally inappropriate. If you’re still not sure, always ask why. Have your in-market experts explain the cultural reasons that a phrase or tone works better than your initial idea. This is a fantastic opportunity to deepen your own understanding. 3. Don’t go for "fun" at all costs Humor is one of the hardest things to translate. It’s built on shared references, expectations, and wordplay, all of which are incredibly difficult to translate accurately. A harmless attempt at humor can easily turn cringeworthy, confusing, or even vaguely offensive in another language. On top of this, overly enthusiastic celebratory language can feel ironic or even cynical. A more understated, almost factual acknowledgment of the user's progress can be cooler and more in line with certain market segments. Example: A punny success message like "Nailed it!" is delightful only if the user recognizes both the literal meaning and the celebratory slang use of the word "nailed". If the phrase is translated word-for-word, it's likely to simply be confusing. So when in doubt, keep it understated, especially for high-stakes interactions. A neutral-positive tone is much safer than attempting to replicate a sense of humor that might get lost in translation, literally and figuratively. By the way, that doesn’t mean the source copy has to be stripped of its creative or fun side. A localized version can stray from the original as long as it maintains the same overall meaning. Extra Credit: Related contact points to consider 1. The opposite of success: failures and errors How do you convey that something hasn't quite worked, or needs extra information with cultural sensitivity? 2. Micro-celebrations Even small bits of progress, especially on complex tasks, can benefit from messages tailored to the market. And you don’t have to stop at words. Tiny visual cues, like a delightful animation or a subtle color shift, can convey positive feedback in a way that feels universally understandable. 3. Sound for success Don't neglect audio cues! A subtle celebratory sound effect for micro-wins, or a reassuring tone to accompany progress updates can work across language barriers. As always, ensure the sounds are tested, as the same celebratory fanfare might not always be interpreted as positive. 4. Timing of the celebration When success is a slow burn process (think multi-step applications), is immediate gratification valued? Some users in a high-speed culture might enjoy instant positive affirmation, while others might find it distracting until the larger task is complete. That's it - hope these tips gave you something to think about! Now go forth and localize some fantastic success messages. Good luck! :)
- To localize or not to localize: Making the right decision
Localization can be a game-changer for expanding your product's reach, enabling you to connect with a global audience in a more meaningful and culturally relevant way. It opens doors to new markets, drives engagement, and can significantly boost your bottom line. However, it's essential to recognize that localization isn't a one-size-fits-all solution. Not every company is at the right stage to dive into the complexities and expenses that come with adapting their product for different languages and cultures. Rushing into localization without a clear strategy can lead to wasted resources and missed opportunities. Let me play devil's advocate for a minute, and remind you that sometimes, saying "not yet" to localization might actually be the smartest move. It's crucial to evaluate your readiness and the potential impact before making such a significant investment. Let's break down how to make an informed decision about whether localization is the next step for your digital product. We'll explore key considerations like audience analysis, resource allocation, UX integration, and strategic piloting to ensure your localization efforts are both effective and efficient. 1. Know your audience, and make sure it wants localization Before you start translating everything, ask yourself: who are you really building this for? If your current user base is predominantly from one region and you have limited resources, it might be wise to focus on perfecting your product for that primary market first. Use analytics to understand where your users are coming from and how they're interacting with your product. Spoiler alert: if 90% of them come from a country you're already serving, maybe hold off on the massive loc project. Understanding your audience is crucial. Dive into your user data and segment your audience based on geography. Look at engagement metrics to see which regions are showing the most interest. If you notice that a growing portion of your traffic is coming from a specific country or region, that’s a strong indicator of where to focus your localization efforts. Also, consider conducting user surveys to get direct feedback from your users. Ask them about their language preferences and how comfortable they are with your product in its current language. This qualitative data can provide deeper insights that numbers alone might not reveal. 2. Ensure you've got the resources you need Localization is a fantastic investment, but it's also a significant one. Assess your resources—both financial and human. Do you have the budget to not only translate but also culturally adapt your content? Do you have a team (or access to one) that understands the nuances of the new market you're targeting? If you're here, I don't need to tell you that quality localization is more than just swapping out words. Consider the cost of hiring professional translators and localization experts. Good localization isn’t cheap, but it’s worth the investment if done correctly. Take into account technology costs and the additional engineering you need. Think about the people who will manage this: Do they have the capacity to handle such a big project? Will you be hiring additional staff or transferring some responsibilities to make this happen? Hint: If you're planning on letting a localization vendor handle everything, you'll be giving up massive amounts of control. You'll also be very likely to have to settle for less when it comes to quality, so it's definitely something to think about in advance. Also, consider the long-term return on investment. Will the cost of localization be offset by the increased revenue from a new market? Can you model this to show how much, or when it'll happen? Sometimes, a conservative approach, like starting with a single market or language, can help you manage costs while still expanding your reach. 3. Remember that UX and localization go hand in hand Your user experience should guide your localization efforts. A poorly localized product can damage your brand reputation, doing more bad than good. Ensure your UX design is flexible enough to accommodate different languages and cultural contexts. For example, think about text expansion in languages like German or the right-to-left reading direction in Arabic. Because nothing says "we care" like a button label that's cut off mid-word... Right? When localizing, consider all aspects of the user interface. This includes everything from navigation menus to error messages. A seamless UX in one language can turn into a nightmare in another if not properly adapted. Work closely with your UX designers to ensure that the localized version of your product maintains the same level of usability and user satisfaction as the original. 4. Dip your toes before you cannonball in If you're unsure about diving headfirst into full-scale localization, consider a pilot test. Localize a portion of your product or launch in a single new market to gauge the response. This can provide valuable insights and help you tweak your approach before a full rollout. For instance, you could localize a landing page and drive traffic to it from Google or other sources. By comparing the engagement and conversion rates of localized versus non-localized traffic, you can gauge the potential impact before committing significant resources. Running a pilot allows you to collect data on how well your localized content performs. Look at metrics such as bounce rate, time on page, and conversion rates. These indicators will help you understand whether the localized content is resonating with your target audience. Additionally, you can use A/B testing to compare the performance of localized content against the original version. This method provides a clear, data-driven approach to measuring the effectiveness of your localization efforts. 5. No one wants to think about the legal stuff... But you really should Different regions have different legal requirements. Make sure you're aware of any local regulations that might affect your product, from data privacy laws to consumer rights. Compliance isn’t optional and can be a make-or-break factor in new markets. Legal considerations can vary widely between countries. For instance, the General Data Protection Regulation (GDPR) in Europe imposes strict rules on how companies collect and handle personal data. Failing to comply can result in hefty fines. Similarly, certain countries might have specific regulations regarding advertising, product claims, or even the types of content that can be displayed. Conduct thorough research or consult with legal experts to ensure you’re fully compliant with all relevant laws. 6. Take a look at the competition What are your competitors doing? If they're successfully localized and you're not, you could be missing out on a significant market share. On the flip side, if they’re not localizing, it might indicate that the market potential doesn’t justify the investment—at least for now. Yes, it could also indicate you're onto a massively unexplored market - data and research can tell you which one it is. Conduct a SWOT analysis (Strengths, Weaknesses, Opportunities, Threats) to evaluate your competitive position and determine whether localization is a strategic move. Either way, remember that just because everyone else is jumping off a bridge... Well, you know the rest. Check before you jump off the bridge. 7. Think about efforts that'll serve your long-term vision Will localization support your long-term business goals? It takes a while to put down roots in a new market, so don't come into this expecting immediate gains. If your vision includes international growth, start laying the groundwork for localization now. That might mean building the infrastructure, hiring localization specialists, investing in tools, or starting to build relationships in target markets. Remember: If you’re planning to expand into multiple markets, it’s important to establish a robust localization process that can be replicated and scaled. For this to really work long-term, you'll need to set up a dedicated localization team, invest in localization management software, develop a style guide and glossary to ensure consistency across all languages, and much more. Go into this process with your eyes open to increase your chances of success. Final Thoughts ✨ So, is it better not to localize? It depends! (My favorite answer). The decision should be driven by data, resources, and a clear understanding of your goals. It won't be as fun as just going with the flow, but it'll be much more robust. If you choose to go forward, start small. Learn from your experiences, and gradually expand your efforts as you gain more insights and resources. And remember, sometimes the smartest move is to wait until you’re truly ready to make a meaningful impact in a new market. Good luck!
- Four UX localization predictions for 2024
As we approach 2024, the landscape of localization is going through a fascinating transformation. The industry is buzzing with anticipation and a bit of uncertainty, as technological advancements promise to change everything we know about our work. Everyone, from seasoned professionals to newcomers, is trying to find their place. For UX localization, we believe this change brings exciting opportunities. Here are four predictions on the changes we’re looking at in the upcoming year. 1. Localization is going to move further in-house In 2024, we're going to see a significant shift in how product companies approach localization. The trend is clear: more and more companies are bringing their localization efforts in-house. By hiring in-house localization managers, companies are taking the reins of their app and software localization workflows. This approach allows for a seamless integration of localization into the product development cycle, so that users get a more cohesive and consistent experience. And when the content pile gets high enough, companies are also starting to recruit in-house translators. They’re building a dedicated team that deeply understands the company's voice and mission. But why this sudden urge to keep everything under one roof? The answer is control and quality. Having an in-house team means companies can closely monitor and guide the localization process, ensuring that every piece of content aligns perfectly with their brand voice and values. This level of control extends to collaboration as well. In-house teams can work hand-in-hand with other departments – be it marketing, product development, or customer support – creating a synergy that's hard to achieve with external partners. This collaboration isn't just about meetings and emails; it's about creating a shared vision and understanding that impacts every aspect of the product. Going in-house does take its toll on the company, as people do need to work harder and more to facilitate that collaboration. But thankfully, technology is continuously evolving as well (more on that in a bit). Companies will leverage those localization tools to ramp up productivity: Translation management systems, automated workflow management, AI-driven quality assurance, and platforms for remote collaboration. These tools are essential in compensating for the time and resources invested in building an in-house team. 2. Machine translation will finally reach UX Machine translation is already deeply embedded in localization workflows – there’s nothing new here. But up until now, MT wasn’t considered good enough for UX content. The technology wasn’t designed for short-form content, the outputs weren’t good enough, and the risk was simply too high. The accuracy of content in an experience is critical, since there’s limited additional context readers can use to find their way in case of errors or mistakes. In the upcoming year, companies will gradually give MT a chance, even in UX localization. They may need to experiment with different forms of AI-based translation, from neural machine translation (NMT) to large language models (LLMs), to some hybrid solutions. New models released in 2024 will offer improved output, better prompting capabilities and enhanced tuning features that’ll make AI-based UX localization a real possibility. What’s going to be a real game-changer, however, is the evolving capability of these models to incorporate visual context into their prompts. LLMs that can consider screenshots, layouts, and design elements of a user interface will provide more accurate outputs in AI-based workflows. This advancement is crucial in UX localization, where the placement of text, the flow of a user journey, and the overall layout can significantly impact the content. It's a leap from seeing translation as a purely linguistic task to understanding it as an integral part of design and user engagement. But don’t worry: this shift towards MT doesn't mean the end for human translators. 3. Humans will be in the loop, but their role will change Incorporating AI into UX localization workflows will mean companies can leverage the strengths of both humans and machines. The traditional model, where human translators are manually moving content from one language to another, is going to evolve into one that’s more efficient. More importantly than that, it’ll also help companies deliver better international experiences. In the upcoming year we’ll see machine translation being used for the initial, manual translation step, and human experts step in later, particularly during the linguistic quality assurance (LQA) stage. This shift is more than just a change in sequence; it's a strategic realignment of resources. By allowing MT to handle the initial translation, companies can process large volumes of content rapidly, meeting the demands of today's fast-paced digital world. However, this won’t diminish the role of human translators. They will become quality guardians and cultural consultants, adding value through their nuanced understanding of language and culture. The shift will focus their skills and expertise where they are most needed – in ensuring relevance and enhancing the experience for their target audience. The emphasis on in-context LQA is a game-changer in this new workflow. Traditionally, translators and reviewers worked with text in isolation, often detached from the actual user interface or product experience. But as we move into 2024, seeing the translated content in its intended context will slowly become the norm. This approach allows translators to understand how the text interacts with design elements, how it fits within the overall user experience, and how cultural nuances play out in the actual product environment. This in-context review is not just about catching errors; it's about fine-tuning the language to resonate with users, ensuring that every button, menu, and state feels natural and intuitive. Human translators, focusing on the LQA stage, can work more effectively, as they are dealing with content that has already been processed and structured by MT. This synergy between machine efficiency and human insight leads to a more streamlined, agile localization process. 4. Translation and design teams will have better relationships The final pivotal shift we foresee is in the dynamics between translators, localization facilitators, and design teams — moving towards a much tighter, more integrated collaboration. Gradually, teams will establish deep, ongoing communication channels that allow for better flow of ideas and feedback. Product teams are beginning to recognize the immense value that localizers bring to the table, not just as language experts but as key contributors to the overall user experience. This enhanced collaboration means localizers are allowed in earlier in the development process, offering insights that can shape the product from a localization perspective. With translators having a clearer understanding of the product's objectives, audience, and context, their translations can go beyond mere linguistic accuracy. They are able to create helpful, valuable content that resonate with users in different markets. This level of detail and customization can only be achieved through a robust exchange of information and a deep understanding of the product and its users. Companies are investing more in this area, recognizing that effective communication between translators and product teams is not an overhead but a critical investment. The focus shifts from merely translating content to creating an immersive and relatable user experience for each market. This evolving relationship signifies a new era of respect and recognition for the role linguists have in the product development lifecycle. On the linguist side, this requires a commitment to continuous learning and adaptation. Translators will be expected to stay up-to-date of industry trends, technological advancements, and evolving user preferences. In turn, product teams will also be expected to provide translators with the resources and insights needed to understand the product comprehensively. This mutual respect and investment in knowledge-sharing lead to a more informed, nuanced, and effective localization process. Heading into the new year Even with the tech powering forward and industry evolving at breakneck speed, there's still plenty of space for localizers. The key? Stay curious, keep evolving, and keep bringing value to the table. This will be the best way to secure your spot in localization in the upcoming year.
- Optimizing localization processes with Willian Magalhães from Quandoo
The first episode of the Localization Process pod! In every episode, we'll be learning from one guest about the way they do localization for digital products. Our very first guest is Willian Magallian, Senior Content Designer and UX Writer at Quandoo. We'll be hearing all about Quandoo's unique process and the journey to make localization better, constantly. Audio Text-based video About Willian Magalhães Willian Magalhães has been working with UX Writing since 2017. Currently, he is a Senior Content Designer at Quandoo. Brazilian, based in Berlin, Germany, Willian is passionate about UX Writing and uses language to execute business strategy. Prior to working as a UX Writer, Willian taught English as a Foreign Language for over 10 years. He holds a bachelor’s in English Linguistics and in Systems and Analysis Development. He’s also been a UX Writing teacher since 2021, having taught in universities and in UX Design Schools in Brazil. Enjoyed the Localization Process Pod? Subscribe here, on LinkedIn, or on the Localization Station website to get notified about the next ones. Transcript Michal: Hi there, I'm so glad to have you here for the very first episode of the Loc Process pod, a podcast dedicated to the localization process for UX and digital products. We're going to be learning from the wisdom and experience of others to optimize our own processes and produce better experiences. In this podcast we'll talk with product leads, UX writers, product designers and more to learn what they do to create incredible localized experiences. Learning from each other can help us create better industry standards, and better localization processes for digital products worldwide. Today I will be talking with Willian Magalhães, Senior Content Designer and UX writer at Quandoo. Willian came to Quandoo as a content designer but also helped recreate and redesign their loc processes to streamline, scale, and bring better experiences to audiences in other countries. We'll hear all about it from Willian today. So, Willian, thank you so much for being here! I would love to know if I'm pronouncing your name correctly. Is it... willian Magalhães? Willian: Yes.. Willian Magalhães. Yes. Very nice! Michal: I actually looked it up before. I'm just really used to people mispronouncing names, I guess, so I had to look it up myself first. So, welcome, Willian Magalhães. We are here to basically discuss how you have built your localization process at your company, at Quandoo. And you've mentioned that you're now localizing into eight languages. Is that correct? Willian: Yes. Michal: That is amazing. So I would really like to hear from you first before we kind of start digging into, I guess, the meatier part of the interview, about the processes themselves. I would love to hear from you what kind of background you brought into this role and kind of where you came from into it. Willian: All right. Thank you so much. So let me tell you a little bit about me. I have a degree. I started my degree in English linguistics And then I taught English for 10 years in Brazilia. I'm from Brazil. And then, after 10 years in the classroom, I was thinking, it's time for me to do something that I also love, which is technology. I didn't know what to do exactly. I just like thought: I should get into a... I don't know, a university course or something to give me some guidance so I could find out what it is in the market I can do. So I started this university degree again, the second one. In analysis and systems development. In my first semester, I was lucky enough to get an internship at IBM. And inside IBM I discovered Watson. I started working with IBM Watson, like building chatbots and working as a conversational designer, UX writer, since then, that was in 2017. And then after my internship, I started being contacted by companies. Hey, could you come and help us with our chatbots and conversational design. So this is where my foundation is, UX writing for chatbots since 2017. And then, two years ago I joined a global company called Cinch. And I was able to start working with international teams. Because we had people from all over the place, and because I can speak English, and people in my team couldn't, I was the one reaching out to them, like getting information, bringing information to my team. So the interest of having these connections with international teams was born there. And then, after Cinch, I was invited to come to Quandoo here in Berlin. I'm based in Berlin now. And the main objective, the main goal of coming to Quandoo was to help the company with localization because we had sort of a process, but it wasn't something documented. It wasn't something that followed a flow. It was something that was like, let's create a ticket, and let's follow this ticket until it's done. So when I first came here, I tried to understand the resources that we had, the languages that we localized, and which kind of markets we were localizing to. It took some time. For example, in 20 days, it's gonna be a year that I'm here, but it took around seven months for me to really start doing something about localization. I believe the first six months, of course, onboarding and learning the product and understanding users', data, users' behaviors, all of this counted. So recently I've finished the localization process here in Quandoo. It's a mix of having localization specialists as externals helping us in this flow, and also counting on some local employees from Quandoo to also help us out in this process, because we have people from 52 nationalities in the company. Michal: Oh, wow. Willian: Yes. We're People all over the place so we can, you know, rely on these people to also help us. I know they're not localization specialists, but it's better than me, that I don't know the local customs of that place or languages. For me, I cannot tell if that sounds weird or not. Michal: Yeah. Okay, so let's start with like the beginning, cuz you said you came on to Quandoo, and you did already localize at the company, but you didn't really have a set process. Anything documented . And so I'm curious to know how that went. Before you even started streamlining and improving and optimizing. Willian: All right. So the original process was like, we had this LSP, this language service provider here in Quandoo we use Crowdin. Michal: Mm-hmm. Willian: And we also had Google spreadsheets and we were translating the content in a spreadsheet. And the content that was translated in a spreadsheet was then by a UX writer inputted in Crowdin. And this was the process, I think people created a spreadsheet and asked, can you translate this? And then after it translated, you would be able to go to Crowdin, find the keys, and then update the strings with the translations that you got. Michal: Mm-hmm. Willian: And then sometimes we were requesting translations from from a provider and sometimes we were asking directly people to translate them. So there wasn't like a rule, like, for this, we should follow this path. And for the other thing, we should follow the other path. There wasn't clarity in this process. So what I did, I was like, okay, so let's understand first what kind of content comes to us so we can translate. So it's a small, like, content audit. Is it a paragraph? Is it an article? is it a UI text? Where are we gonna use this content? And then, is it a marketing campaign? Is it a product thing? So this small audit is done now because, depending on how big the text is, it's very expensive for us to keep requesting them from translation providers, you know, so depending on the amount of words we have this flow. We may get in contact with them earlier to be translated because it's a very big thing, like an article or a page or something, a tutorial. Or if it's a UI copy text or something, we ask them, just review what we got from a translation service. Michal: Right. So basically what you did was you kind of started categorizing the types of content that you have, right? So that you can find a process that is more optimized for each kind of content. Is that what you did? Willian: Exactly. Michal: Yeah. Willian: And not only that, but we eliminated the spreadsheet step. Because I gave power to the translators to work directly inside our LSP. Michal: Mm-hmm. Willian: So I gave them the role, as translators, inside Crowdin, and they're free enough to go there, edit, change, save, update, vote, whatever they feel about the copy, they can do. It's like I made it scalable. I scaled this process, because I believe that the success of this process is getting me out of it. Like as long as it flows without me, I'm good. And that's the core thing for UX that I believe in here. Like, scaling people to do your work without having to call you because they can't do it. You may be like the consultant, that signs off. This is good. Nice. Like, I mean, I will, you know, do something, of course. But for example, empowering people to write, which is my role here, UX writer. Empowering people to write, empowering people to start talking about localization in their teams. And I am having this already. I presented the localization topic here. I actually had two presentations in the company. The first presentation I delivered was a very educational one, like talking about the topic. What is it? What can we do? What are the impact? Let's see some examples of wrong localization and right localization, because if we have the intention to go global, we should be worried about global content as well. Michal: Yeah Willian: So the first meeting was an educational presentation for the company, for POs, PMs, developers, designers, and everybody else. The second meeting was technical. The second meeting was like, okay, so let me present you Crowdin. Let me present you the scheme of the flow. Let me present to you, like, when you can get in touch with me. Let me present to you what we can do in our teams. So after these meetings, I got people from other teams getting in contact with me saying, hey, let's localize our website. I mean the homepage for this region. For example, we are in Hong Kong, we are in italy, and they're very different markets, but we use the same image for all of them. So they started like, hey what if we change the picture here to reflect more of that market? And then I was like, yeah, that's localization. That's what we're supposed to do. How can I help you? So. I think I've planted the seed and it's growing slowly, but it is. People are actually reaching out and saying, hey that's really nice. How can I do it here? So let's talk, let's have a meeting. So this is the outcome that I expected. Michal: So you became like the localization advocate, right, at Quandoo? Willian: Yeah. Michal: Were you the only localization advocate, did they have other people handling localization as a managerial role? Willian: I don't think so. I don't think so. I believe this localization task was spread among employees. Like for example, when I go to Crowdin and I see the history of translations, I see names from people that were once product managers, and I see people who were content designers and I see people who were product owners, so I believe there wasn't this responsibility of the area given to a person, so this person could, you know, organize and manage who will actually review the translations, who will actually do the translations, where we gonna get the translations from. So, yeah. I believe it wasn't given to a person to manage this area. Michal: Do you feel that having a localization owner transformed not just the processes, but also the results that you got? Willian: I believe so because we are getting outputs on this. It's too soon to get some data because we have just implemented the process. But we need to talk like designers now. How to measure – and if we can measure – like how can you measure user satisfaction on seeing an image that reflects to their culture? We know we are in the right track, but I mean, we still have to sit down and say, hey, okay, we're localizing. So what? So what are we gonna do with it? I think this is really important and it's a very strategic conversation we should have. And then after we have this conversation, I think we're gonna have more material to keep on, advocating for the discipline. Michal: So now I wanna start talking about the process itself. So basically, at what point do localizers come into the picture? Do they get, do you consult with them earlier on before you really start actually creating content in the first language? Or do they only come into the picture at a later point? Willian: Okay, so the first thing that we request in this localization process is, whatever yOu want to be translated or localized, we need the strings. We don't work with Slack strings anymore. We don't work with Google Sheets anymore. We don't work with this. We need to have this in a place that we have control. So Crowdin is the place for us. If you want us to translate something for you, what you have to do is to create a ticket on our Jira board. We have a localization board now. And we have some instructions on how to create this ticket. Create a ticket, put the Crowdin links, give us some context, give us some deadline, and we will then move forward with this. So, When they create this ticket and they put the strings, I see what languages they're requesting. And then I see the context and I try to help the localization specialists. Because they're not in the teams. These people, they're like consultants. But they're not in the teams, so they don't know what we are doing. The product we are working on, the feature we are working on, so they need to be contextualized. After I try to contextualize for them, I request translations from the translation service that we use here in Quandoo. And then this ticket moves to translations from this service going on. As soon as it's done, we go to the second part. Actually, the third part, which is localization specialists will sign off this content, so I let them know that they should go in Crowdin, see the translations we've got and sign them off or change or adapt or see what we can do. So once they're done with it, then we are able to do quality assurance of this content. So we build whatever we are testing, we go into test environment. We see how it looks. And then we send it to production according if it's right or wrong. Michal: So basically you do design, it goes to development, and then the people who create the keys are developers, at that stage, at the development stage. Willian: Exactly. Design designs. I write the copies in the design. After the copy, and that part of the process is done, front end developers build the strings on our LSP. As soon as the strings are created in our LSP, they come back to us for localization. Michal: So let's say, basically you do the design, you do the writing, you send it to development, it goes to localization, and then the localizer comes back to you and says, oh, I'm sorry, but I need more than one line for the title, or my language is longer so it doesn't fit, or something like that. You need to make any adjustment to the design. So what do you do when that happens? Willian: Okay. So in this training that I gave, the educational training about localization, I talked about internationalization. Which is pretty much this, and internationalization is under my responsibility because I am the one creating the copy in the first place. Michal: Yeah. Willian: So I'm the one who has to keep this in mind. I should understand that when we translate, for example, from English to German, German is going to be smaller, because in English, we separate the words more. In German we tend to get all the nouns and make them compound nouns. So they are usually smaller. However, when I translate, for example, from German to Chinese, I know that Chinese is gonna be even smaller. So these moves that can happen inside the ui, I have to have them in my mind. So as I'm the one creating the copy, I'm pretty much preparing for how it could be when we get bigger or shorter strings. We don't do very long CTAs in our product. Usually our buttons are safe because of the internationalization techniques. But the others are just paragraphs and titles and they can grow because... yeah. Michal: Yeah, absolutely. Flexible layout can definitely make this easier. What kind of response did you get when you started creating and outlining everything? You obviously maybe stepped on some toes, I'm guessing people had a way of working and they were used to it, and now you are starting to change things for them. So what kind of response did you get? How did they react? Willian: They liked. Michal: Yeah? Willian: They liked, because in the past they were translating. Localization specialists, they were translating. Now they're signing off what has been already translated, so it's less work for them. So they liked because It's less work, it's faster. So for them it was, I believe it was good. And for POs as well. It's easier to find a string in Crowdin than find a spreadsheet in a drive that belongs to some person. So having this content all in one place is also good for organization. And for example, in a case that an employee leaves, that spreadsheet is going to be deleted. With his or her account. But when you're talking about LSP, everything's gonna be there. Michal: All right, so now you are maintaining your source of truth on Figma, right? And then, Willian: Yeah, for some designs that we create, yes. And for some other things that we don't have in Figma, Crowdin is a source of truth. So Michal: how do you keep things from getting confusing? Like if I update something in Crowden and then something changes on Figma and then they're kind of not in sync now, how do you keep them from being mixed up? Willian: As we are a very small team, and I'm the only content designer for B2C, changes for strings usually go through me. We like design systems updated. We don't have this, many changes in our buttons or anything. When we have something that's going to affect the whole product we very well aware of what's happening. So for example, we recently changed our main CTA, from "reserve" to "book". When changes that big, we are usually aware and we update in Figma, Crowdin. So it's okay. And we have the history in Crowdin, so it's okay. Michal: I'm curious to know, you said you were doing design, you're doing development, and then you're taking everything to a test environment and you have it sent to the localizers again for review. So how does that go? The quality assurance process? Willian: Okay. Quality assurance process is pretty much done by QA people here. And we don't check the content again. We only check for bugs or visual bugs. Okay. For example, we translate it in our LSP, we localize in our LSP. QA understands that and sees that, hey, this is not good visually. What's wrong? It's not like in the design. So probably QA will compare this test environment with our Figma file, which is the source of truth. And then if necessary, we can contact the localization or design and then we can use any workarounds to, to fix that. Michal: So you have all these processes basically set out now. How do you plan to proceed? You have everything outlined, you have your documentation. What's the next step for you? How are you going to kind of further optimize this? Willian: Yeah, so to be very honest, we need to clean our LSP, because it's pretty much full of sentences we don't use. And sentences that are reused. Because of this the localization specialist get lost. Like, what should I actually translate and verify? What was created in the first place? Or what the translation is saying? Yeah, so this is like the thing right now. So maybe cleaning the LSP right now, so we can have a better environment for localization specialists to work for. But in relation to the content that is being created, I think it's pretty much working well. This process has been working well. And something that I learned in my career is that, I helped create the design process here in Quandoo, and I've created the localization process. And what helps the most is create a process from scratch. Don't bring this shelf processes to your company. Because you may not have the resources, you may not be able to follow this specific step in that process and then it's gonna be a mess if you try just to apply this shelf process that you get from whatever person created or whatever company created. So what's been working for us is like, we just sat down and we said, what do we have? How can you do it, you know, in a quick way? Because usually, we have deadlines. Strings are done, they need to be translated as soon as fast because they need to go live. So I don't have much time to keep, like, I brainstorming with our localization specialists, like, what should we do here? I'm so sorry. They have to look and sign off. Michal: I'm really curious to know though, you just did this, so maybe you don't have data yet, but if you make a change, like going from "reserve" to "book" or from "book" to "reserve", do you always make that change throughout, across all languages? Or do you check that maybe some languages will be better off with " book" or do some languages even don't have "book" or "reserve", they have another version of the copy that is unique to that language. And if so, do you keep that or do you change it as well? Willian: Then we involve the localization specialist and we explain the reasoning. And this change is based on user research. And we present this data to localization specialist and say, okay, how can we say this in your language? In the language that you master. This old word has this result and this new word had a better result. So based on the word that had a better result, how can we change in your language, a word that represents this. Michal: Right. So better result, that's in English. So do you do further testing on other languages after you implement the change? Willian: We're not AB testing localization yet. It's a plan. Michal: That's why I asked about optimization. Because I think there is always more that we can learn and always more that we can improve or optimize in our processes. There is so much that we need to take into account when we plan these processes. I think that there's always room for improvement. Willian: We just implemented this process. It's a baby. And iterating this process and getting data on this process. Like how can we test, how can we measure, what can we do now after we implemented the process? Now that we have a process. This is something that we are still thinking you know, understanding. Michal: Yeah, definitely. So one last question before we go. You said today that you were manually writing the copy, then you're manually localizing it. So have you considered using any of the machine translation, AI tools, Gen-AI, to kind of streamline your process and make it faster or more efficient? Willian: In Crowdin I believe we have some MTs, in crowding already. And we make use of a lot of translation memory, but AI is still a, a thing that we're discussing. Michal: Right. This is like, my... kind of "foot out the door" question. Because, it's a big question. Everyone are... kind of discussing the same thing now, right? And it's out there, and you want to use it, but... you're not really sure how to, and you're not really sure how to implement it, and if it's good in any way. Because if it's not a good fit, then you can do some damage to the process. So it's definitely something that should be approached with caution. But also, I think it's really fascinating to see where it's going to lead everybody. Is there anything else that you want to say or discussed that we haven't discussed? Because I'd love to hear it too. Willian: Uh, I mean, Congratulations on putting together that Slack group. It helped us as professionals to give maturity to the discipline. And I believe it's a topic that has been getting attention lately. Which is really nice because I'm in love with hands-on. So I love creating tutorials, showing how to do stuff and your Slack channel, it'll definitely help me improve and become a better localization specialist here in Quandoo. Michal: Yeah, that's amazing. It's actually the reason I created this. Because in UX... You're in UX as well, so you know that this community is so good about knowledge sharing, it's so good about bringing people together to kind of share how they do things, and how they set everything up. And they try things and experiment with things and test a lot, and I think that this is a vibe that we should get - and we are getting gradually - in localization. It's definitely something that is going to improve the results, processes, the quality of everything. And I guess, the quality of the experience at the end. So it's definitely worth it. And for me, that was the main goal for creating that community. But it does depend on people, also, including their own knowledge and sharing their own knowledge and kind of being part of it. And every time someone posts I'm getting really excited to see what they wrote. Willian: Let's share knowledge and let's help people out there with whatever they're facing or, you know, any challenges they're facing, let's help them. Michal: Yeah. This was really, really fascinating. Thank you so much for sharing and thank you so much for being here, for taking the time. I'm actually really, really curious to know where you are going to be in a year from now and where your localization process is going to take you. So hopefully maybe we'll do like a follow up and I'm just going to meet with you again in a year and see how things are going. Willian: Awesome. Thank you so much Michal. Michal: Bye bye. Willian: Bye. Michal: To everyone listening, if you enjoyed this podcast, if you want to learn more about localization processes and keep up with the next episodes of the Loc Process Pod, make sure you follow Localization Station on LinkedIn or sign up to our email newsletter so I can let you know when a new episode is ready and if you have any feedback, if you have any questions that you would like answered, if there are specific people that you would like to learn about processes from, do let me know. Send me an email. Send me a message. I would love to hear from you. Thank you so much for taking the time to listen to the lock process pod today. And I hope you have a great day.
- Localization at scale with Adi Meller from Wix
Localization at scale is significantly different than localization at a small company – for better or for worse. The challenges that come from maintaining over 17 languages and several different sections are mitigated by more localization colleagues, and access to better documentation and resources. In this episode, Adi Meller, Localization Operations Manager at Wix, will tell us all about how it's done. Audio Text video About Adi Meller Adi is an experienced Localization operation manager and translator on a mission to make the world of knowledge more accessible with localization. She's been working in the localization field for the past 6 years and gained knowledge and experience as an operations and project manager, vendor manager, and translator for a vast range of fields. Enjoyed the Localization Process Pod? In every episode, we'll be learning from one guest about the way they do localization for digital products. Subscribe here, on LinkedIn, or on the Localization Station website to get notified about the next ones. Transcript Michal: Hi everyone, and welcome to a new episode of the Localization Process Pod, the podcast where we break apart localization processes from companies all over the world to learn what goes well, what goes wrong, and how we can make it better. Today, we'll be learning about a little company that maybe you know, it's called Wix, and I have with me Adi Meller, who is the Localization Operations Manager at Wix. Adi, it's really great to have you here. I have to say, I'm personally really excited about this specific session, hearing how localization is done at Wix, both because this is a company that I've been watching from the first moment that they created their product and seeing them going global and seeing them becoming so big and advanced is really exciting for me. And I would love to hear how it's done and how, I guess, the cake gets made. So thank you for being here. Adi: And also, you have a special connection to Wix. Michal: And I also have a special connection. Yeah, full disclosure, my sister is a UX writer at Wix. But that's not why I'm excited about localization because she does UX writing in English and she's not a translator. No, but I also, I use Wix myself. I have Localization Station. The website is on Wix. And so it's actually a product that I've been using daily. Which is exciting. Also it's an Israeli company, which is always exciting for me. Okay. So, you work at Wix. What exactly is your title? What do you do at Wix? Adi: I'm a localization operations manager, which means I'm responsible for translating and localizing parts of the platform into 21 languages. Some parts get translated to more than 30. Luckily for me, it's just 21. I'm in charge of the CRM, the automations and the OS parts. My day to day job is receiving translation tasks about new features, new products, text changes, AB tests and just getting them translated into 21 languages and also QA-ing these translations to see the flow is clear, there are no bugs, no design issues. I don't know if it sounds easy. It's not easy. From one side I'm working with the product team, I'm working with PMs, I'm working with product managers, I'm working with the developers and I'm working with the UX writers. Thank you And on the other hand, I'm working with the translators and languages. So I'm basically in charge of getting this flowing into each direction. And because we're translating to 21 languages, bugs are bound to show up, you know? At least once in every flow. So yeah, that's up to us, the localization managers to handle and address. Michal: Oh, wow. So you said, "I know this sounds easy", but it sounds really hard. It doesn't sound easy at all. How many localization managers do you have? Adi: Well, it depends because in our team, the localization team, we're about... 12, 13, I think. And there's also the localization team for marketing, which is different from us. But my team is responsible for translating most of the platform. We have in-house writers, we have freelance writers. Everything is done in Smartling and Monday and Google Sheets. Basically everything is on the cloud. Michal: How did you get to this role in the first place? Were you a translator before? How did you get to localization? Adi: At the beginning I was a content writer and editor and manager. But I always like to translate because I take pride in my reasonable English. At some point I realized I'm using a lot of English and translating in my day-to-day job. So about four years ago, I decided after I quit a horrible job as a content editor. I decided to go into localization, I took a Google online course, and they had a chapter in localization and it was like Eureka, that's it! I was looking for a new direction and there it was. And it was so reasonable to me because I used to translate on my former jobs. And also I did a little research and I discovered that in Israel, it's not a very big niche. So for me, it was really great because I wanted to be a leader in this area. And my dream was always to teach. So I said like, yeah, let's do this. Let's learn a new profession. Let's work. And maybe one day I can teach and pass this knowledge on. Michal: So you got from content editing, from marketing basically, UX into localization. Adi: Yeah. After the course, I had a small business and I started to take translation jobs. A year after I did the course COVID struck and I was able to take a lot of freelance jobs. And I was the translator and project manager for a big streaming company, I don't know if I can say the name, but it rhymes with Felix, so you can guess. So I did this role for two years, I had a lot of fun, and I also did translation jobs for Nespresso and for PlayStation and for Airbnb and for Google, so I translated in a lot of different areas. And after two years I saw that Wix is looking for a localization manager and thought " this is the next step in my career". And here I am! Two years later. Michal: It's funny because I feel like a lot of translators, this is kind of how they got to UX. And it's also, it's the same for me. I did translation, just general translation, and then gradually you'd get more and more, I'm guessing, UX, UI, localization, tasks, just because there was more content in that area. And you'd end up saying, oh, this is something that I'm really interested in, right? And it feels like something I want to do more of. This is, for me, this is how I discovered UX writing, and then I started doing UX writing as well. Because I said, Oh, I have the experience from translation and I've been actually doing this for a few years. So I should also be writing. And then I started learning about UX writing and that's... everything I'm doing now. I feel it's a story that a lot of people have. They kind of accidentally land into this. Like you said, a Eureka moment. So it is interesting. I'd love to keep talking about this, but I do want to dive into the process just because feel that specifically for Wix, you have a lot of valuable information to share. And so, tell me how the process looks like on the day to day. You get a task for translation, who do you get it from? Adi: I usually get it from the developers or from the UX writer I work with. I get it by Jira tickets or I get a Monday board or I get it by Slack. It really Depends on like the relationship I have with the UX writer. But I'm super available in each channel. They always know to deliver the key list and also if they have a link for Figma, which is where I see the full flow and what I should recreate. Because eventually I don't just send everything to translation. I also have to understand the flow in order to recreate it in the localization QA. So it's really important. I also get a feature toggle, because a lot of new features are closed to users and only employees can see them. And it changes from UX Writer to UX Writer. some of them tag the keys in Smartling and they just send me tag name. And some of them just send me key list and everything's cool. But it's really important to always have context. That's why I really need Figma, and that's why I always try to recreate the flow before I send everything to translation. It helps me understand the flow, and if the writers, the translators, have any questions, I know how to answer. And also, I can spot localization red flags, before I even send a translation. Like, for instance there's a very long text with limited space. I can say in advance, listen, in long languages like Russian, German, French, this space is not going to be enough. It's going to be cut in the middle or maybe we need an ICU format. If there's a difference between the masculine and the feminine language. So I always try to make the text as dynamic as possible. So the translators have as much freedom in translating. Also if I see date and time formats, I talk to the developers, to enter a certain code that will make the date and time localization friendly. So people in Japan will see the date format they're used to read. And that's it, like, once everything is ready, I send the translation task. The ETA is between three days and a week, it depends how long the task is, and once everything is ready, I do a pre-QA myself. I check the flow in like, two or three languages to see everything was translated, there are no texts left in English. And once I see everything is done I can send the localization QA doc. It takes about... between three days and a week also. And once the QA is done, I can approve to expand the feature into languages. This is the ideal case. If it's like a small feature or a text change, it takes about two weeks, but new features or new flows, they're super complex. It can take up to a month. It can take even more than that. If like new text keeps getting added. So some tasks are time-limited but some of them are ongoing. Michal: So you get the task from the developer and then you check everything you have to check, then you send it to translators. So are those translators freelancers, are those in-house? A combination? Adi: Most of them are in-house. We have a lot of in-house translators sitting with us in Israel, and some of them are working abroad. And some of them are freelancers. It really depends on the language, like the scope of the language. A lot of times there are more than one translator to each language. There are language leads which are responsible for the glossary, termbases, so on. Yeah. So there are translators, freelance, in-house. Michal: And when you localize a feature, is it already live in English usually? Or is the launch in all languages at once? Adi: It really depends on the product. It really depends on the team. It really depends on like the KPIs they want to achieve. It's different between each team and each product. Sometimes I get a localized flow or feature or product which is already open to English and they say like, no pressure, take your time. We'll expand to languages once it's ready. And there are times when the deadline is urgent and they want to open everything all at once. We had a big launch last month of a new product at Wix. Michal: Wix studio. Adi: Woohoo! So the whole localization team worked together to get everything done because they wanted to open everything all at once. So it's really different from product to product, from team to team. But... it's never boring. Michal: Yeah, definitely never boring. So you mentioned context, which I feel... I agree is a critical issue. Adi: Yeah. Michal: How do you provide that context? Because you get a figma file. Do your translators also get a link to that figma? Or does Smartling sync with figma? How does it work? Adi: What I do, I just add, or the UX writer adds, screenshots to each string, to each key. Michal: I'm curious why? Because I know Smartling does have it in-context translation feature. I'm not sure how exactly it works, but they do have a feature that you can translate in-context. So you see the interface and you type and you see the translation populated into the interface. So why do you prefer using screenshots and not in-context? Does it take time to set up? Adi: I feel like the translators already have a lot on their heads. So I don't want to send them locating each text in the Figma. I think it's... My job to do that. And also, a lot of time I recreate the flow even before I send it to localization. I recreate the flow, I trigger a lot of texts, so I just take screenshots myself, and I already prepare, first hand, the QA doc. I trigger the whole flow, I prepare the QA doc, I learn the flow, take screenshots, and the translators can see exactly what they are going to translate, where is it located in the product itself, how much space do they have. And that way they know if they have to keep it short or they can translate it however they feel like it. Michal: Are features usually already developed once they go into localization? Adi: Yeah. Michal: So you already have like a live test environment with the feature in it? Adi: 95% of the times, yeah. The feature is already live but to employees only. And we need to use a feature toggle. It exists somewhere. Michal: Does it happen that you send something to localization, then you get comments that mean that you have to go back to development and fix things or change things? Adi: I usually try to find them myself beforehand. It doesn't happen a lot of time. Because the features get so many eyes testing them and looking for bugs and doing bug hunts and doing QA beforehand. And... content QA. Localization usually comes last. We're the last QA because we only get it after the content is done. And because the content is like almost the final stage, we already get everything when everything is almost ready. So it doesn't happen a lot. There are mostly like issues with texts that appear in English or for some reason, I don't know, I see old texts and I don't know why. It's usually UX issues and not product issues. Michal: Yeah. But you don't have UX issues that are kind of specific to those markets that you localize into? Like maybe a French linguist says, "Oh, for France, this is not going to work" for some reason... Adi: Yeah, sometimes there are comments on the content. Yeah, for sure. Each and every language has their own set of rules, their own grammar. We also expect our translators and writers to flag things that they think is not going to work. That's why I always request the developers create dynamic keys. Then the translators can play with the order and with the format. But yeah, it happens sometimes. For instance today the Portuguese language lead asked me if we can ask the developer to create a new key because the existing key refers only to masculine format, and she needs to translate it in a feminine format. Which is like totally legitimate because you want to give the best UX possible. Michal: If you did localization before development, do you find that it maybe would have made a difference? In terms of how you address queries or feedback from your linguists? Adi: It's hard to say. very good to be involved in an early stage, like in the kickoff meetings. And this is something we always request our product teams to do, invite us to kickoff meetings and to weekly meetings so we can be in the loop and know exactly what's going to happen. And this way we get to know the new products and the new flows. And we can raise flags and say, " Think about localization before you develop it and allow the space to be dynamic and don't limit it in characters or in space. Allow dynamic keys. Think about the date and time formats. I feel the more we work with the product teams, the more they take localization into consideration. And it's really nice to see developers and product managers ask me questions before they send the product into development. Like, " can you tell me how many characters can we put in", etc. So yeah, it happens. Michal: Yeah. Okay. Um... Sorry, I lost my train of thought... it's August. Adi: Yeah. Michal: So you said we, "We come to the kickoff meetings". Do you mean "we" as in localization managers or "we" as linguists as well? Adi: Localization managers, because each of us is assigned to a different company – in Wix it's called company, like a department – and different products. And most of us localize for more than one company. So it's really important for us to be in the loop and know what's the workload that we're facing in the next few months. 99% of the times we can contribute. A lot of people that don't work with content day to day, like developers, they don't think about localization. And it's my job to say, " listen, this product is going to be 21 other languages. And it's almost half of our users. So we need to think about localization. Michal: Big question. You said that you are in charge of localization for the CRM. And for... Adi: And for automations and for the OS, which is the dashboard, menu and some other parts in the platform. Michal: And you do that and then there are other localization managers and they're in charge of the other pieces. So do you make sure that you keep everything consistent in the different sections of the product? Adi: Ah, not always... but It has a lot to do with how our predecessors used to work like five years ago, in... Smartling projects and so on. Sometimes it's very hard to differentiate and recognize which localization manager is handling which part of the platform. It's very confusing because Wix is a super big, super complex product. As time passes, each and every one is more familiar with the product but yeah, sometimes they get confused. Sometimes I get confused. And... Luckily I have my team to back me up. Michal: I would assume that if you have in house linguists, which is a big plus, the linguists themselves can maintain consistency in a way. Do you have more than one linguist for every language pair? Adi: Yeah, sometimes like in bigger languages like Spanish or Portuguese, for instance, or German, yeah. Their scope is big because some products only get translated into these specific languages. So yeah, they use several writers, translators. But each language has a language lead. So they do their best to be consistent. And each language is responsible for the QAs throughout the product and to change and to align the text . They're on it. They're on top of things. Michal: I noticed that sometimes you say linguists, sometimes you call them writers. How much freedom do you give them in terms of what content they create in their own language and how it looks? To create different content that kind of feels fluent and natural? Adi: T