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.

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.

"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! :)

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!

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.

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 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: They don't really involve me in their content choices or their UX choices because they have enough experience and they have enough knowledge and we trust them enough to make creative and smart decisions. We also expect them to make creative decisions. As long as all the texts are aligned, the user understands, let's go. But each and every language has a language lead. So I believe the writers always consult them before they make a very big change. Sometimes they also ask me and I'm super happy when they get creative and sometimes it's a necessity, because... if the choice is between getting creative with the content or asking a developer to change the key, I'll always go for the creative. Michal: So if they have questions, do they have access directly to the UX writers? Can they message them directly and kind of talk things over? Adi: Yeah. But I try to make flow as clear as possible before I send everything to translation. That's why I use context. That's why if I feel like something is not clear enough, I will always add instructions and explanations and if it's something super new and not clear, I will even do a kickoff meeting with the writers and explain the flow before the translation task, so they will get familiar with the flow. Before they start to translate . But on a day to day basis. Yeah, they can tag the UX writers and ask them questions like, can I translate it this way? Like if this translation will get the message of the original text. So yeah, it's nice. Michal: It's good that they have direct access too, because I feel a lot of the problems in localization come from not having that direct connection. And also, I really like that you have in-house translators because this emotional investment that you get from actually working at a company and being part of the company's success, it definitely leads to better content, better decisions. Just being more invested in the content that you create. And so I think it's probably a big part of why it's a success. Adi: Also, Wix is a big and complex platform. So I think it's good that writers are in-house. First of all, it's a very long onboarding. It takes a lot of time and a lot of effort. So we want to invest in the writers so they will create the best UX possible. Michal: Do you give them training on the company's brand, guidelines, and voice and tone and all of those aspects? Adi: Yes. Michal: Yeah. Adi: Yeah. Some of the writers are in charge of it. Michal: Amazing. How do you know if it's a good user experience in those languages? Do you test in all languages? Adi: Only after the product is live and running we can learn and analyze. Of course we really want to learn if the localization is successful by sitting with the data analyst and learning how many users are using the product in each language. What is the success rate? What's the failure rate? That's something I think that each and every localization manager has to know. Michal: I understand time is an issue, it's always an issue. But if you had infinite time, what kind of KPIs would you have looked at? Adi: I think clear message, clear instructions. And how efficient the UX is. If we see that the users continue from screen to screen, without stopping and without rereading and without asking for instructions, then it's a success. Michal: I'm wondering if it's possible to even create those tests to run automatically. It's going to take time at the beginning, but then you have that data always available. Adi: I had it a few months ago, with one of the teams I work with. I wanted to know if... a very big product I worked on, how is it doing? I wanted to hear some insights, to see what our users in Japan and in Germany think about it. And they didn't really have a lot of answers to give me. I think English is, will always be, the most important. Michal: Yeah, it's something that a lot of companies do, is they don't really test a localized product, they only test the source product. Which, again, I getthat time is an issue, and money is an issue, and obviously, you start by testing the source product, then you... Maybe if you have time and you have the capacity, you expand it to the localized product. But... I'm always curious to know how companies manage to justify this really significant investment in localization without actually having the data to justify the investment. You know what I mean? So it's kind of an interesting... Challenge, I guess. I don't know, or maybe companies do justify that, and they do run the data, but they don't want to share it, which is also okay. Okay, let's talk about the QA part 'cause we haven't really discussed that. Do you create kind of a script for people to go through the localized product? Adi: Yeah, we have a ready made template that we can use, and every one of us has a different method for creating the QA doc. I realized that you have to be as clear as possible. You have to write the QA doc as if you're explaining... not to ten year old, because a ten year old will probably know better than I do how to operate everything in Wix, but like... imagine you're explaining everything to your grandmother . You have to use clear words, choose as many screenshots as you possibly can... because you only have words and pictures and videos to explain yourself. And the QAs are very complex and they're very long. So you have to be as clear as possible. You have to write the instructions as if you're writing to someone who never used your product. That's the only way to make it as clear as possible. Some of the companies use Storybook, which is super helpful. Not all of the companies use it, unfortunately. Storybook Simulates real product. And you can change the language and you can test several scenarios and it's super easy to QA, but not all companies use it. So we have to make very long docs and guide the language leads through them. But that's the best way to discover bugs and issues. Michal: You say companies, so do you mean kind of like subsections within the product? Adi: Automations is is a company, Stores is a company. Michal: So different subsections . Adi: Yeah. Michal: Okay. And so you create the QA scenario, the script, and you send it to linguists and they find bugs. What do they do with the bugs? Adi: They flag them. They always write in the most clear way possible because I don't speak Japanese or Italian or whatnot. They always have to give me context, tell me exactly what the issue is. And also to explain as if they're talking to a grandma, which in this case I'm the grandma. And it's all about communication and explaining the needs. I also have to translate these flags to the developers. So if I don't understand what the issue is, I will never be able to explain it to a developer who has no idea about localization. Michal: How do they send it to you? What do they use? Adi: The QA doc. We have a special section where they can flag issues. And I discovered once you make the QA doc clear you explain everything, you have less issues. Building a QA doc can take from one hour to two weeks. It really depends on the product and how complex it is. But if you simplify the flow and if you make it as clear as possible, you will have less issues because you will also discover the issues beforehand and you will report them before you send the QA. So they will be fixed before you even sent the QA. Michal: And then they fix it. You have like a back and forth. And then it goes to production. Adi: Sometimes it takes a day, sometimes it can take a month. But they do their best. Once it's fixed, I test it, or if it's something I can't test because I don't speak the language, I will send it to the language lead, and if it's fixed, yay, we can implement the change, if it's not fixed. It goes back to the developer... Michal: Okay. My final question. If you had to give one tip to companies who are just starting to localize or trying to optimize their processes. What would that tip be? Adi: Ooh, wow. Do your research, learn your audience globally. Also Invest in human resource. There's a tendency to think about translators, yeah, yeah, you see content and you translate, la la la, la la la. And people don't understand how localization is very complex and demands a lot of resources. You have to know two languages, you have to know slang, you have to know the culture. You have to keep learning. You have to do your research and you have to think about the user all the time, but you also have to think about the company and the develop... Especially in big techie companies. It takes a lot of knowledge. So I think it's really important to invest in translators. To teach them. Give them a lot of resources. Invest in the onboarding. Yeah, because eventually localization is a gate to new markets , you know? To new users. I think localizing is like giving access to people who didn't have access before. There are a lot of places in the world where people don't use English content and they want to see everything translated in their own language. And if you give up on them, or if you don't translate it good enough, you lose them. Michal: Yeah, localization is accessibility in many ways, I completely agree. If you're a small business owner and you're able to create your website and go online and have more customers and even reach new markets, thanks to that product being localized, it has a huge impact on your quality of life. And, you know, financial security, and really critical things. Adi: Exactly. Like we saw it on COVID, people moved everything online and our localization department grew so much bigger during COVID, I was recruited during COVID. Michal: I love the we ended on this note on investing in your translators because I feel a lot of times companies get caught up on the technicalities of it. Like, how do you send your files? And, you know, I don't know, how do you calculate the budget, but they don't really focus on the people who are actually doing the work, the people who are actually creating the content, creating those experiences and investing in those people is definitely the biggest thing you can do for your content, for your localized product that's amazing. So thank you so much for giving us a glimpse into how Wix does their own UX localization. So thank you so much. Adi: For sure. Michal: For those who stuck around, give yourself a pat on the back for learning about one more way to do localization. I think localization at scale is significantly different than localization at a small company. For better or for worse, I guess. There are a lot of challenges that come from having 17 languages to localize into, and several different sections in your product. But you also enjoy the support of more localization colleagues, and access to better documentation and resources. So I'm not sure which one is better or easier, but I would actually love to know what you think. So come join the conversation on our UX Localization Slack community. There's a link to join on the Localization Station website and it's open to everybody. I really can't wait to see you there. If you want to get updates on new episodes from the Localization Process Pod, make sure that you subscribe on Spotify or YouTube, or the Localization Station email newsletter, and I promise to only send you the good kind of emails. Until next time, have a great day!

While localization is a joint effort, it's clear to everyone that those actively translating have a major impact on the quality of the results. In this episode Marta Boer, an expert of vendor and talent management in the localization industry, shares from her experience on how product teams can work with and manage translators to optimize their localized user experiences. Audio Text video About Marta Boer Marta is a talent acquisition expert passionate about improving the world through localization and human connection. With over 20 years of experience in the language industry, Marta previously worked as a project manager, vendor manager, and localization operations manager, as well as an independent localization specialist. Today, Marta helps SMBs and LSPs build or grow their localization teams and solve talent acquisition and supply chain management challenges. 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 another episode of the Localization Process Pod, where we learn all about how companies everywhere get their products localized. 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're optimizing their processes for a better localized experience. Today, I have a special episode because for the first time in this podcast, we are not meeting with someone from a product company. Instead, I'm interviewing Marta Boer, an expert on talent and vendor management in localization. We already know that humans are the biggest resource when it comes to creating great experiences in every language. And so I asked Marta to come and tell us how to make the most of our relationship with translators. Marta has been in localization for over 20 years and managing vendors for over 10, and I'm really happy to have her here. Welcome, Marta. Marta: Thank you, Michal. Michal: I would kind of love to know, are you a vendor manager today? Marta: I am a vendor manager today, but I try to work on my own, trying to set out on my own. Not to say that if I didn't have a job offer, I wouldn't take it. But I'm also consulting with a few companies. So they manage to implement some kind of a community sense to their vendors to their vendor management department and how to go about this. Michal: I'm not sure if you even told me how you got to vendor management in localization. Marta: Well, I think it was a mix of things, but, in the last 12 years I was part of a company that specialize in QA, linguistic QA. It started with two people when we were managing projects and reviewing content for Brazilian Portuguese. But the whole mission of this company was to set up a an LQA for other languages as well. So from the very start of the company, we had to contact people in the industry. At the time, we knew people that worked together or for us in other projects. So we hired people that we knew. I was a Brazilian reviewer and I remembered people that had worked in same projects as me and... spanish reviewer or a French reviewer. And that's how we got our first contacts to work on those projects. And from then on, as the company grew, the people were busy and we were trying to find more people to join new projects. Okay, so let's go to Proz.com or LinkedIn. LinkedIn was very new at the time. People would refer other people. Yeah. So that was challenging in a way, but it was what needed to be done. Now, we would go out and, you know, find people to, to work on our projects. And we were lucky or we were good at what we do. with That's very hard to say, right? People don't boast enough, especially women. But we found good people to work for us. And our projects went very well while we were doing them. Michal: Yeah, I actually, I remember those first days. had to go into these, like, infinite lists on pro.com and you had to search through the people, and then you had to decide based on sometimes very random criteria, who to approach, who's like the right people for the job. Marta: Yeah. And because we wanted to do something different, we decided not to test people. So a lot of our projects, we would kind of train them or get senior reviewers to review the work after they did the first few projects, so there was not a pressure of doing tests and having to pass something. And also not having to put people on the spot without getting paid. Sometimes the tests are long, right? Half an hour, one hour of work for a freelancer is a lot. So we decided not to use this way, not to ask people to do tests for free. So we had to invest a lot of our time and other people's time to check the work of this new people that would come to work for us. And in the end these people that work for the same language became kind of a team, even though they were freelancers. Michal: Then if you don't test the linguists, then... on what grounds do you choose to work with a specific linguist and not one of the others, which are, there are a lot of people looking for work. Marta: Yeah. So the first thing we would do, it would choose people based on years of experience, five to 10 years depending on the subject. Also, for some subject matters, we wouldn't go over 25 years of experience because it was all related to technology and tools and... you know, not to say that people that have 25 years experience cannot do those projects, but it was one way of screening. Mostly, we decided to go on a hunch and trust people a lot of the time, and it worked out. And we would support them saying that if you're a new reviewer working for me, you would be by a senior reviewer, or your work would be reviewed a second time by a senior reviewer. By the time we had like three or four people for the same language, they became like a team, like I said. And they would welcome somebody into the team and, and tell them, this is how we do it. This is this client's preferences. So, hmm. We didn't encounter any problems. We did, but not something that would explode a machine or something like that. But we, we used to hire people because they were experts in what they did, and they had to demonstrate that. They were the last people to touch some content sometimes. So they, that's why we had... the usual, right? Style guides, glossaries and stuff, but we also had senior reviewers checking their work from time to time or train them before they start to get very heavy projects. Our main job was to do LQAs. The mission was to remove a very painful point in localization, which is the LQA cycle. Michal: Yeah. Marta: The LQA cycle used to be very long and very painful, a lot of back and forth as well. And it used to be done in an Excel sheet or something like that. I'm talking about 15, 20 years ago. This Excel sheet with the review points from a reviewer would go back to the translator. The translator wouldn't agree with some points. There was a review 2 phase. Then the reviewer would review the translator comments and so on. So this could be going back and forth five, six times. Very hard for people to agree. LSPs were very protective of the translator's names and details. the reviewer didn't really know who they were talking to in this sheet. So one of the remedies was: why don't you create more collaboration for this phase of the process. And then that's how this company came about. Our reviewers were like language owners or language leads. There are different names for the same thing. They would review the content, create feedback, send to translator and the translators would be invited for a conversation. So they could discuss the feedback, understand the points. And most of the time the translators would understand where the reviewer is coming from. Not to say that our reviewer was the owner of the truth. sometimes the translator was right as well. So it was an adjustment. It was all a conversation and a collaboration. Michal: Yeah, but there was a conversation, which I think is, on on its own a unique aspect, right? Because a lot of the times LQA is done very separately from translation. Sometimes , not even by linguists, right? And so it's very hard for people to agree and everyone has an opinion when it comes to content. Marta: Yeah. Michal: It's also, it's the same when you write the content. Everyone has an opinion, the writer does something, then the designer has their own feedback on it. The developer has their own feedback on it. The CEO says something and it's like, it's infinite. You can never get out it unless you say, okay, I'm limiting the amount of people who have access to giving feedback on this piece of content. And so it's the same with translation and it's infinite. Marta: Yeah. The owner of the project, most of the time wouldn't speak the language, so they couldn't be an arbitrator or decide on the best solution, but they were put on the spot a lot of the times because they were anxious to get their project finished. There was nobody that take the ownership and say, okay, we stop here and this is gonna go this way. So the solution of the collaboration was very welcomed by our clients. Our clients knew the name of our reviewers and our clients sponsored some programs that would also require the LSPs to disclose the name of the translators because if they have to collaborate in a chat or in an email group or something, they need to know each other. So the other important positive aspect of that, was bringing this translator back to the conversation. Because you know, they were very siloed. They are very removed. They have to churn words like crazy to make ends meet. And the value added by the reviewer side of things would also give them feedback, but also bring them into the conversation and ask their opinion and, and also check why some instructions are not followed or how much pressure was this person under so they couldn't understand what they were doing. How does these strings reach them? Because if you are doing a UI, most of the time you only receive strings. There are one word, 10 words, I don't know. But they don't come inserted in the context. Michal: Yeah, and it's very hard to produce good results Marta: Yes. So our PMs and account managers and so on understood what the client wanted, helped create instructions, helped curate the style guide, the glossaries. If the client had a good localization department inside there was even more pressure because we would have to abide for what they were you know, building internally. If the client didn't have a localization department, then our teams were understanding client needs, understanding the quality that the client wanted, creating documentation around it. there was enough time, this would be shared with the translators before they could do translations. But this would vary with the nature of the project. The point of this one was just to, to bring the translators back into the conversation. Make them feel part of the whole, you know, collaboration Michal: Yeah, the process. I feel that in the earlier days of online translation, when companies started getting their workforce online as well, it was so easy, I guess, at the beginning. So it was sort of industrialized, right? You, you made these kind of, not automated processes, but you could click a button and you could email 50 people and say, oh, who wants to take on this project? First one who answers, the cheapest one, was given the project just because it made everything faster and made everything cheaper and kind of like mcDonald... mcDonaldized.... Okay. I can't say it, but you know what I mean. It made this kind of a fast food translation method, I guess. Marta: Yeah. Michal: And what is happened is that... translators were... They became this kind of bolt in that system. Marta: Yeah. Michal: And, they started being treated like non-human. Like just someone who has to move the text from one stage of the process to the other stage of the process. At least that's how I felt when I was working as a freelance linguist. Like I was a bolt in the system and that's how I was treated and all these mass emails... The only thing I was meant to do is to move something from one end of the process to the other end so that it can go on and do its thing and be there for the client as fast as possible. Marta: Hmm. Michal: And when you dehumanize people, obviously you get less involvement, less engagement, less of a willingness go the extra mile, to do better work. Right? No one is inclined to do anything that they're not forced to do or paid to do. And what you're saying, I think the biggest thing that comes out of it for me is humanizing translators again, making them part of the team instead of part of the process. Yeah. Does that make sense? Marta: Absolutely. Michal: Yeah. Marta: Yeah. So bringing the translator back into the conversation was a big, big step. And we felt that at the beginning, translators felt weird about it. Michal: Yeah, because it's unusual. And I'm sure it was more unusual then. Marta: Yeah. But after a few months, realized the value and that they were heard. And once they felt heard, then they accept the process a little bit better. Michal: Yeah. I'm guessing that once everybody understands that their input is actually valued. Then I'm guessing they start behaving in a whole different way. Marta: Yeah. Michal: Which kind of leads me to my next question, because we talked a lot about the technicalities and how LQA was done, but from your expertise as a vendor manager, what were the key things that you did that really made these people become part of the team and not part of the process? Marta: Hmm. I've been asked this question a lot, and I think it was just our ethos, the way that we treated people from the get go. And our reviewers, being treated better, would treat translators better as well. So it's a kind of a chain. I think if you change the way you treat people, it goes in ripples and it affects everyone, right? So if the reviewers are treated better, and if they understand that the review part is not only something that they need to do to prove they exist, like, they have to change something in a text to prove that they're doing the work. Because that's what happens, a lot of people in the localization industry kind of have to prove their existence by pointing to other people's mistakes. Michal: I distinctly remember, I worked with a different linguist and we worked on reviewing the content. We worked together. And I really distinctly remember, I didn't have any notes and he said, no, you have to have least two notes. Otherwise, something is wrong. You're not doing the work that you're supposed to do. But then a few years later, I did a project and there weren't a lot of notes and the project manager actually wrote back to me to say, so you know, we got feedback that you were doing really good review because you're not excessively adding, you know, Marta: Yeah. Michal: Preferencial edits, just to show that you did edit, I'm is a big issue for companies. Marta: So, by that time then there was already the option of kudos in the industry. So if You review a job that has no changes, then you would give praise to the translator. Then the cycle's closed. In way people need closure, right? Michal: Yeah. Well, it makes sense because you know... I saw on one of the Facebook groups a while ago, when you talk to a human chat support center. Uh, Then you wanna say thank you, and it reopens the conversation because the... yeah, because, the conversation was already closed and it was handled, and your problem was solved. And it's an issue because as humans I think we really want that, like you said, that closure. We really wanna be to say that "thank you". Marta: Yeah, that reminds me of the early days of email. I'm going to reveal my age. And there was one machine in the office, one email address for the whole office, and people would take turns sitting in front of the computer to see if there were new projects coming in. Then one day somebody sat in front of the computer and said, oh, this guy sent me an email just to say thanks. And we were not used to this, you know, we were receiving projects and email was not something so quick in the beginning. We were surprised that this person used this whole means of communication just to say thank you. Michal: Yeah, that makes sense. You wouldn't send a letter to say thank you, but yeah. When you do, when you have email, then you say thank you. Okay. So, when you manage linguists, freelance linguists, what are the top things that you should be doing and you should make sure that your company's doing to optimize, I guess, the quality of work? Marta: I think trust is the first thing that comes to mind. You have to feel trusted to trust people, I suppose. Somebody has to start, right? Somebody has to be the first. So if you treat people like people, it's already a great start. You need to invest some time and some energy into building a relationship. I think we are at the stage now that everybody realized that crowdsourcing didn't work. Machine translation is not great either yet. So trust and investing time into getting to know your people. And that's where vendor comes into play, because you need somebody dedicated to do that. So, when we were bringing new people to the team, it was always very welcoming and casual and trying to make people feel at home on the slack channels and things like that. But there is a time and energy that you have to invest in it. You cannot have a project manager try to do this bit very well. Michal: Yeah. Marta: The project managers will develop their own communication style and relationship with their preferred vendors. But there needs to be this level of care in the beginning of the collaboration, so people feel welcome. Translators, reviewers, feel welcome, feel heard, feel understood. When this particular company grew to a point where we were hiring people that we never heard about or they were not referrals or anything, we started to do 15 minute phone calls with them just hi, how are you? To check if the person is real, to check the person is a good fit for your team. To check why somebody that does English into German is charging a low rate. You know, as you grow in this role, you notice some red flags as well. So if a German person is charging too low, then what's going on there? I suppose this role is becoming more relevant now. So you really need people that like to deal with people, that have a good rapport. It's almost like a human resource thing, but it is not as formal because these people are freelancers. They are your vendors. They don't have any commitment to you, formally, apart from a contract that is like, I send you work and I pay you, and so on. But you really need to create this bond. So they, they feel they want to work for you. They feel they are treated well and they are valued. And if their kid is sick, they don't mind telling you, look, is there somebody to cover for me for this project because I have to go to the hospital. Or, you know, something like that. So it's human connection as well, very important. You make people feel at ease with you so they don't feel under pressure or become unresponsive because of some anxiety that they don't know how they're going to be treated. And I suppose that another thing that facilitated this whole thing was that projects were coming on an ongoing basis. So the same people would be getting the same kind of jobs from the same client. So the account manager, the project managers and the reviewers that did the work were like part of the same team, and then supporting this whole operation. Then there was the vendor managers getting people, but also checking on people. One of the ideas that we had that worked well was having somebody that would call the vendor advocate, if a vendor becomes unresponsive or delays a couple of projects in a row or something, then somebody would go and check on them. Not check on the project, right? The first questions I would ask people were, is everything okay? Can we help, can we support, can you engage with the second reviewer and see if they can take over from you? Because this also became like a relay team kind of thing. For projects that have had more than one person working on the same type of content. They could exchange jobs if one person was too busy or if something happened suddenly as well. It's funny how these people set out to work on their own, but when they're part of a team, they feel more comfortable. Michal: I think there's nothing we can do against it. Right? It's, it's human And I say that as a person who likes to work alone. Obviously when there's communication, we communicate better, so we transfer information That's the first part. But also I think we do feel more inclined to do things for that other person, for the other company. When we know who they are, we have a face and a name that we can kind of connect to that random email that we get. Marta: Hmm. And this whole thing that we set out to do, we didn't know where we were going to end. For me personally, feels like it happened organically. The intention of this company was collaboration, human centered communication. Human first everything. It worked because everybody felt good working for this company. You know, Michal: Yeah, definitely. Marta: They would refer friends, they would, would like to work in the team. We had a slack workspace with more than 300 freelancers. and we didn't need a community manager for that. So, you know, people knew how to behave. If they feel safe and trusted, they self-regulate in a way. So if somebody would post something that was, somebody wouldn't agree with, they would kind of, you know, discuss and resolve it among themselves. It, it was not like one of those Twitter kind of things where people not treating each other very well. Michal: Yeah, because there is a face and a name, and once there's a face and a personality, you know that other person, then you don't... Marta: It was a still professional environment. So yeah. Michal: Yeah, well you mentioned about how people self-regulated and how... I'm just curious ' because translators are considered to be a tough people to work with sometimes. And we do have this reputation that we sometimes, first of all, there's a lot of ego involved in working with translators. I think a lot of translators are just very, very smart people and that shows in the way that they communicate, that shows in the way they're used to being the smartest person the room. And then egos clash sometimes. And like you said, people have their own opinions and when you do translation, editing and QA, everyone has their own opinion and people start arguing with each other. So how did you, how did you feel about working with translators? Was that your experience as well? Marta: I don't remember any very bad situation that happened, but what happened was that because translators felt heard for the first time in a long time, they started oversharing. So they would come to our reviewers issues they were having with the PM they worked for in, in an LSP. So it was not, it was not under our scope. We couldn't do anything about it. So I don't remember anything very bad that happened apart from reviewers sending feedback and the feedback not being heard or not being implemented. We didn't, we didn't really detect any in this collaboration because I think it was a professional setup and translators were eager to learn from the reviewers as well. Michal: And what would you recommend, because you said you really recommend having a vendor manager on staff because project manager can't take this on top of all their other responsibilities, which makes sense. But what would you recommend if you are in a digital product company and you are the only localization manager or even the product manager, and have enough capacity to really hire a dedicated person. Marta: Yeah, Michal: How could they do, like with minimal effort and maximum impact, what could they achieve? Marta: The first idea that comes to mind when you ask me this question is if you go after language people that have experienced. And they can become like some sort of a lead for you. Even if they're a freelancer, they would be your top person for that language, for example, and, and give them some kind of autonomy to choose other people for the team together with you. So I think nobody should work alone. If you are a localization manager in a company I would look for top people on their language and try to hire two people per language so you're not uncovered. So... Michal: Yeah. Marta: Of all the systems I've seen, there is no perfect way of localizing content. Even if there is a good content management system end to end, there's always stages that need people. So like managers or coordinators or something like that. you can convince one freelancer to put the team together for you as well. You can outsource this as well. There, there are people that are willing to do this work. Michal: Vendor management. Marta: Like a light version of a vendor management Michal: Okay, that makes sense. Yeah. Tell me a little bit about the courses that you are... I actually said you are writing them, but I saw that one is already advertised. Marta: Okay, so I created a course for Localization Academy called Vendor Management. It's to see how vendor management works end to end for somebody that wants to get into this role. It's a 20 hour course, so it's 10 sessions of two hours each, and it, it will cover all aspects of vendor management that I am being exposed to in my career. And the second course is called new to loc. It's with localization Advocate. And it's going to be a six hour course, so two hours, three Saturdays in a row. For people that want to get into localization just after college. Michal: Yeah. Okay. That's amazing. Before we wrap it up... let's say if I asked you for your biggest tip for people reaching out to freelance linguists for the first time. Maybe they're just starting to localize and they're saying, oh, we need to find someone to do Spanish. We have a very small piece of work for them. It's not, we're not doing a whole kind of big product. don't have, obviously the budget for LSPs and also the need, most of the time. They don't even have a localization system yet. But they're reaching out to freelance linguists. So what would be, first of all, your biggest tip on how to do that, but also... if you have kind of recommendations to where they can find them and what are the best places to look for linguists? Marta: My first instinct would be to invest time at the beginning to get to know the person. No still want the highest quality, right? Michal: Yeah. Marta: So if you invest time to get to know the person, exchange a few emails or LinkedIn or even Proz. Proz is more difficult. But linkedIn is more personable. Get to know the person, exchange a few messages, have a phone call if needed. You know, build a relationship. It's time well invested at the beginning. Look for references. Look to see if they work as part of a team. This gives some reassurance that they have to keep themselves in check because they are working with somebody else as well. But I would invest time at the beginning to get to know the person, to show them you're human and to, to, to check they're also a human. I am investing time in LinkedIn these days, so I look for people in, the language pair that I need in there. I think LinkedIn is the way to go right now. I feel that at least in in the last couple of years, I would like people to invest more in their online presence and LinkedIn profile. I have a personal mission to eliminate CVs from my inbox. Michal: Oh, wow. Marta: Would love people to be, you know, findable and personable and reachable on LinkedIn and, you know, eliminate more paperwork. Michal: Definitely. you find that maybe you are more inclined to reaching out to people who have their own website or a well maintained LinkedIn profile rather than those who just send a cv? Marta: Yeah, I'd say make yourself easy to find on LinkedIn and have a website that is up to date as well and have a consistent online presence. You'll need to work on your personal branding. I think it's the way forward. Michal: Yeah, that's a whole other podcast episode, I guess. A whole other conversation. But yeah, absolutely. Marta: I feel the industry should go for human connection, trust, and collaboration using things like LinkedIn and Slack and, you know, the way that you're doing stuff. So yeah, just create opportunities for people to connect, to interact. Michal: Absolutely. Marta: And we keep each other in check. Michal: Definitely, definitely. Just have more people and localization around us. More women in localization is also amazing. Marta: Yeah. Michal: I'm enjoying that, a lot. Just seeing women from all over the world who are also passionate about localization and UX localization. So thank you so much. I really feel that this could be a game changer for a lot of companies because I think a lot of companies that don't do localization come into this without really knowing how to reach out to people, how to communicate with people from different, you know, countries, different languages. it's a whole other mindset, I guess, when And so definitely I think it's going to be really, really helpful for people. Marta: Well, thank you so much for inviting me and for the opportunity. Talk to you soon. Michal: For those of you who took the time to listen, you're the best. Thank you for being here for this special episode. I hope Marta's words gave you some inspiration on how to make your localization processes more human and find the best people too. If you want to get a message about new episodes from the Localization Process Pod, make sure that you follow this podcast on Spotify or subscribe to emails from Localization Station. I promise to only send you the good kind of emails. Until our next episode, I was Michal Kessel Shitrit. And this was the Localization Process Pod. Have a great day!

What does localization look like when you localize into the same language? That's exactly what we tried to discover in this incredible conversation with Monica Martín del Campo from Despegar. Monica collaborates with the UX team on Spanish-to-Mexican-Spanish localization, to create a unique experience for Despegar's Mexican audience. Audio Text video About Monica Martín del Campo Mónica is a bilingual content strategist specializing in SEO with over six years of experience in the innovation and startup ecosystem. She has previously worked as a translator, copywriter, and content creator within both product and marketing fields. Mónica is currently part of the UX Content Management team at Despegar, the largest Online Travel Agency in Latin America, where she leads content localization projects all across the platform for its Mexican users. 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 again to the Localization Process Pod, the podcast in which we discuss different localization processes of companies all around the world, so we can learn from each other and deliver better experiences to users worldwide. I'm Super excited to be hosting Monica Martín del Campo in the episode today. In the industry, we usually talk about localization from language to language, right? From one language to the other. But Monica works at Despegar, which are a digital product company in the travel industry. And at Despegar, they do localization from country to country within the same language. So they do localization in Latin America from Spanish to Spanish in different countries, and I think this brings a really unique perspective into this discussion. So we're going to be hearing some really interesting insights. So hi Monica, it's really great to have you here. Monica: Hi there! it's so nice to meet you and happy birthday, by the way. Michal: Thank you. It'll be a distant memory by the time people hear this, but still, thank you so much. Monica: I just thought it was your birthday yesterday. Mine is right around the corner on Monday. Michal: Oh, really? Happy birthday too! Monica: Thank you! Michal: Summer babies. Monica: Summer babies. Exactly. That's really good. Michal: Although you're on, is it summer? Is it winter? Monica: It's summer. I'm in Mexico. So yeah, we have summer over here. If I were in Argentina, it would be winter time. And you would see me like fully clothed all the way up to here. Michal: Isn't that confusing though? Although I would imagine that's the same for English speakers in different countries. I'm so not used to it because I speak a language that is in one very, very tiny part of the world. Monica: Well, that's kind of what we're going to talk about today, right? Michal: Yeah, absolutely. That's exactly it. So tell us a little bit about you. What brought you into localization? Monica: I think I have a little bit of a mixed background. I started out studying mother languages and interculturality, and I was interested in that program because it had a track focused on translation. And I had my eye on being a translator. At the same time, I did have the opportunity to work for a business incubator. So I had my first approach into the innovation startup ecosystem. Like, I had got a glimpse of what my life would end up being like working more in the digital context. And by the time I graduated, I officially started my first role as a translator. I started getting the seeds in that job for like understanding localization and like my other specialization, which is SEO. I would start seeing all of these patterns and like, Oh, this is interesting. Why do we always highlight or have a link to this word? Or I started having an understanding of keywords, and things like that. I went on my own and I started learning. I started working more as a freelancer, with my own clients. For these clients, I was not just translating, but I was also doing copywriting. And so we needed more nuance to all of the work that I was doing with them. But it wasn't until I was offered a full-time job at the FinTech company that I was also introduced to not just SEO and copywriting, but to UX writing. I don't know if you've ever worked for a startup, but you know, it's like, everyone does everything basically. If you are the copywriter, you are the UX writer because you also need to write copy for the website. And so I was like, okay, I need to start learning about it a little bit more. So that was my background before arriving in Despegar. Michal: So then you came into Despegar and then... What kind of role were you doing in there? Monica: So in Despegar, they found me because they were looking for someone for the UX content management team. And so they were looking for someone who had skills that were very similar to mine, but also happened to be Mexican because one of our three main markets are Argentina, which is where the company started out. And then Brazil, our brand is Decolar instead of Despegar, and then Mexico. And Despegar right now is in 19 countries. So again, these are the top three markets that we have, but we're also in Columbia, we're also in Peru, Chile, so all over Latin America. Are all the markets Spanish-speaking, Portuguese-speaking, or do they have markets that speak like, Asian languages or European languages, other kind of Latin languages? Mostly it's Spanish-speaking countries with their varieties, Brazilian Portuguese, and we also do have our website in the US, in English. Michal: What's your source language? Monica: Spanish. So most of the content is written in Spanish, Argentinian Spanish because again, that's where the company started out. Now that we have a bigger team of UX writers that are also Brazillian, there's some content that actually starts out in Portuguese and then gets localized into Spanish. Michal: You've mentioned that you came from SEO writing, SEO translation. I think it's really interesting because in SEO, you have to use the words that people use, right? Because that's the words that they use to search. And then UX writing is very, very similar in the sense that you have to use the language that users use, the language that your market actually uses. So there are similarities between those two fields, I think. Monica: Yeah, definitely. Sometimes I've heard like, oh, UX and SEO, they're like enemies or like they are constantly clashing. I'm like, not necessarily. SEO is actually you doing UX for search engines in a way like you're helping the audiences find you. And like you just said, you need to create a strategy based on how your users are searching for you or for what you are offering. I could have the same landing page for Mexico or for Argentina, but the way we say, like "Vacation rental", "rentas vacacionales" in Mexican Spanish. And then for Argentina, it's "alquileres temporarios". Michal: Oh, like temporary rentals. Monica: Yeah. So, like, the concepts that we use are very different. That's where also localization comes in. Inevitably in SEO as well as in UX. Michal: I think this is very interesting because a lot of companies, the way that they do localization is they do research in a source language, in one language, and then they take all those insights, they write the copy, they translate the copy and no research comes in at the middle of that process, right? But it seems like you're doing a lot of adaptation to each market. Monica: I mean, it is challenging. I'll tell you. That's the ideal, what we're trying to constantly do. We are in 19 countries and I think it's 17 Spanish-speaking countries. So we're not quite there yet. We try to do that at least in the three main markets, that's something that we're focusing on. Michal: But it is incredible that it is the goal. And I'm guessing that sometimes, when you do localization, for example, for Japanese and, I don't know, German, it's really hard to look at the tiny things that distinguish different variants of those languages. And when you do a lot of different Spanish variants, then I'm guessing the unique features pop out. Monica: Yeah, exactly. When I joined the team, I didn't join as a localization expert. It was more like your content strategist and a lot of, you know, localization-related projects go through this team, which is the UX content management team. However, it was like, oh, we have our first Mexican UX writer on the team. I think we're 24 UX writers in the company now. And so they would start sending me messages, like, Hey, can you peer review this content? It's for Mexico. It's just going to be a quick checkout message. But then it started getting a little bit more complex with some of the requests. Like, here's the screen. And we were trying to welcome someone into a new feature. And then I'll be like, okay, we need more cultural nuance. So give it to me, let me work on it a little bit, and then I'll bring it back to you. And at the beginning that sounded great, but eventually, you know, like that, it was not a process precisely. Maybe in a week, I would get more simple requests and I would just answer and that would be it, or I would get bigger requests which would eventually delay both their deadlines and also my own projects. In the beginning it was just me. Thank God we now have Juan Bravo, the second Mexican UX writer on the team. That was like, just for the first, I think, six months in the company. That we were just getting requests and we're responding to the requests, depending on how big the project would be or the necessity of the feature. And then we realized, you know, guys, I think we need a process. It's getting confusing and like, how do you prioritize what comes into your workflow? I sat down with my manager and our content ops specialist, and we decided, okay, it's time to design a new process. There was already a process in place for localizing from Spanish to Portuguese or Portuguese to Spanish. We assign a ticket to one of the Brazilian UX writers, and then they do their magic. But we kind of need to adapt because of what you just mentioned, like maybe it's a little bit more obvious when you go from one language to another. Because like, it's the same language, just a different variant. So, we started thinking, how do we adapt this process? And on that process, we found you actually. We started doing some research because again, I have a little bit of a background. I took some courses at some point in my career, but I really wanted to know how to work on that process and make it so that we can streamline all of this. And then we went into talking to the UX managers. Our goal in that meeting was not just to explain the process, but to explain why this was a need. Like, why is it important, not just for the user, but as a company to have this process to make sure everything's organized. To be honest, I was very nervous for that meeting. Because like, these are UX managers that have the longest career in UX, and then just, how do I talk to them into this? And fortunately, I do think that the culture... Everyone in the company are very much open and understanding and being receptive to new things. So on that hand, we did great. "Yes, like we need to do this. It should be a process". However, we did get feedback like, "You know, I'm not sure this is the right process for it". Like it feels too complex sometimes. Are we supposed to upload a ticket for every single piece of content that should go to Mexico? That sounds insane, you know, it's just going to be endless. So we had to go back and workshop a little bit more and understand, like, what are the nuances? How does localization from Spanish to Spanish work specifically? And where is the need? We came up with this three-step process, for this first version. Sometimes you just need to confirm a concept, or just get a quick peer review. So for those messages, we created a channel in our company messaging app. You can say it's like the hotline for Mexican localization. So, "Hey, Moni", "Hey Juan", "We have this question. Can we use this word? Can we use the word carro or coche?" Because in Mexico some people are like, no, it's supposed to be carro. No, it should be coche. But those are the quick questions about specific technical aspects of it. What we do there, we start recording them and we start understanding where's the pattern, what are the most typical questions that we should later document so that we're not answering the exact same questions every three months. So that was like part A. And then for part B, we're still going to use this process of creating a ticket for localization, but it has to do more with specific scenarios that affect the brand voice, that have to do with cultural nuances. Based on the audit that we did before, we understood, okay, these are the scenarios that we can just dig into a little bit more. And so now the team knows to add a stage for localization. And so they also see that in like their timeline and, you know, their Gantt and everything that they need to work on. And for us, it's just clear. Okay, we're going to have to work on this for two days, three days. And sometimes something will come in through the chat and we realize, no, it still needs more of a cultural nuance. And sometimes we get something through the ticket and it's like, oh, this is actually pretty simple. But we're documenting all of these things so that eventually we can workshop with the rest of the UX writers. And streamline the process a little bit more. Michal: So I'm curious because you said you are localizing into 19 markets and you only do Mexican Spanish. Do you have in-house people for every one of those markets? Do you work with freelancers? Monica: We're not localizing right now for the 19 markets. We're localizing mainly to Brazil, Argentina, and Mexico. Maybe a little bit more on the US side. So three main languages and like the two variants. We do work with the, quote-unquote, neutral version of Spanish for the rest of the countries. But there are again, scenarios that require a little bit more of that wink, that localization flavor to it. So what we will do is something that was done before both myself and Juan arrived on the team. The writers will work on the content. We do the research and we try to make sure that it's as authentic as possible. We are a big company. So even if we don't have UX writers for all of those markets, we have more people in the team that do belong to those markets. You know, the content might not be their specialty, but the culture is. So in that sense, they can give you more feedback, like, "Oh yeah, that's perfect," or, " That kind of sounds a little bit out of line". Or "Oh, this is something I would say in Colombian slang, definitely, but I don't think that's how the company sounds like. So we do have the resources in that sense. We have the people who have, like, the cultural background. Michal: Does the copy perform differently in those markets that you're not directly localizing for? Monica: Yeah, I think that they do perform differently and they work even better once you start localizing like it just feels closer. It's, it's part of the nature of like, you know, either UX, SEO, copywriting. If it feels closer to you as a user, as an audience, then you will just be more drawn to it. So yeah, I think localizing is key for as much as you can, not just between languages, but like between variants. Michal: When you do the default variant of Spanish, the neutral variant, is it more formal or kind of strict or stiff than the cultural variants that you use? Monica: I wouldn't say it's that formal. Because that's not aligned with brand voice. We're very much a more casual brand. But yes, definitely. I keep calling it neutral because it might not be formal, but it's a little bit more neutral in some of the cases. However, Latin American Spanish does share a lot of expressions that reflect closeness. So I wouldn't say it's completely formal. But it does refrain from some of the cultural nuances for sure. You can just get so much closer once you start bringing in those references and expressions from the country. Michal: It's a challenge that is shared, by the way, by every kind of standard variant language, because, you know, because casual language grows from the surface, it grows from people. And so it grows within the different variants. Once you use a standard variant, by default, you lose some of that casualness and that closeness and that engagement. And I think there's no way around that, unfortunately. So it can explain some of the differences in performance that you see in the localized variants Monica: For sure. Yeah. I'm a geek. So for me, it's just so exciting to see all of that unfold in front of my eyes. When I was studying more languages, we would study social linguistics and like, understand registers. And now that I'm working in localization, I understand the big influence that localization has in language registers. Because there are specific expressions that maybe for a Mexican, you're being too direct. Because we Mexicans like to just talk in circles a little bit. So, it's the exact same phrase and you understand it, but the cultural connotation makes it go up a register or down a register. That's what makes it so interesting to go digging into different variants. Michal: Yeah. Isn't this fascinating? I completely relate to what you said about geeking out about this because I feel that sometimes you look at a language and you can see the culture through it. And it's, it's really so fascinating to see. It happens even in languages that have one variant, Hebrew, in my case. Monica: Yeah. Michal: You can definitely see the culture through it, and through the expressions, even the expressions that kind of develop these days, the new expressions that come up. And you can see the way that our culture changed in the last two decades and how it influenced language. I think it's fascinating. Monica: Well, to that point that you just mentioned, sometimes it's got to do with generational differences of like expression. So maybe I cannot use this expression in Mexican Spanish because it's just way too casual. And sometimes I will go into these conversations again with Juan, with my partner, and he would be like, I think that sounds like my uncle talking to me, you know. How do we work around so that it feels like it addresses our main audience, based on the ages that access our platform? Language is so complex, but beautiful. And so the more you go into it, I think it becomes more human and more real, the interaction that you have with the company. Michal: Yeah, definitely. Okay. I'm going to take us back a little bit, and I'm curious to know when you do localization into those markets, how do you do it practically? Like, how do you document the changes? Do you use a localization platform? Do you all access the CMS? Like what kind of process do you use? Monica: So like I mentioned, once we're doing the complex localization, we get a ticket and then it'll get to me or Juan. So we ask the team to be as detailed as possible so that we understand what was the intention behind the message or where in the flow is this screen's going to show up. It's very manual in that sense still, but we will be given either a Figma to see how the screen is looking or how many characters can we fit in. It's not changing one language to another, but if I want to use a different expression in Mexican Spanish, it might be longer. So it might not fit into the screen or not fit into the button. So then I have to rethink. We analyze the content and then we give it back either in the Figma or a Google Sheets or whatever, kind of type of document that was requested. And on my end, you would say like, that's it. Sometimes we go back and forth with the UX writers. But overall it's just like, I'll give it back to the UX writers and they'll just take over and go back to make sure like it's uploaded or deliver it to the IT team. Michal: When you say you have access to Figma, do you have actual edit access to Figma and you can change the copy in the file ? Monica: Yeah. Michal: And if you change a version in Mexican Spanish, do you have like a different board for Mexican Spanish and a different board for other kind of variants? Monica: Yeah, for sure. Yeah. We keep reference of those. It would be the UX writer who assigns the content and they will give us a space specifically for the Mexican version. So that way you can see the original version versus the Mexican version. Michal: And who copies that into the final production file? So who's in charge of that? Monica: Yeah. It'll depend. Sometimes the UX writer is in charge of uploading the content or has access to the different back-office platforms where you upload the content. Sometimes if it's something that's been developed by IT then you give it to IT. Soc... Michal: Okay. So I want to ask you a hard question. Another hard question. Monica: Another one. Michal: Another one. So let's say that your bosses come to you tomorrow and they tell you, we want to add another language. We want to add, I don't know, Chinese. How would you adapt the process when there's someone who's working on the copy, who is maybe not an in-house UX writer, and who's an external freelancer, or new to the process. So how would you adapt that process to make it more scalable for that? Monica: Yeah. Again, good question, hard question. If it's a market need, they would do something similar to what did with me. It's like, okay, we need a UX writer or content strategist and it has to be someone from that country. Michal: Yeah. Monica: So I'm guessing we would add someone to be the language lead if you may, for that. But I do think if it's a completely new language, we would follow the process that we already have for Portuguese to Spanish. I think we already have like a good background to have someone join in. However, we are always, always testing and challenging the way we do things. So it's probably going to be like, oh, maybe if we're going to start translating for Chinese, we're going to need an extra step because the characters alone are going to change. Michal: Yeah, that's true. I think it's really, it's really fresh what you're doing, because I feel that in many ways, the correct way to do a localization these days for digital products is just by hiring UX writers in different languages. But once you scale it up, it becomes maybe too complicated or too expensive for companies. And then someone says, okay, we have to find a way to make this more affordable. And that's when things start to break apart, if they even landed on the UX Writer solution to begin with, and not just went to an agency and that agency said, sure, we're going to do that for you and just send it over to whoever. So I, I do love that you're just taking this in a very slow and focused way, actually reviewing the copy, actually reviewing the flow and the experience, and not just saying, I just need that text in one, two, three languages. Monica: Exactly. No, we do try to be as detailed as possible with that. We're still in the process of figuring out that I think ourselves, I think we're on a good path. We're still figuring that out. Michal: Yeah, definitely a good path though. I agree. What are your plans to further optimize or improve this process in the future? Monica: Right now, we're on version one. We're just observing, understanding what's going on. We're constantly analyzing what is working. Maybe the process is not clear enough for some of the UX writers or details are not being turned in. We start documenting it and just understanding how to make it better, but also documenting the content, the concepts and all of the insights that we're getting. We're documenting them so that we can later on try to train the team, so we can make it easier or empower our other Spanish-speaking UX writers, and give them the tools so that they can do more of the localization, technical aspects, or certain expressions. I think that's going to help us optimize the process a little bit more. And from there, we're just going to take the next steps. I think in the future we're looking forward to putting these workshops together, and just keep learning more and like... So far it's going well, but you know, there's so much more that we can work on for sure. Michal: You mentioned that you came on as a content designer, as a UX writer. And then you sort of stumbled into a localization role, right? Monica: Yeah. It wasn't brought in as the localization expert, more like, I guess, the cultural experts. I didn't have the official title of localizator. Can we say localizators? I think we can say localizators. Michal: I think maybe we should. Because localizers are the people who are translating. So localizators could be the people who are facilitating the process. I think we need to use it. I think it's, it's here. Monica: OK. Let's throw it out there. Let's see if it sticks. And if people start using it, then we can coin the term. Michal: Definitely. Take credit. Monica: Sure. But yeah, I didn't come in as the localization expert for sure. It was the goal from the start: you're Mexican, you have the skillsets and you're going to help us curate, create, and just work on the content that's specifically for the Mexican market. Michal: Yeah. Monica: But I wasn't officially. Michal: Yeah. Well, it's something that I've been hearing a lot from people. A person comes to the company as a UX writer, as a content designer, or as a UI designer sometimes, and they really care about the localized content for some reason. Maybe they were in a localization role in the past. Maybe they speak another language. And so they kind of take that flag and they start to run with it and they become the localization advocate in the company. And it's, it's a story that I've been hearing repeated because I think a lot of the time companies don't know that they need a localization expert or a localization manager until someone says, "Whoa, something is not going right here. And you need someone to, to kind of constantly watch over this. And I'm willing to be that person". Monica: For sure. Exactly. I think if companies can't name it right away, they're like, we know something's up. Maybe we should pay more attention. Before I landed in Despegar, that would also be my experience with clients. You'd be like, "Hey, but who's your audience?" and they would say, " Oh, they're from 18 to 25" or whatever. Like, yeah, but, what's your market? So that I can translate and I can adapt to it. Then they were, like, "Oh, just do Spanish. And I'm like, no, it's not just Spanish. Michal: " Just do Spanish". Monica: "Just do Spanish." And I'm like, okay, fine. But if most of your audience is Mexico, and if your brand voice is quirky, I have to bring in those aspects that this variant has. So yeah. I do think companies are more and more learning that this is key. But I do think that even you mentioned it at some point, that localization has been around for a while, but it hasn't really been popular for a while. Right? Michal: Yeah. Not in experience teams. Monica: Exactly. Exactly. So hopefully that will change in the future. And now they'll go for it or localizers... No, not localizers. Localizators. Michal: It works. Monica: It works. Just, just put it on your LinkedIn and start like... Michal: Maybe that's just the name we need as UX localizers. It's just going to be localizators. Monica: Yes! Oh, I loved it. I love that. I think you already mentioned UX localizers. I was like, I'm going to keep that. Michal: Yes! It's really a problem because translators have been, like you said for a long time, have been existing and doing their thing. And they used to have like little pieces of paper where they wrote the texts in different languages. And then this is such a different industry than what that used to be. It's such different work. Monica: Yeah. Michal: And the only similarity is that we're both writing something in different languages, but that's it. That's the only similarity. And so companies come into this and they say, "Oh, translation is translation, right? So just make it Spanish", but... Monica: "Just do it in Spanish". Michal: "Just do it in Spanish!" But... no, it doesn't work this way, right? It's part of the digital experience. You have to design the copy in Spanish, right? Because you're a content designer, you're doing it in a different language, but you are still a content designer. Monica: Of course. Michal: So that's one of the one of the main challenges. And that's why I think we should have a different title, maybe UX localizers, maybe something else, but something that is more relevant to the industry, I think. Monica: Yeah, I agree. Well, I mean, thank you so much for creating this podcast, too. And creating all of this content that's now online. That's something that's one of my personal goals. To just start being an advocate for localization, maybe like Latin American markets, just so that more people are joining in and understanding that it's not just language to language, but they're between varieties and what are the challenges? And I think it's important for us to just put that content out there. So that people are more aware and we start making better processes in companies in general. So thank you so much, too, for creating these spaces. Michal: Yes, do it. Do it. Take the flag and run with it. Monica: Yeah, I'll try. I'll do my best. I promise. It was just a pleasure talking to you. Again, I don't have that many people, like, in the localization business that I can talk to directly. Michal: Are you on the Slack group for UX localizers? Monica: No, I'm not. Can you send me the link? Michal: Yeah, you said a space. There is a space, an actual Slack space. Yes. So I'm going to send you the link, and feel free to join. It's a place To ask questions and consult and whatever and send memes about localization. Monica: Yeah, I heard that on the first podcast, but I was like, "What are they talking about? Can I Join that? " Michal: "What is the secret Slack group?" You have to wear the sorting hat. Monica: Nice. Michal: All right, thank you so, so much for being here. Thank you for sharing your process. Thank you for taking the time. I really appreciate it. And it has been fascinating. And also, I think really enlightening for me at least to hear about how you adapt copy in one language, because I've never, this is not something that I've been obviously doing because Hebrew only has one variant. And so I've never really taken a minute to think about how this is done and if this is even done sometimes by companies. And so it's really interesting. So thank you so much. Monica: It's my pleasure. Thank you so much for having me, really. I guess I'll talk to you soon. Michal: Yeah, you too. Bye! Monica: See you. Bye! Michal: For those of you who got this far, thank you for being here and learning about another localization process with us. I hope you enjoyed this conversation, and I hope you learned something new. And if you want to get notified about new episodes from the Localization Process Pod, make sure that you follow this podcast on Spotify or subscribe to emails from Localization Station. And I promise to only send you the good kind of emails. Until the next one, I was Michal Kessel Shitrit, and this was the Localization Process Pod. Have a great day!

We talk a lot about optimizing our processes, but it's rare we get an inside look into how it's done. In this episode, Anna Lenik, Localization Team Lead at LetMeSpeak, tell us how they brought their localization workflow from Google Sheets to 24-hour turnaround times by focusing on vendors, tools, and timelines. Listen in to learn how it was done. Audio Text video Key takeaways Prioritizing tools, guidelines, context, quality control, and development integration can help optimize localization processes. Establishing a dedicated localization team and permanent vendor relationships improves quality over one-off freelancers. Managing vendors directly instead of an LSP allows more control, though now a project manager assists with the growing workload. Transitioning from spreadsheets to specialized translation tools helped streamline LetMeSpeak's processes. The development team sets up the localization environment and selects content to translate within the tool, with English as the source. Optimizing timelines, such as delivering all updates within 24 hours, requires addressing issues like time zone differences and more. Involving the localization lead in product design gives perspective on the cultural and linguistic adaptations needed. Providing context like screenshots and string comments is also important for translators. Machine translation is avoided for UI due to context dependencies. Translators review and score machine translations to confirm the level of post-editing needed. Guidelines cover both technical and linguistic aspects like tone. They vary by language region (e.g. European vs. RTL vs. Asian). About Anna Lenik Anna is a user research and localization expert. When this interview was recorded, Anna was a Localization Team Lead at LetMeSpeak, a language-learning platform that helps people from 140 countries learn English. Currently, she owns a boutique user research agency to help companies connect with their user base in a profound way. To learn more and connect with Anna, visit her LinkedIn page. 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. I'm so glad to see you here for one more episode of the Localization Process Pod. I started this podcast to learn all the real hands on things that happen when companies get their products localized and we're five episodes in and we've already uncovered some incredible processes and advice from those brave enough to take the microphone first. To If you haven't done so yet, make sure you give the previous episodes a listen. And if you have a localization process to share, send me a message. I would love to talk to you too. If it's your first time here, then this is how it goes. In every episode of the podcast, we meet with someone from a different company to grill them on what they're doing right and what they're doing wrong and how they're optimizing their processes for a better localized experience. Today, I'm going to talk to Anna Lenik, Localization Team Lead of LetMeSpeak. Anna will tell us about how they managed to remove bottlenecks and optimize their process to get localized content turnaround to 24 hours. If you've been listening to me for a while, then you may know I don't think speed or cost should be our sole metric for success, actually far from it. But there is still a lot to learn from this about making localization processes more efficient. And I'm hoping you'll find this as valuable as I do. So hi, Anna. Anna: Hi. Thanks for having me here. Michal: Tell me a little bit LetMeSpeak and what you do? It's a really interesting approach. Anna: So at let me speak, I'm Head of Localization and Education. My main responsibility is product development for any educational features. It can be a challenge because in online, the motivation is really decreasing rapidly. That's why we have to think of better ways to teach people. And I'm also a team lead in the localization team. We've got 16 languages. And users in 140 markets. So your localization flow, it's pretty large. When I talk about myself, I usually just say that I am a linguist because that's my passion. I started my career in localization in 2012, so a long time ago. A little bit about us. LetMeSpeak is a language learning... medium for everyone who wants to learn English. We've got a lot of apps integrated. Like we've, we've got iOS and Android apps, a web app, and An NFT marketplace as well. So we have both users in Web2 and Web3 environment, and they all learn English together in this medium. One of our unique concepts is that we give financial rewards for learning English. And that's what makes us unique in that market. Michal: You say you have a few platforms, do you design the experiences themselves or is it more like a marketplace that people design experiences for LetMeSpeak? Anna: No, we design everything and develop all the products ourselves internally. We've got a lot of users, but for now they use what is already available. We create everything like language learning materials and all the features connected with Web3: crypto exchanges, NFT marketplace, and whatever you can do with NFT and crypto on the marketplace and then the app. Michal: You mentioned that you're doing both educational design, like in the product, and also localization. So how does that add up? It seems like two separate roles. Anna: In the beginning, I was more a localization manager because we didn't have... established processes at all. When I came to the company three years ago we had two languages and it worked with makeshift processes established by someone else. At that time, they didn't have a separate role for that. And then I came, we decided to scale a little bit more, so we needed more localization efforts. And now we only need to update and keep everything on track. So now it's easier to manage. But with education design, we've got a lot of new features basically every month. It's not so hard to work in both of these roles because we've got established processes already. Michal: Yeah. Okay. So do you feel that being involved in localization gave you a different perspective on designing the experiences? Anna: Yes, sure. Because when you work in localization, you just instantly become aware of what you deliver in different languages and in different cultures and how people react to it. You have to always keep that in mind when creating educational features or whatever product features you design, because all, the cultures and all the languages are different. For example, if we talk about education design, you have to adapt your methods to the audience, because people have different native languages and they understand the grammar rules and exercises differently. For example, if we talk about RTL languages, like Hebrew or Arabic, the syntax is very different. So you have to teach things differently for those users. The same in localization. You have to adapt everything to the culture, otherwise it just won't work for them. I think those two domains are very close because you have to adapt everything for culture. Michal: Do you find that people in different cultures learn differently? Anna: They actually do, but I think if we talk about online learning, the differences are not so distinct. If you teach online, you basically have to think of the syntax and the cognitive load for different types of learners, based on their level and based on their native language as well. But it's also very hard to adapt. If we talk about localization. We usually adapt the learning content when localizing it. We've got special style guides for, like, grammar explanations. We always ask our linguists, what do you think is the best way to explain this concept to speakers of your language? How do teachers teach this concept in your language? And it's always different. For example, if we talk about Chinese, they find special metaphors to explain certain concepts like tenses. And in Russian, we usually just use a lot of translation. So we try to adapt. So the copy is not the same in any language. Michal: Do you find that, components of the experience, like for example maybe... if you give positive reinforcement, do you give it differently to people from different cultures? Anna: Well, I don't think we do that now. But I think in the future we have to adapt things. All the marketing copy should be adapted, but sometimes it's like, too costly for certain markets, so you have to first analyze and do the research and then think of how much effort you want to put in that. market. Michal: Yeah. Prioritize. Cause you talked about motivation and I was thinking, okay, I know that people here are motivated by different things compared to those from other cultures. And then... I'm guessing the more you adapt this to the culture, the more motivation you're actually able to achieve for each of these markets. Anna: Yes, that's right, for example, if we talk about learning English, the motivation is very different in different countries. A lot of people want to learn English for moving to an English speaking country. That's why it's just important to emphasize different things in your marketing copy. Michal: Yeah. I would imagine. Okay. So I want to ask you about your process in localization specifically. Cause you said that you came at the beginning and there wasn't really a process, but then gradually you evolved it into something that can now more or less maintain itself. So you need a smaller team. So tell me a little bit about that. Anna: Okay, so when I came to the company, we didn't have any established processes. The only thing they used at the time was Lokalise for UI localization. We didn't have any vendors or freelance teams at the time. That's what I started with. I think that team is one of the most important things in localization, because everything else depends on how qualified your vendors are, how qualified your managers are. The quality of the end product will depend on that. That's why I started from the sourcing and testing and everything. Now we have a wonderful team of mostly freelancers, but we've been working with some of them for more than a year. They know the product thoroughly, and they know everything about it. So that's what I did. Next came the tools. As many other companies, we also used spreadsheets in the beginning. Everyone has that step in their processes when they use spreadsheets. Michal: Yeah. That's all we had, though. Wasn't it? It was, it was born out of necessity, I guess, because before we had of these tools, it was the only cloud based environment that we could use Anna: So we used Google spreadsheets as well. And then we realized that they are not reliable for localization. So we started using more translation management platforms. And after that, we focused on streamlining the process, we wanted to deliver all the updates in 24 hours. And we kept on adding new languages, so the time zone difference was a problem as well. So we optimized, now we can deliver everything in 24 hours, basically. So that's how all the processes changed. Michal: Let's talk about each of these. You mentioned people, vendors. You mentioned tools, and then you mentioned timelines. So first of all, people, because you said you found your team and you started working with permanent linguists. Which I agree is a really important part of it. Where did you find them? How did you get them to work with you permanently? Anna: So at first, we started working with people from Upwork. Because it was the easiest, it's super easy to hire people. But what we found out in the process that the quality could be very low. We couldn't guarantee we deliver the best quality. So we invested more time in hiring more freelancers. Who we could work continuously for a long time. And after that I also used Upwork and Proz, and also, I just Googled and used LinkedIn a lot to find the right vendors. So we tested them thoroughly. We just integrated a test processes with sample tasks that they had to complete before we had an interview. That worked like magic for us, we found a lot of very professional linguists who could do the work we have. And just... Continued working with them after that. Now we've got 30 linguists in different languages. We've got two people for each language and we usually double check everything. So the first person is a translator. Then the second person reviews everything. Our quality just went up after we integrated that. Michal: So you manage all the vendors yourself? So don't work with LSPs, you manage the freelancers on your own. Anna: I used to manage all the freelancers on my own for a long time. But now we've got a localization project manager as well because now the workload is growing and now I mostly do strategic planning. Michal: Yeah. And they manage the vendors. So that's great. And then you mentioned tools too. So you said you're using Lokalise for your UI translation. Anna: Yeah, we do use Lokalise for UI translation. And we use everything it has to offer inside, like glossaries and also... machine translation. Sometimes when we need to do things quickly, we use it, and then our translators review it, but not so much in UI. Michal: So why not for UI? What was your experience with that? Anna: Because UI is very content dependent. I think machine translation is just not the right tool for the UI localization. That's my personal opinion. I think the technology will develop and probably in the future, you'll be able to use it without any changes, but now it's more of a hassle. When you write or when you localize the UI copy, you have to keep the whole scenario in mind. Machine translation can't do that for you. That's why we don't use it for UI. Sometimes we do, but only for very simple things. Very simple titles when we have to deliver things very fast. We do machine translation, but we never release anything with machine translation without review. We review it with the translator and only then we can release it. I think machine translation works great for longer texts. For example, if you have a long article that is not too specialized, you can use machine translation, and then you need to review it anyway. And sometimes we just use it for educational content. When... It's not context dependent. Two years ago, I worked at a language learning game, and we didn't have a budget to translate the huge dictionary manually. So we used machine translation for the dictionary translation, and we asked our translators to review it. It saved us a lot of money because they didn't spend so much time translating every single word of that dictionary. Michal: How do your translators respond when you send them machine translation for MTPE? Anna: The first thing we do is we do the machine translation, and then we ask them to review it just very quickly. Just to assess it from one to five. And if it's four out of five, they just do the post editing. So... But when the quality is very poor... I think Hebrew, Arabic, Chinese, and all the Asian languages. Machine translations just can't cope with that. So we don't use it for all the languages as well. For French, for German, I think for Spanish, it would be very effective use it for them. so it depends. Michal: Yeah, absolutely. There's also, I think, sometimes other issues when you're using machine translation. Like in Hebrew, a lot of the times we have a gender issue because machine translation is trained on a lot of masculine form content. Anna: Yeah, that's right. Michal: And that's an issue on its own. Because, those sentences, even if they're correct. Changing them to non-gendered, it's like re-translating everything. I think it's more of a question of prioritizing. Once you prioritize a language, and you teach the engine to handle that language correctly, then you will get significantly better results. But you do need to say, okay, I want to focus on that language now, and actually invest time to understand what it needs, and understand how to adapt that. And I'm guessing there are languages that get the spotlight for now, because they have a lot more material and a lot more speakers. But it will change. Anna: Yeah, that's true. Absolutely. Michal: So let's get back to the process. When you localize. Who sets up the environment, who sets up the ICU syntax, who chooses the screens and imports them and exports them? Anna: Usually the dev team. It's important that the dev team creates the strings because all the titles are integrated in the app. We usually have the English copy as our source text. We first review it and check if it's correct, if it corresponds to the context and if everything is how it should be. And then we assign the translators from our team to do the localization of those strings. Michal: What kind of context do you provide? Anna: Oh, we try to provide a lot of context because that's... I think it's essential. So we screenshot everything from the app, or we also copy the screens from Figma and add them right in Lokalise as well. We also write comments for basically every string, if there is something that is hard to understand from the screenshot sometimes. Sometimes you have to divide the strings into small parts and they are joined together in the end. So you have to leave a comment about that. So that's what we do. We also have guidelines for our translators that they have to read before they start working with us. Like how they should deal with strings translation, how to use variables, how to translate the titles. Michal: So about the guidelines. You mentioned that translators need to read them before they start. Do you mean before they start every project or is it before they start working with you? Anna: No, basically, before they start working with us. Not every time. Sometimes we have to remind them of certain things because they just... Yeah. but it's not every time. What we add every time is screenshots and small comments to strings that can be hard to understand. Michal: Are these guidelines general for the company or are they language specific or locale specific? Anna: They are specific to certain types of languages. Like European languages have similar syntax, so we don't create separate guidelines for every language. And we have specific guidelines for RTL languages, for Asian languages. Some languages, we have certain instructions that we have to follow. It's usually with polite and impolite. So we have special that we want to emphasize. Michal: Do you also give guidelines on branding and things like tone of voice, or is it just technical guidelines on gender and formality and syntax and stuff like that? Anna: Yeah, we do. We've got a tone of voice file in Notion, where we state all the important points, how we want to address the user, and a small explanation: what our product is about, how people interact with the product and what they expect to see there, and also the level of formality we want to use and the forms we want to use for buttons and for different kinds of titles. Michal: Do you sometimes get feedback from linguists on how that tone of voice fits their culture or the language? Anna: Yes, we have a lot of feedback. In localization and in product development, nothing is set in stone. You can't create a file that will stay with you forever. You have to change it all the time. You have to edit things. You have to think of better ways to convey your message. That's why we usually ask our freelancers for feedback. We also do UX research and we talk with the users. So we got some insights from them. And after that we adapt our tone of voice to what they expect from us. We also look at the competitors and see what they use in different languages, and also use these findings to continuously improve our documentation and how we localize. Michal: Do you do UX research in all languages that you localize into? Anna: I don't think so. We only use this for... Our big largest markets mostly. But ideally that's what I want to achieve. I think every user deserves to read quality copy. I think that we try to achieve the best quality, but of course we have to work and do more research in every language. Michal: If you had gotten the budget now to do research in all of those markets. You don't have a lot of budget, but you do want to make an effort. So what kind of effort would you choose to get insights? Anna: One of the most important things you can do is to use your translators as a source of expertise in that language. Or maybe use your team members as well, because I think in international companies, there are at least a few people who can speak different languages. Ask them about the copy, go to whatever source you have... I'm also in a polyglot community, I'll just ask people to talk to me. I'll show them the screens, and they just give me a lot of feedback. I remember once, when we wanted to launch in Japan, I just opened the Polyglots Facebook group and created a post. I had a lot of people who commented. We had a call and we showed him the product and we had a lot of insights after that. And it was basically for free. So you can always find people to talk to. Michal: Yeah, definitely. And I like that you... instead of saying, oh, we don't have the budget, you said, okay, let's try something creative. Which I think is really great. Anna: Yeah, it's very important to be creative. Sometimes you don't have the process you don't have the people. Sometimes you are just a one person team. So you have to think of creative ways to solve problems that come up, to get better results. That's what we do a lot in localization. We also try different platforms to hire freelancers. We tried everything. Michal: Yeah, we should call it " localization hackers". Anna: Yeah. Michal: Try and find ways to do localization better if you don't have the budget or the time or the people. Do you have an example of a time when you made an effort as a company, you changed something in the UI or you made an effort in terms of how you guided the translators, and you saw real measurable improvement in performance? Anna: Let me think. if we talk about localization all your efforts pay off because you can cover more markets. I think when we localized to Chinese traditional and to Hebrew, we had the biggest return. If you find the right market you'll see the return. With the revenue, with downloads and with everything. I can't think of a specific example because localization is usually an iterative process. You come to the market with the first version of, localized copy, and then you don't see any return. But you do very small changes. And in a few months you see the revenue growing and you see the user base growing. Michal: I think it's probably one of the hardest things about localization. Is you can't really say, Oh, we did this effort from A to B. And then we saw improvement in performance subscriptions or something else, because it is, like you said, a very, very long term process. And there are a lot of little tiny improvements throughout, which makes it really hard to measure and really hard to prove the value of it. When you take a step back and you look at the longer process you can see there's definitely a significant improvement. Anna: Yeah, absolutely. Michal: So, okay, you mentioned that you managed to get all your requests answered within 24 hours. How did you make it happen? Anna: We used a lot of project planning. We did kind of audit to see what the bottlenecks are. In the beginning we had a very long turnaround time, like three or four days for basically each language, because we had a distributed team of freelancers working from different countries. So there is a huge time difference. We didn't know how to manage that. So we just sat down and looked at the processes and we found out that we assign the translators too late for them to start right away. Michal: Yeah. Anna: So we found those bottlenecks and we just started working on them. At first, we started assigning the translations as early as possible. And it worked great right away. And then we talked with the project manager and we changed the release processes a bit. The strings were added in the beginning, so we had time to review them in English, add all the context and assign them to the translators at the right time. And we also integrated some planning tools. We use Notion for the project planning, so we created a board where our translators could see all the tasks and the timelines and the deadlines. And we also just made sure they are available every day. We talked with them and discussed the workflows, and continued working with those who were okay with that, and wanted to work with us. Because it's important to be transparent in your communication. I remember we had translators who were not so used to UI translation, but they did the other translations perfectly, like articles and marketing copy. So they ended up procrastinating on those stuff. So we talked with them. It was a lot of project management. And... Michal: Yeah. Anna: And we also just invested a little bit of our time in automation. We started using Smartcat and Lokalise for different types of content. And we also used plugins for Figma to automate the workflow. So we just came to 24 hour turnaround time, you know, in 16 languages. Michal: Yeah. That's really impressive. You said there were some people who were not so inclined to do UI translation. Do you find that it also impacted the quality of the UI content that they created? Anna: Some of the translators are more proficient in certain areas. I think most of the translators do all kinds of translation work, but every person likes a certain type of tasks more than the other ones. Michal: Yeah. Anna: And now we keep on working with people who understand our product, who see the mission of our product, who are reliable in terms of deadlines and timelines and who just have a passion for their language. It's a pleasure to work with people who are like that. They ask a lot of questions. They always want to know everything about the feature and you just have very interesting chats with them about certain features and intricacies of their language. Michal: There are linguists who will do a lot of the work that you ask them to do, but the thing that they really do amazingly is marketing, or something else, maybe technical, maybe business, maybe medical. So I'm curious why you chose to work with one or two translators per language for everything, rather than split the linguists by their specialties and the things that they're really passionate about. Anna: We didn't come to that in the beginning, we had a lot of staff turnover in the process. In the beginning we had a small team of freelancers and they usually come and go and then you just find someone else. And after that we just found the right team for this kind of translation work. So they usually specialize in UI as well and in marketing copy. That's what we mostly have. And we also have translators who work on educational content, so now the teams are kind of specialized because we've got a team of freelancers who work on UI, and another team that works on educational content. Michal: I would imagine it even takes time to find those people because usually good translators are busy. Anna: Yeah, it takes a lot of time. Another approach could be: you find people who really want to with you. And you teach them everything. But it takes a lot of time, a lot of effort from the manager. Michal: Yeah, although I would imagine that if you invest in teaching your linguists, first of all, you get exactly what you need in terms of the training that they get. But also I'm guessing they are automatically more invested in working with you . Anna: Yeah. Michal: Because you gave them something as well. Anna: Yeah, that's what we do a lot. We think of them as our team members, but just those who work part time. It's important that they feel that they are the part of the team. They are developing with us. So I think it's very important. Michal: Yeah, I completely agree. So I have a question. Can you outline just the process looks, from creating the content in the source language and the design stage to having a completely localized feature out in production? Anna: So in the beginning, we just brainstorm, we look at the user story, and then we interact with the designers with the product manager a lot to come up with the design that serves the right purpose. The English language copy comes up at the time. When we approve the final copy, we usually try to gather all the context, the screenshots and all the comments and everything that we need to assign it to the translators. After we review everything, we create the UI strings and add the terms to the glossary. We've got a large glossary of crypto terms. We need to sometimes think in advance how to translate them because there are no direct equivalents in many languages. So that's what we do. We create new terms. We talk with the linguists about how we can translate those terms. We do the research. We look at the competitors at this stage as well. Sometimes when the features are very complicated, we have to talk with the developer team about the variables, about the plural strings, about the strings that are divided into different parts sometimes. So we have to look at that and talk with them about how we have to deal with them in different languages. Like Hebrew and Arabic and Chinese and all the others that don't use the Latin script. So we try to gather and direct all this information to our linguists, so that they understand the context. And then we localize the copy, the QA team checks everything, visual bugs and functional bugs. Sometimes we spot the localization bugs at this stage or sometimes before the functional QA, we do the linguistic QA, but it usually depends on how big the feature is. And after the LQA, we do the edits if they are needed. We correct everything and review everything and then it's launched. After the release, we also check it once again to see if it's okay. It's always double or triple checking. Localization is like that. You have to be ready for that. Michal: Yeah, absolutely. So if you could do one improvement, whatever you want. What would you have optimized? Anna: Well, I'm a big fan of automation in any process. As a strategist, I always think about how we can automate this. So I would integrate more automations in the process. The last one we did is... We've got 16 languages and we got app store pages. Michal: hmm. Anna: And We've got like 10 screenshots for each of the languages. And for a long time the process was, we translated all the copy from the screenshots, and then the designers manually added them. We had to first copy and paste those strings, then the localizers had to change them and check them and... It was such a daunting task. No one wanted to update the screenshots anymore. And it just left us behind. If you want to do marketing right, you have to update your assets. You have to do the experiments. So I just found the Smartcat plugin that helps you import everything from Figma to Smartcat. Then it adds the translations from your Smartcat project to Figma. You don't have to copy and paste anything manually. I'm always looking for the ways to automate things. So that's what I would continue doing. Michal: Yeah. Automation and optimization, right? Anna: Yeah. Michal: Just making things faster, I would guess, because even if it's not really automated, just having the busy work done for you can probably make everything much more convenient. Anna: Yeah, and it makes your people happier sometimes, those who do these daunting tasks, like designers and localization manager. They are more satisfied with what they do because they don't have to do those routine and manual work that's very daunting Michal: Yeah. Absolutely. Okay. Okay. Thank you for taking the time to share your process at LetMeSpeak. Anna: Thank you so much for having me here today. I hope it will be helpful for your audience. I would be happy to follow up anytime on the processes and on how the localization industry develops and talk about anything localization related. So that was great talking to you today. Thank you, Michal. Michal: I also want to thank you, the person listening to this now, for taking the time to learn more about localization. Localization has always had this gray kind of lackluster image, but it's got such a huge impact on the world around us. When we take the effort to make localization processes better and improve localized user experiences, we make a positive impact for users globally, and you are a big part of that. 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 all the most interesting conversations happen. And if you want to hear about new episodes of the Localization Process Pod... Be sure to subscribe on Spotify, on YouTube, or the Localization Station email list for updates. I was Michal Kessel Shitrit and this was the Localization Process Pod. Hope to see you again for another localization process review soon, and until then, have a great day!

Here’s something I’ve been thinking about a lot: can we utilize the benefits of a design system in localization, too? A localization content design system, if you will? But OK, let’s start from the beginning. What are design systems, and why are they valuable? About design systems A design system is essentially a collection of reusable components, guidelines, and standards that ensure your user experience will be cohesive across different flows, platforms, and products. Maintaining consistency is hard, and the more your team and product grow, the harder it gets. Design systems make consistency possible. A big advantage of design systems is that they eliminate the need to recreate design elements from scratch, and so they save time and effort. They also promote consistency in visual design, interactions, and user flows, which ultimately leads to a better user experience. When you have a design system, there’s less discussion over how each component should look and ‘act’ when users interact with them. You can onboard new team members easily, and have a clear framework and references for design principles and best practices. And with everyone having access to the same set of design assets and guidelines, teams can work together more effectively and ensure that the final product meets the desired standards. Design systems also contribute to scalability and flexibility. Teams can quickly adapt and iterate on designs without sacrificing consistency since changes to the design system impact the components based on it. And from a cost perspective, those time savings naturally lead to significant savings in operational costs. Often, design systems include some reference to content – especially in the documentation. Style guides and brand voice guidelines were used to try and ensure consistency. But content was just a small subsection of a greater system, focused specifically on experience and UI design. About content design systems Once we discovered how helpful design systems can be, content designers’ interest started to pique, too. Better consistency? Better communication? Quick iterations? Yes, please! But here’s where things start to tangle. Because components can have a preset design, but content is hardly ever identical. Initially, teams started using content design systems to pull all their content-related guidelines and documentation in one place. For example, the content design system at Intuit has a glossary, guidelines on inclusive language, a voice and tone document, and some formatting instructions. The Material design content design system also includes some instructions on accessibility and a style guide with grammar instructions. It was a nice way to start, but guidelines and documentation are not new in any way. And so some teams started considering ways to offer more value through their CDS – reducing friction for writing teams. They examined their processes, discovered repeatable, scenario-specific components, discussed them, and documented their final decisions. For example, the design team at Deliveroo described how they set a pattern for their error messages, making sure that they are always: Explaining what’s happened IIviting users to try again, or Giving them the option to discard the action and “Go back”. (Seriously, read their article. It’s excellent). Source: https://medium.com/deliveroo-design/content-design-systems-need-you-82836afb4fe6 The best part of a CDS is that, ideally, you only have to think about each component once. Then, you can plug in new information and get a new error message, or success screen, or splash screen at any time. These patterns are only useful if they’re rooted in real-life scenarios. Content design systems need to be extremely specific to the product, flows, and audience content designs and UX writers will need to deal with. Should you create a localization content design system? In the context of localization, design systems can prove to be even more valuable. By design, there’s always a rather high level of entropy in localization. The high number of people involved, combined with the fact that not all people can read and understand the content created, means we’ll never get to 100% control. But just like a content design system enhances predictability and consistency for UX content, a localization design system can help us enhance predictability and consistency for localized UX content. Advantages of a localization design system Ensure consistency. Oftentimes, similar components are localized in different times, by different linguists, and/or with minimal context, causing consistency issues. A localization design system ensures components are consistent for every language, not just the source. Streamline onboarding of new linguists. With a clear framework and references, new team members can quickly understand and contribute to the localization efforts without compromising consistency or quality. Keep localization scalable and flexible. Teams can easily create new versions of components without having to rethink every localization challenge from scratch. The fact that decisions are already made and common issues handled helps keep things efficient. Remove friction. When localizing content, there is often a need for clarifications, queries, and back-and-forth communication. With a well-defined localization CDS, many of these queries and issues can be preemptively addressed. Speed up localization. Instead of recreating design elements from scratch for each localized version, teams can leverage the components already defined in the design system. Help with tracking and improvement. Having set components gives localization and content teams a starting point to measure and assess localized content. Tracking performance for these components can give teams an idea of the quality and efficiency of each localized experience. Disadvantages of a localization design system Requires preparation. Setting up a comprehensive localization design system requires substantial initial effort and time, which can be a challenge, especially for teams with limited resources or those already stretched thin. Requires buy-in from managers. Convincing upper management of the need for such a system is critical. Without their support, it may be challenging to get everyone involved to implement the system. Requires collaboration from everyone. You’ll need the cooperation of in-house teams, language service providers (LSPs), freelance linguists, and more. This level of collaboration can sometimes be hard to achieve. Correctly implementing a localization content design system Remember, building a localization CDS is a means to an end, not a destination. This system is a tool meant to empower your team to make better content choices in every language. Keep that goal in mind as you create it. Create language-specific versions of the style guide and voice guidelines Start by tailoring your style guide and voice guidelines for each language. This ensures that the linguists creating the components - and those using them later - are familiar with these requirements. Since each language and culture has its unique challenges, you can use these guides to address them without overloading the general style and voice guides. For example, you’ll discuss the formal vs. informal dialect in a Croatian style and voice guide, but you won’t mention it in English, as it doesn’t have formal and informal forms. Develop a glossary of repeatable terms from your UI A comprehensive glossary is critical if you want to keep consistency in localization. For UX, it also ensures your users will be able to find their way in your product. This glossary should include tab names, UI terminology, and industry jargon, as an example. Make sure you keep this glossary up-to-date. Of course, if you change a term down the line, have your linguist change it across the product. Start creating your localization content design system components If your company already has a CDS Collaborate with the UX and design teams to localize the content design system components they have already defined. Before you start working with your linguists on this, train them to effectively use and apply the principles of the CDS in their localization work. If possible, give them some UX training, as well. Especially when localizing CDS components, ensure your linguists have as much context as possible. Remember that the quality of these components will dramatically impact the quality of all localized content based on them. If your company doesn’t yet have a CDS Work closely with UX and design teams to create a content design system from scratch. This involves defining the core types of components you’ll want to replicate, creating content templates, and localizing those. Since you’re starting from scratch, you can use this opportunity to ensure that the system will be flexible enough for different languages. Verify that the layout has enough space for localized content and that the typography chosen works for all languages you’re localizing into. If you can, create RTL versions of your LTR components, too. Use your localization content design system When sending content out for localization, ensure your linguists have access to the relevant CDS components and can use them as a reference. If you’re using a CAT tool you can upload each component as a context screenshot for the relevant string or attach them in your handoff to your linguists. Remember: placeholders in a CDS are there to support content work and help writers and localizers understand what they should include. Do not concatenate your content or separate a placeholder from its line before you send this content to localization. This can result in significant usability issues. Each component should come with a clear explanation of its intended purpose and what it should contain. This way, your linguists will know what they need to pay attention to when localizing. Monitor your system and iterate Just like a design system and a content design system, a localization content design system should never be static. Keep your LCDS up-to-date. When the UX content design system gets an update, ensure this update is localized to all relevant languages, too. From time to time, ask your linguists for feedback and ensure LCDS requirements are actually implemented into the localized product. This iterative process will help you adapt to your team and company’s changing needs.

Let's talk about four brands that executed impressive localization strategies. Ones that are so well-thought-out and inspiring, we can all take a minute to learn from them, too. We already know that a company's localization strategy takes into account much more than translation. It needs to be creative, bold, and inventive, producing assets and initiatives that resonate with audiences worldwide. To account for the cultural nuances and generate real connections. It's not an easy feat, but when done right, localization can help a brand tap into new markets and find significant success beyond its home country. Today I want to discuss four brands that executed impressive localization strategies. Ones that are so well-thought-out and inspiring, we can all take a minute to learn from them, too. Let's dive in, shall we? Examples of localization done right 1. Coca-Cola Coca-cola worldwide As a true staple in almost every supermarket aisle around the globe, Coca-Cola is no stranger to localization. In over 100 years of activity they've perfected this art - successfully creating a presence in more than 200 countries. In 2000, their then-CEO Douglas Daft cemented this position by introducing a new localization and marketing strategy for the company: "think local, act local." In each region where they operate, Coke creates ads, social media posts, packaging, and even products that reflect the local culture. The coca-cola localization strategy Coke's localization strategy is evident when examining its localized marketing materials and offering. In India, for instance, the company created different regional variations to attract local consumers. Rather than have their labels in English, they rolled out Bengali labels in West Bengal. They also launched unique local drinks, like Vio spiced buttermilk and Minute Maid Nutriforce. Source ‍ In China, Coke uses a Chinese name on its packaging to appeal to consumers and features celebrity icons and cultural references. Their ad strategy made use of some unique Chinese practices, too. For example, a few years ago, the team at Coca-Cola discovered that Chinese teens communicate through a series of codes containing numbers, emojis, and graphics. And so, they featured 35 of those codes on their labels. The company calls this their "hyper-localization" strategy - which means they're doing much more than simply translating their marketing materials. Understanding each country's culture and customs lets them appeal to a broader range of consumers. What does Coca-Cola do well in its localization strategy? • Adapted visuals and concepts Coca-Cola's localization strategy is evident not just in the words they use but in the visuals they create. They incorporate colors, graphics, and cultural references into their ads and packaging, making their products more relatable to the target audience. They also work with local ad agencies to create advertisements that resonate with people - rather than try and nail down a marketing strategy remotely. • Local product variations Another way that Coca-Cola does marketing localization is by creating different product variants for each region. Like the Vio spiced buttermilk, tailored to the Indian palate, they launched herbal infusion drinks in China, cream soda in South Africa, and ginger drinks in Australia. • Original marketing assets When creating its marketing materials, Coca-Cola does more than translate English ads. Instead, their localization efforts include investing in local actors and actresses, original soundtracks, and local designs - all to give people the feeling that these ads were created especially for them. This focus on localization has led to some of Coca-Cola's most iconic and well-loved ads, which is a big part of what makes the company successful in its target markets. • Local manufacturing Coca-Cola has manufacturing facilities in many different countries, which helps them keep their logistics costs down and reduces their environmental impact. It also allows them to create products tailored to each market. They can work with their employees to experiment with different flavors and ingredients, getting feedback from people directly in their target market. What can Coca-Cola improve about its localization strategy? • Be sensitive While Coca-Cola's localization strategy is largely successful, we mustn't forget they are a massive international force. If people see their marketing efforts as inauthentic, they could do more harm than good. The company should be extra cautious not to step on any tows - something that's incredibly hard to do without in-depth cultural knowledge. • Take an active part Rather than staying on the commercial side, Coca-Cola can contribute with outreach programs and additional community development initiatives in the countries where it does business. This would help to build positive relationships with these communities, and could even lead to increased sales as people come to see Coca-Cola as a company that cares about them and their wellbeing. 2. Netflix Global content localization Netflix is perhaps best known for its original programming, tailored to fit the unique tastes of each region. By investing in local filmmakers and creative talent, they've been able to create content that's popular with viewers worldwide, generating lots of buzz on social media. Netflix's algorithm also supports its localization efforts: It automatically customizes the thumbnail and imagery displayed for each piece of content, so it naturally adapts itself to the preferences of each locale. Source But that's not all their translation and localization team does. Netflix gives users in their new markets a truly native user experience - putting a lot of effort into creating an interface in their language and providing translated content through subtitles and dubbing into multiple languages. Quality management at scale In 2017, they even launched the ambitious Project HERMES - an attempt to design a standardized testing system that will allow them to generate high-quality subtitles on a massive scale. With so much translated content in their catalog, their localization department needed to control the quality of the translators they work with. But in 2018, Netflix reported that HERMES was shut down - saying that the task was "best left for the experts." On top of being a good business decision, Netflix's choice to go global and support foreign creators tremendously impacts cultures worldwide. The syndicated, programmed TV of the 20th century made American culture an attractive "norm" to aspire to in many countries. But with the advent of multi-national television - thanks to streaming services like Netflix - American culture is no longer the only option on the table. Viewers worldwide can now choose from a variety of content that reflects their cultural values. This is good, as it allows for greater diversity and understanding. Paolo Sigismondi wrote a fascinating article about this here, which I recommend reading. What does Netflix do well in its localization strategy? • Original international content ‍This has helped them appeal to a broader range of viewers and also nurture a more personal connection with their global audience. As a plus, they were able to support smaller creators and bring great TV to people around the world. Win-win for localization! • Localized user interface Netflix did an excellent localization job on their user interface, too. It improved their customer experience, making it significantly easier for non-English-speaking viewers to use the app and find the content they wanted. Source ‍ • localized marketing strategy Netflix also did a great job of marketing its original content. They used targeted ads and social media campaigns to reach specific demographics globally. The audiences in countries where these shows were created take pride in heading the Top 10 charts, generating even more buzz around those new shows. • Flexible pricing models Netflix also did some localization with its pricing, tailoring its subscription plans to fit each locale's income levels and preferences. So while Denmark customers pay an equivalent of $11.50 per Basic subscription, in Brazil, they pay $5.50, and in Pakistan - $2.50. • Subtitling and dubbing The Netflix localization team has done an excellent job of subtitling and dubbing a considerable part of its content catalog. This has helped them reach a much wider target audience, as not everyone understands or enjoys English-language content. What can Netflix improve about its localization strategy? • Invest in subtitle quality Despite their ongoing efforts with the HERMES project, Netflix subtitles often get bad user feedback. Some went as far as saying that Netflix should focus on fewer languages to invest more effort into improving the quality of its subtitles. With such an extensive content catalog, it's understandable that some subtitles will be of poor quality, but this area could use improvement. • Avoid inaccurate cultural depictions Another issue that has come up is the question of cultural accuracy. In some cases, Netflix's productions have been criticized for their inaccurate depiction of foreign cultures. For example, the show Narcos has been criticized for its portrayal of Colombia, which many viewers found stereotypical and inaccurate. And Emily in Paris was panned for its patronizing depiction of the French culture. It's certainly a problematic issue and something that Netflix should be aware of. 3. McDonald's Fast food localization As one of the biggest fast-food chains in the world, it's no surprise that McDonald's has a significant global footprint. Wherever you choose to travel, the company has a restaurant there waiting to serve you - with over 32K restaurants in over 117 locations. But their massive global growth isn't a fluke - it's a result of a carefully-crafted localization strategy. Source Unlike Coca-Cola's hyper-localization approach, McDonald's localization treats the world as one big, international target market. But while the golden arches are always there and the core characteristics of their chain restaurants remain the same everywhere, there are always original touches that make a huge difference. Marketing materials, visuals, and packaging get a local version that's often very different from those well-known designs in the US. In fact, the company likes to launch new, exciting menu items in their global branches. Diners appreciate that their favorite food is featured at McDonald's, and tourists treat these unique items as a draw when visiting from other countries. Source What does McDonald's do well in its localization strategy? • menu localization McDonald's did a great job tailoring their menu items to each country's tastes, cooking up their versions for all-time favorites. There are infinite examples of this: From iced milk tea in Hong Kong to the Cordon Bleu Burger in Poland, and from the McRice Burger in Indonesia to the Spicy Paneer Wrap in India. Source • Brand flexibility Another thing McDonald's did well was adapting its brand identity in their branches around the world. This is evident in their local marketing campaigns, staff, restaurant decor, and more. They even embraced local architecture by setting some of their branches in historic buildings and traditionally-designed structures. • Worldwide familiarity McDonald's maintains a sense of consistency and familiarity for their customers everywhere. There are certain items you'll always find on the menu - from burgers to sundaes. People often appreciate that, as it gives them a sense of comfort and stability no matter where they are. Additionally, this helps to build global brand loyalty among McDonald's customers, who see the chain as a global institution that they can rely on to provide consistent meals no matter where they go. What can McDonald's improve about its localization strategy? • Provide the whole meal experience While McDonald's developed its versions of local dishes, they were often flat representations of the local meal experience. For example, in many Asian countries, a meal is usually made up of various dishes eaten with noodles or rice. While I'm sure McDonald's Tsukimi Burgers taste great, they don't quite fill the same culinary slot. It would be great to see them reinvent their international menus, providing a more authentic and complete meal experience for those foreign markets. • Tailor more than food McDonald's built its business on fast, cheap items you can grab on the go - a very American approach to dining. But in many cultures, dining is a much more leisurely affair, and people often want to sit down and enjoy their meal in a relaxed setting. In other countries, the service expectations people have of a dining establishment are significantly different. Adapting their restaurants - and menus - accordingly may help them assimilate even further into their international target markets. • Respect its host countries At McDonald's, even local foods get the brand treatment: A Chilean dish of breaded chicken and guacamole becomes "McPollo," and a Norwegian salmon-and-dill-sauce sandwich is called "McLaks," for example. This familiarity can be comforting - but it can also be seen as appropriation, with the brand absorbing the unique foods of these markets and generating its flat version of them. It would be nice to see the company step out of its comfort zone, serving local dishes without transforming them into its fast food variant first. Source 4. Ikea Local brand, global presence Ikea's successful localization strategy helped it expand into new foreign markets. With the help of a team of translators, Ikea translates its offering, products, and marketing materials so that they are relevant and relatable. The company also localizes its website, ads, social media, and catalogs to be culturally appropriate and easy to understand. However, in a very strategic choice, the folks at Ikea chose to leave all product names in often-unreadable Swedish. This choice works in their favor, creating a fun, memorable customer experience. What does Ikea do well in its localization strategy? • Enviable atmosphere Ikea sells more than furniture - it sells a dream. Their showrooms are filled with micro-spaces, with every bit of detail carefully placed to make customers feel at home. These decorated rooms, with their warm, inviting look & feel - in-store and online - encourage visitors to copy the clean Scandinavian design in their homes, too, no matter where they are. Ikea catalogs even became coveted reading material in some markets, and they're displayed in living rooms worldwide next to reputable home decor magazines. Source • Consistent branding Ikea dropped any semblance of assimilation in favor of an "imported from Sweden" edge. No matter which store you visit, you'll immediately get recognizable Ikea vibes. The decor is similar; the signage is always the same; the colors are consistent. They even sell the same Swedish food products in-store - from cookies to preserves. Customers don't come to Ikea for local furniture. Instead, they come for that unique foreign customer experience and for decor they can't get elsewhere. Source • Consumer content The Ikea community developed a hobby around the global brand: "Ikea hacking." Ikea furniture is known for its durability and versatility, and there are plenty of affordable options to use as raw material. This led to the development of a culture where people find creative ways to use it in their homes, creating bespoke-looking furniture from the simplest pieces. Some of the most famous Ikea hacks include transforming essential pieces like cabinets and dressers into built-in furniture, using Ikea furniture to create custom storage solutions, and using the company's inexpensive accessories to add personality to a room. These hacks generate buzz worldwide, making Ikea a household name. Source • Language-free manuals The high-ups at Ikea likely planned for globalization, creating a recognizable illustrative language for their manuals. This allows them to provide customers with clear assembly instructions without translating every word. A brilliant way for Ikea to ensure that all of its customers can understand how to put together its furniture. Source • Small adaptations While the Ikea brand stays consistent everywhere, its product offerings vary slightly. This allows them to appeal to a broader target audience, as they can tailor their products to fit the needs of each specific foreign market. For example, for the Indian market, Ikea designed outdoor furniture that will withstand high heat and humidity. And for Korea, they released a wide range of small beds and sofas to fit smaller apartments. These minor tweaks help make Ikea products a staple in every home, growing their large fanbase even more. What can Ikea improve about its localization strategy? • Local collaborations Ikea has done a great job at localizing its products and materials to fit the needs of its consumers. However, they could improve their localization strategy by collaborating with local designers and manufacturers in each target market they expand into. This would help them create products that are even more relevant and relatable to local consumers, while also building stronger relationships with local businesses. It will also enhance their eco-friendly & sustainable brand promise, setting them apart from other furniture retailers. • The human touch While Ikea's furniture is undoubtedly popular, the brand can come off as somewhat plastic-y. The cookie-cutter quotes plastered on the showroom's walls and the uniform furniture you see wherever you go... don't scream 'authentic.' And the bigger they get, the more noticeable that's going to be. Working with artists and designers in every country would be a great way to lend some warmth to their brand. For example, Ikea stores worldwide could sell framed prints of local artists or host special concerts and events in the showroom. This would help customers connect with the brand on a more personal level. Does every company need a localization strategy? No, but it can give you an edge when tapping into a new foreign market. When you localize, you can connect with customers on another level, building trust and credibility. Assuming your original marketing would do the trick can damage your brand's image, and you might lose out on potential customers. So if you're looking to expand your business into new territory, it's worth considering planning your marketing localization strategy ahead of time. That being said, keep in mind that smaller brands just getting a feel of new markets can postpone their localized marketing efforts for a bit, and get away with a one-size-fits-all marketing strategy in the short term. And in some cases, if you don't have the time and funds needed to do it right, it might be better not to localize. Whether to invest in your localization process right now depends on the brand and the product or service you're selling, the market you're getting into, your brand image, and a boxful of other considerations. If you're unsure, set up a consultation with a local marketing agency. They'll be able to help you figure out if localization is suitable for your brand, what your localization needs and goals are, and how to go about achieving them. Thank you for reading! We hope this gives you a better understanding of the importance of localization strategies in marketing, and how some of the big ones successfully implemented it in their business.