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!

Last night I was a guest at Nimdzi Live, talking about bringing UX and localization teams together (👈🏼 Click there for the recording). We covered a whole bunch of topics. Like: 🔵 What even is brand voice, and why is it so hard to keep it in localized content? 🔵 Why should localization and UX teams stay in touch? 🔵 Why should everyone in localization learn the basics of UX? 🔵 What will the role of localizers be with AI-generated UX content? But we also covered a question that's been bothering me for a while: Is there a place for LSPs - localization agencies - in today's UX localization landscape? It used to be that the value LSPs offered was in managing the process and bringing in the linguist. But nowadays, tech clients buy their own loc platform license anyway, and it's much easier for them to find linguists across the many social networks and directories available. It's still a hassle, you'd say. And you'd be right. But the fact is that having someone else source your linguists and manage your processes has proven itself as a poor strategy for UX teams. To put it simply: The results are bad. The content is generic at best. And you can kiss your brand voice goodbye. Does this means LSPs are obsolete? No, it doesn't. It just means they need to find a new way to offer value. And for agencies hoping to work with UX teams, that starts with learning about UX. Why? 🔵 You can't claim to support UX localization without understanding what good UX means, i.e. what you're expected to provide. 🔵 You can't figure out how to offer value without understanding what your clients need (in this case, UX teams in software companies). And yes, I have a UX workshop for LSPs opening in just 3 weeks - but this isn't a plug email. I have my ideas, but I'd genuinely love to know what you think here. What kind of value can LSPs offer to UX teams in 2023? I'm here for your replies and your questions, Michal

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.

In honor of Pride 2023, we've invited the brilliant Kinneret Yifrah to talk about gender-neutral writing in UX. After writing gender-neutral guidelines for all government products in Israel, Kinneret shares her unique insights and experiences on the importance of gender-neutral language in UX and the challenges and potential solutions in implementing it. This video is in Hebrew, but don't worry if you're not a Hebrew speaker, we've got you covered with English subtitles. Scroll on for the full English transcript. Video [Hebrew with English subtitles] Transcript Michal: So how are you? Kinneret: I'm very good! And you? Michal: Great! So, because we're recording this, and it's going to be public, I'll do an introduction, even though it's just you and me in the conversation. Kinneret: Go ahead, go ahead. Michal: So the reason we met and arranged this meeting is because this month is Pride, and I really wanted to do something related to non-gendered language, non-gendered writing, specifically in UX writing. And because I'm in the localization space, I really wanted it to be available to the international community, because I feel like there are some gendered languages that deal with it heavily, like we do, we talk a lot about non-gendered writing, and I feel like there are languages that don't focus on it as much, and it's not as present in the conversation, and mostly there's less talk about the how - How much of it is possible, is it even possible. And the spaces that deal with how to localize, or how to write, and don't deal with the writing itself, like, not the writers themselves, they deal with it even less. Kinneret: What do you mean by how you do the writing, and not the writing itself? What does "how" mean? Michal: For example, if you're a project manager, managing some kind of process, writing in several languages or even in one language, so – especially if it's several languages – you don't understand HOW to write, you don't understand what it MEANS to write in a non-gendered way. Often you just know it's something you should do, and if your client isn't asking for it, you're not going to focus on it too much, because it's one more thing on your mind. Kinneret: Okay. Michal: And we don't really talk about how we can lead processes like this, how do we make them happen, how... I have all kinds of questions for you about that, but we don't really talk about these processes over time, and how they work. We just say it's something that should happen, and let's all be inclusive, but we don't talk about how to implement it. Kinneret: Yes. Michal: That's it. So that's why I really wanted to meet and talk about it, especially because you led such a comprehensive process, so in-depth, which also had, at least from where I'm looking, very significant implications on how we write in Israel in general, in UX, and how our government offices look online. And I would love it if you could start by talking about the project itself, and what it included... Driving change towards gender-neutral writing Kinneret: So there's a voice and tone guidelines for the government, which I wrote together with Digital Israel, which is now part of Digital Operations. And in this project, we included – and it was very clear that we were going to include – a chapter about equal writing, about writing for all genders. Writing microcopy for all genders. And we wrote this very comprehensive chapter, and there's a bit of a change, and I can't take all the credit for it. And in a bit when we'll talk about how things like this come to be, how organizations... how there are organizations that do it, and organizations that don't, and what the difference is between them, I'll talk about what I think was the driving force behind the change. So I really can't take all the credit for this change, there are others, like Daphna Eisenreich, who are leading a very, very big movement of change, and there was Michal Shomer's book, Non-Gendered Hebrew, which also made a very big difference, that word: "Welcome" that applies to both genders at the same time. Just people seeing the word "welcome" for both genders everywhere, including at the entrances to government offices, already makes people aware and creates a change, and people think about it, and... So that's about the government. There's the voice and tone guidelines for the government, and it contains rules on writing for all genders, government offices do recognize that and use it, and it did make a difference. I can't say that it's the only thing that made a difference. It was a big part of it, but just a part still. But in general, writing equal UX copy for all genders started because digital products started talking to users. They're now more than a machine referring to itself and addressing itself, they address the users directly. This happened in the past seven or eight years, a conversation came to be: between the product and the users. Both male and female. When we're speaking out loud in Hebrew, we don't have a way to refer to both in one word, so we have to choose. And that's when the problem started, because, in gendered languages, where nouns are either masculine or feminine, we need to know the gender of the person we're addressing to speak to them. At least in a personal way. Now, for government digital products – there are 3,000 products. So even if they would change some of them, even if they would only change the new ones, it'll be extremely hard to go back and change all of them. So some would stay as they were, some would change, the new ones are different, the new products are already being launched with non-gendered language, and we'll cover this soon, they are even sometimes launched in a way that lets men and women choose how... they're actually asked at the start how they would like to be addressed, we'll talk about that later, how to make that happen... So yes, there's progress, a lot of progress, but I don't think they'll ever be able to go back and change all 3,000 products, I think it'll apply to products from now onwards, not retroactively, like a lot of transformations that take place through big processes like this. Michal: So when you say that you decided to include a section on non-gendered Hebrew in the voice and tone guidelines, who was the one deciding? Who was involved in that decision? Kinneret: That leads me to the first and - in my opinion - most important factor in whether it's going to happen or not. Whether our product will have equal language or not. The biggest question is this: Is there someone who owns that in the team. This is where it starts and ends. If no one in the team owns that part, someone who really cares about this thing and is willing to fight for it, it won't happen. In my case, the one leading the entire voice and tone process with me, together, was Liron Libskind Mulyan, who was then at Digital Israel, today he's no longer there today, and he cared about it a lot. Deeply cared about it. He wanted there to be a section on it, I wanted there to be a section on it, of course, I had a partner to help me with it inside Digital Israel, and that's why there was a section on it. Of course, during our discussions and conversations, as we wrote the voice and tone guidelines, we got everyone's agreement, and we discussed this with everybody, and we led this process, but there has to be someone within the team who really has a passion for it. A bit after this I wrote Avodata, which is a product by the Ministry of Labor, and there, too, you can browse through professions, it's a product that makes all professions and learning pathways available to young people – not just young people, to anyone who's at a professional crossroads or facing a big professional decision. And the person who led that was Evyatar, who found it very, very important that you will be able to view all profession names in both male and female forms, that you will be able to view the masculine and feminine form of engineer, the masculine and feminine form of architect, the masculine and feminine form of teacher. Actually, teacher reads the same for both. But nurse - masculine and feminine. Right? That all those professions that are stereotyped as meant for men or women, will be there in both male and female forms. He led it, he cared about it, he was the owner of the product, he acquired the resources needed to get it done, he motivated people to do it, and he made a product where you could choose how you wanted to be addressed. He later added a questionnaire, and in it, you could also choose if you wanted to be addressed as male or female. So there was someone who cared about it, who got the resources for it... There were development resources needed. It's a financial investment. There's a financial cost. And when there's an owner, it happens. That's really the biggest thing I can say about whether it's going to work. It'll work when someone really cares about it within the team. And that's what happened in Digital Israel, in fact. Liron and I were there. And both of us really cared about this. And every person we talked to in the various government offices, we got them on board, too. We talked to a lot of people in government offices for the voice and tone guidelines. Obviously, as it represents the voice of the entire government. And... We got them on board, we got confirmation, and it went in. But that was led by people. A man or a woman who cares, that's the secret, if you ask me. Getting everyone on board Michal: But did you also face resistance? Kinneret: No. Michal: Really? Everyone just accepted it, despite the additional investment, despite the additional effort, it was just kind of obvious that this is what you're going to do? Kinneret: No, so in the voice guidelines, the directive is just not to write in the masculine form, and it includes all the "usual" methods to avoid the masculine form in Hebrew. How to write in a way that's equal for all genders. At Avodata, we did need development resources because they split the interface so that you could choose how you wanted to be addressed. For that, you need development resources. You don't have to go that far. They could have written male/female engineer. I mean, there are other ways to do this. They wanted it to be top-notch, so they did it this way, but you can also do it without a development resource. You can just write in non-gendered Hebrew, without using development resources. Using all those techniques that we know, with the letters ך and ה and all of those. Michal: Now, I want to ask... From my experience in projects, both in government office projects that I did personally, but also in other projects... You write the voice guidelines, and the initial copy for the product, and everything looks nice and shiny, and then it goes out into the world, and they suddenly need to add a line, or need to add a headline, and someone adds it in quicklty... you know. And all sorts of things go in that you didn't mean to be there. So how did this go? I mean, did the guidelines succeed in implementing or preserving writing for all genders? Or was it... Kinneret: No. I mean, it's exactly the same thing. A product that is written... you described exactly what happens. The product that is written according to the guidelines, the big initial mass is really gender-free, and then all kinds of things come in. So yes, you're asking about things that happened after I was done, or when I wasn't there to write them, some of them really are in masculine form. I think it's very noticeable that it's different from the other copy in the rest of the system, but I guess the general public doesn't notice this as much as we do. And it stands out, it does a little bit. But... But you know how it is. When you're a writer, not everything will go up. Not everything I write goes up. So in this case, it was really about the gender, but it's something I'm letting go of – because I'm a freelance writer, and not in-house. If you're writing in-house, you can keep track and follow up after that, and fix and improve. As a freelance writer, I submit the content, I cross my fingers that it'll all go live, including error messages. Somehow those are the ones always left out, but I'm a bit used to it, that they change a bit after I'm done, and turn informal words to more formal ones, and then it sounds too formal, and I guess I'm a bit used to it already. Michal: Yes. I have to say that... It's part of a different conversation, but... That's a big part of writing microcopy, giving it to people, giving them the content. It's an exercise in giving up control, right? Because... it'll never end up the way it was meant to be. It's true for copywriting too, by the way. Not just UX writing. They always make changes, and then you're like... cringe, you have to hold yourself back from sending them an angry message. Kinneret: Absolutely. Absolutely. A while ago a friend sent me a screenshot, and she asked me, "did you write this?" It was in the government "My account" zone, which I also wrote a big part of. So "did you write this?" And I told her, it really sounds like me but I would never write "due to". So something doesn't... something doesn't add up. And that's what happened. They turned my "because of" to "due to". They thought it was too low-brow, "because of". You know? It was really funny. But what can you do. Michal: It's like when someone sends you a project you did, and you have the urge to write, yes! I wrote this! ...but they changed... they changed things since then. Kinneret: Exactly. In your portfolio we need to use what we wrote, and not what was actually launched at the end. Michal: In my early days I'd take screenshots. I'd save screenshots so that I'd have fresh versions, before they'll make their changes. But if we go back to the topic, I'm interested to know, because I've actually seen, in the past years, a certain movement, that when you talk to clients, government or otherwise, it comes from them, a little bit. They do want it to be non-gendered, sometimes they don't notice that it's gendered. It's like a sense you need to develop. Right. But they do want it. And the question is, do you think that this movement is linked to this stamp of approval that these voice guidelines became? Because it is a significant, very formal stamp of approval. Making this possible. Kinneret: I'm not sure everyone knows the government's voice guidelines. We do, in the community, we've heard of it and work with it, but I don't think most of the clients asking for non-gendered language do it because of the government voice guidelines. I think it's very much connected to the work of Daphna Eisenreich, Dabru Elenu, and she is very, very public about it, and it's always talked about, and... I think it's much more connected to our work in the community, and to Dafna's work, and Vered Huri's work, who's also working on it, so there are a number of activity centers, who are in contact with very large customers, with very large organizations, who do this work, and drive this change. I'm not sure it's linked to the government's guidelines. And I think it's these actions that drive the change, and it's now... It's now considered unreasonable to write in the masculine, it's considered old-fashioned. But it's several actions that made this unacceptable to write in the masculine. It's going to be shared in some group, in Dabru Elenu, in Kinneret's group, it's going to be shared somewhere, and they'll talk about you, if you write in the masculine. So I think that's what... At the end, that's what drove the change. That... That it's unacceptable. That it's not OK to write in the masculine. And... It's very welcome, in my opinion. But I think that's it. It's true that the government guidelines makes this more official, but I think it's actually from the ground up, and not from the top down. That is, the fact that the field doesn't accept it anymore is what makes the people in charge and brands reluctant to be in the spotlight like that. Not be those that get criticized in the groups for writing in the masculine. Michal: Although, I have to say that this... Israeli brands, being from here, naturally care more about what the Israeli public thinks. But for international brands, we're just a dot on their global growth map. Right. And so they don't care about it as much. It's not something that's on the agenda at all, because it's like, it's just ten million people living in this small country, and we don't care if it's gendered or not. Or what they think of us. Kinneret: Right. But I think what big brands don't understand is that those who localize into a lot of languages... it's not just Hebrew. It's the full ten million, because Arabic is also gendered, So it's anyone living in Israel. but it's not just that, 40% of the world's population speaks a gendered language. So if you create the infrastructure that allows you to split your copy by gender, you'll be able to adapt the language to fit 40% of the world's population. So this platform isn't for ten million people, it's for 40% of the world's population. I'm not going to calculate how much 40% of the world's population is, but I think Arabic speakers alone are around 300 million. Michal: That's right. Though there are some problems here because gender comes through differently in various languages. Creating the infrastructure Kinneret: Yes. But if they created the infrastructure that allows me to choose how I want to be addressed, they wouldn't even have to create their copy using non-gendered language. They could write in the masculine and feminine, and maybe even in a third gender, if possible, and that's it, you see? So creating the infrastructure, which they did, by the way, in both Android and iOS, there's already the option to split by gender. We can talk about that later. So if you made it possible to... if that becomes common practice, to write two or three strings for each spot, masculine and feminine, and a neutral form if it exists, that should be the common practice, and you wouldn't need to force non-gendered writing. Although in Hebrew we're stuck because we only have two genders, and what will we do with the neutral form? We're still stuck. But even if we only have two genders, and I can switch from one to the other at any time, if I'm non-binary, that's great. That also works. Not ideal, but we don't have a neutral form. We can't invent a third neutral form. So I think that, take Microsoft for example, there's no reason that Microsoft won't have my pronoun, set in their operating system, and they'll show me the right masculine or feminine forms. There's no reason that can't happen. And that's relevant for 40% of the population. So the fact that they're not doing it is really strange. That's what I mean, to have the option to choose, based on my pronoun. Language innovation Michal: So I really want to talk about technology, but before we move on to technology, because it's a big topic, what are your thoughts on inventing a third neutral form? Because there are languages where that's done. They actually invent another way to use words. Kinneret: Right. They do, but it hasn't been... for now, it's still... experimental. Like we use dots or slashes, or the non-gendered Hebrew font. These are all experimental methods still. Even adding a third neutral form, I've yet to hear of a language where this truly caught on. There are all kinds of experiments, but it still leads to a lot of opposition from all sorts of language purists. So should we invent a third neutral form? Maybe, I don't know. I don't think it's something that can be decided. I think if it has to happen, it will happen. No one is going to wait for the Academy of Hebrew Language to decide. And if it has to happen, it will happen, and someone will invent it, and if it catches on, it catches on, and if it doesn't, it doesn't, and... I don't think we'll have a choice in the end, because... the masculine and feminine forms are simply not enough. They don't reflect reality. And if they don't reflect reality... Language has to reflect reality. It can't be... we use it to convey reality. So it can't not reflect reality. Which means that in the end, it will have to happen, I don't know if it will happen in our lifetime, and in what way, I don't know. Let's take, for example, the plural imperative form. Today we only use it in the masculine. "Come", "go", all masculine. There used to be two forms, we had a feminine plural imperative form for "come" and "go" and so on. Michal: That's right. Kinneret: We cancelled the feminine form. We now only use masculine, and it works well for us. To use that form for both masculine and feminine. We're good with it. So what if we decided to cancel all forms of plural feminine? So the plural "you" would have worked for all genders. No separate feminine form. And that would have been the correct way to use it. It could solve this for us. It will be very difficult for us to change the direct, first-person form of "you". That will be very difficult to change. But say we figure out a solution for plural forms. If we had a solution for plurals, it would have helped a lot. We can address users in the plural, and it'd be gender-free Michal: And we can say it's a movement that's starting to happen because we are using plurals today when we want to stay non-gendered. Kinneret: Exactly. We use it today because we don't have a choice. But maybe we can actually cancel the other form. Like we did with the plural imperative. Then we can address people in the plural and stay non-gendered, and that's another bit of progress. It's a good question. What will people choose to do? How will it happen? I don't invent things, but I do try what's invented. Like using the dot method for gender neutrality, sometimes I use the dot. Sometimes I use both suffixes. I try all the options, and I wait for something to catch on, for a method we can keep using. I don't really accept the whole readability claim, where people say it's hard for them to read with a dot separator. It's hard to read it because we're not used to it. It's not... If we learn it from the get-go, we'll get used to it, like, from age six. If we learn to use it when we learn how to read, we'll get used to it, and it'll be perfectly fine. I don't think it's a fundamental problem. It's just a matter of getting used to it. But we'll see. Michal: We'll have to adapt all the easy reader classics. I don't know if we can do that. Where do you put the dot? [Laughs] But seriously, my main issue with dots, and slashes, and all of those methods, is that it works when you read the text, but it doesn't work when you speak. You can't read it. Kinneret: Right. And then, on the other hand, we have the option of using plurals. In English, we have "they" and "them", people just choose to switch their pronouns. Michal: Right. And it doesn't work as well in Hebrew, or at least, as far as I know, people don't really use it. Kinneret: Right. Because even "they" and "them" is gendered in Hebrew. It doesn't solve the problem. It's still gendered. It doesn't work. With anything related to voice, we'll have to solve this problem by splitting our UI. There won't be a choice. They'll have to start by asking how you'd like to be addressed and split the UI into masculine and feminine, unless we choose to use plural. But it's a bit ridiculous to use plural when you address one person using voice. So there they will have to split things, and maybe that would create that common practice of offering two gendered interface options. I'm really interested to know - what would big companies do in terms of localizing voice interfaces. I'm curious to know what they're doing today. Do you know? For example, Microsoft's Cortana, which speaks French, German, gendered languages. What does it do? Do you know? Michal: I don't know, actually. And it's a very interesting question. I'll try and ask this on LinkedIn. My voice assistants are always in English, so I don't know how they work in other languages. But it's really interesting, and in general... Using technology to stay gender-neutral Let's start talking about technology because I'm interested in knowing what you can use today, but also... we're at the start of a huge technological revolution, which will probably also give us a lot more flexibility in this regard. So how will our future look, in your opinion? Kinneret: Okay. So, today what technology allows us to do is to split the UI and write each string in two or three forms: feminine, masculine, and a neutral form, if it exists, so that we can offer several setting options and ask every user how they'd like to be addressed. That's the most advanced technology we have today, and today, when we start using AI, it feels so outdated. So outdated. Because I think it's clear that with AI, in Hebrew, we still don't have AI, which is very sad. I hope we will soon. There is a little bit, but not at the same level. Not the really high-end models that we have in English today. And I have no doubt that today you can ask ChatGPT to write a full, gender-neutral text, and it'll do it. Gender-neutral. You can pass anything through it, asking it to turn it gender-neutral. What did it do when you tried? Change the suffix in "shirt" to make it masculine? Michal: Yes. I have to say that I tried in English too. I didn't try switching the gender because English is very easy to keep gender-neutral. It's not that big of a challenge. But I did try to get it to write about inclusive writing and non-gender writing. It didn't understand what it even means, "inclusive." It kept trying to explain to me that I don't have to write the word "guys" in my article because people will be offended, because "guys" is masculine, so write "folks" instead. It loves the word "folks." It bothers me a lot. Really, it said: So when you write, use words that don't have a gender, and that's it, and your problem is solved. It doesn't understand what it means at all. I assume it's because it has been trained in English, so it's hard for it to really understand the challenge of it. And it certainly wasn't trained on texts that describe these challenges because it's not the kind of texts that are available in English online. Kinneret: Right. I would ask him about gendered languages, if it knows, in the languages it does know well and was trained on, like German, French, and so on. Latin languages, yes. Michal: It's interesting. Also, the way people use ChatGPT today, it won't be effective in the flow of localization because we're talking about a lot of texts, and everything is becoming very automated. Things are practically happening on their own now. Kinneret: If they bring GPT's capabilities into the tools used for localization, sure. Without having to manually feed everything into ChatGPT. Michal: Then you can set up a "fence" that'll stop texts before they go in and check if they're gendered. It's an interesting question. Because we're really at the very beginning, and only the early adopters are trying at the moment. Experimenting with all of these changes. Gender-neutrality in localization Kinneret: But you know, it's funny - I'm surprised the whole gender issue isn't more present, especially in the localization community. Because... And I only discovered this when we did the Gender Neutral Language Project, with all those videos. I discovered that this isn't something people in localization speak about that much. And I don't understand how that's possible. It's not just the 10 million Israelis who speak Hebrew, it's hundreds of millions of people speaking a gendered language. How can that be, that it's not discussed more? I'm asking you now. What do you think? Why? Why isn't this on the agenda all the time? Gender inclusivity... It's a hot topic. It's a very hot topic. So how isn't it in localization? Michal: First of all, I think that culturally, how do I put this? The level of candidness and how much people are willing to insist on things is different. And I'm sure there are places where women's status is different. I think that the privilege we have in discussing non-gendered language is a result of the fact that we're already, in many ways, getting past that glass ceiling, in many ways starting to break. Career-wise, family-wise all of that. And so we have the privilege to come and discuss gendered vs. non-gendered. Kinneret: I completely understand what you're saying. We have the availability and freedom for it. Michal: Yes. Kinneret: That might have been true, but it's also French or German or Czech. And it's a topic that's just now starting to get some public attention, even in very widespread, very western languages. And I was very surprised to discover that 40% of the world's population speaks a defined language. I told myself, so how is it that we feel so alone in this? Right? Like we're the only ones stuck with this Hebrew, and it's not just us at all. In German they talk about it a lot. In Italian they published a book about it recently, a whole book about how to write non-gendered in Italian. Michal: Amazing. Kinneret: But only now, and I also hear this discussed by writers and less by localizers. It's really something that, if you look at it in localization, it would be very cool, because I've been hearing this from writers... this book in Italian... it's all by UX writers. Not as much by localizers. Michal: I have to say that many times in localization, it's exactly this, it's availability. The amount of time you have to think about gender strategies is very small, because in the end you get a text and you're told to translate it, quickly and cheaply, and those are the client's instructions. And they're the client instructions, because the client, in many cases, comes from a country where the language isn't gendered. And it's not their top priority. And so gender isn't mentioned, or they write, "we want to be inclusive, because we want everybody to feel accepted", like, someone copied and pasted that line from their voice guidelines, and no one actually cares. And also, no one can really check that it happens. That's true. Kinneret: And there are also varying degrees of training in localization, there are places in the world where you would have to get a translation degree to work as a translator, and there are places where all you have to do... It's like here, right? You just say "I'm a translator", and then you can start working as a translator. And so the levels of knowledge and training are different, and people just don't talk about issues that are more complex than those initial classic translation issues. I can say that I do mention this in my course, there's one lesson dedicated to this, among a few other topics. I do think that your project at the UXCC, the Content Collective, actually made a very significant impact, because it's... first of all it's one of the first results on Google. Kinneret: Really? Michal: Yes. If you search for non-gendered writing, or all sorts of examples and guidance on how to write, it comes right up. Kinneret: Right. We got, I got emails from localization teams around the world saying that they passed it amongst themselves, that they're using it. I know the project had an impact. Which I'm very happy about. Again, even if it's just awareness, I'm very, very happy about it. But there are also a lot of practical tools. Michal: In the end, I think it's really a question of awareness, because people sometimes don't even think about this little detail. It's really a little detail among many, many details that we need to consider as we work, both in writing and in localization. And people don't take time to do this, and then when someone comes and puts a spotlight on it all of a sudden they start thinking about it, and consider it in their day-to-day. And this alone has a huge impact. Kinneret: Absolutely. The Awareness is... You're absolutely right. It's true that people have that penny drop moment, and they're like, oh, right... we just didn't think about it. Of course, we need this. And then, if they also get the tools, like, if tools are included, and an owner, which is no less important, then it can happen. But I think it's these three things: You need awareness, you need someone who cares about it, because otherwise it's like "ok, but we don't have time, or budget, or..." So you do need someone who cares about it. And tools. That is, the knowledge of how to do it. Like, ok, here's how do you write in Hebrew in a gender-neutral way. Five methods. Just like that. So you also need the tools and methods of how to get it done. Taking responsibility - as much as possible Michal: So on the subject of ownership, I'm bringing us back to the beginning, we'll go full circle. So let's assume that we're writing a project, and we really want it to be gendered, and we do what we can on our own, as the writers who write the first part of the project, and then someone comes and takes it forward, and maybe they don't really care as much. How much would you insist if this happens? Kinneret: Today, I wouldn't write something that's not gender-neutral. If in the past... My first client was a bank, Bank Hapoalim, which, today they're the leaders of... In their app, you can choose how you'd like to be addressed, and then the entire app is written in feminine Hebrew when I log in. So today they are very advanced in this field. When I started UX writing for them years ago, they were my first client, they said, "we want it in masculine Hebrew." And I wrote in masculine Hebrew. Today I would never do that. Well, no one would ask me to write in masculine Hebrew today. But if someone would have told me, "we want the whole application in masculine Hebrew," I'd say, no, thank you, and we'll go our separate ways. Today I wouldn't do such a thing; it would seem absurd to me. So, to answer your question, if someone would take it forward, how much would I care? I would care a lot. As long as it's mine, and it's under my name, my name, or my company's, Draft, there's no way we'd put our name on something written just in masculine Hebrew, and we all really, really insist on it. So, yes, I'd insist on it a lot. It's not something we'd let go. Michal: And say you've finished the project, and you've sort of released it into the world, and then it starts to appear there? Kinneret: There's nothing to do. We have nothing to do with it. Like, there's no way... We have no way to follow our projects. The clients that we... Our clients have been with us for the long haul. Bank Hapoalim, they're Amir's customers, my partner, for a very long time, and Maccabi is with us, and Isracard is with us, and so in that sense, we're with them throughout the process, and then this can't happen. We're with them. We're permanently with them, and then things like that won't happen. But the clients we do a single project for, we know there are going to be things that... It's not just... I told you, it's not just the gender issue, there are a lot of other things that... you don't even want to hear. Things we don't want to see in an app that we wrote. But there's nothing to do with it. Like we said at the beginning, it's an exercise in letting go of control. It's not ours, and it's their decision, and if they don't understand the value of having a professional writer review every word and check and approve it... that's life. Michal: And that sums up the whole experience of UX writing in general, I think. Kinneret: Totally. Michal: We can sign off on this conversation now. Kinneret: Totally. Michal: But it was really interesting. Thank you so much for sharing, and I hope I'll be able to translate it into English so that more people will be able to... Kinneret: Good luck! Good luck translating the gendered forms of "shirt"! Michal: Thank you! And thank you again for being here.

Is it just me, or does it seem like every conversation in the localization world these days comes with a side of machine translation and AI? It's like I'm back in middle school and MT is Backstreet Boys' "I want it that way" – and if you think this analogy is stupid, you should have seen what chatGPT proposed I'd use. But somehow, through all that chatter, MT for UX still remains mostly undisturbed, in the sense that people are completely ignoring it. Try and find an MT report highlighting UX or UI as one of its domains - I dare you, because you won't, because there isn't. Everyone's elegantly ignoring UX, since using MT or AI to generate passable-quality multilingual UX copy is HARD, y'all. Some would say, so hard that it's not worth the effort. I'd like to question this premise – a hobby of mine, along with reading fluffy novels and hunting for scones (we're not big on scones in this country). I still think we can get passable results using MT for UX, and more than that, I think companies that use this time to experiment and learn will be the first to benefit from MT when we do get translation singularity*. And yes, plenty of companies are already getting some mileage out of MT. Mostly, they run their content through MT first, then pass it over to their human experts for post-editing (PE). Even if they focus mostly on none-UX content (help centers, blog posts and more) it still means that both loc managers and linguists get to practice MT-driven processes. If you'd like to learn more about this super interesting topic, join Boryana Nenova and yours truly 🙋🏻‍♀️ on June 20th, at 10:00 CET for a deep-dive webinar on machine translation for UX. There will also be a recording for those who can't make it live - but still, make sure you sign up to get the link when it's up! *Translation singularity was all the rage a few months back when Translated announced we're steamrolling into an age where we won't really need humans for translations anymore. I like to imagine we'd all be sitting in our gardens then, eating scones and just overall enjoying life. My kids will be older by then and will obviously be serving me fresh coffee whenever I snap my fingers. Reality's great, isn't it? How is this still happening? Some companies, in an earnest (although misguided) attempt to save costs (which I get), play a peculiar game of hide-and-seek with their legacy content. How? By excluding it completely from the word count, meaning translators are expected to localize new content without any reference to the existing history. It simply doesn't make sense. I’ve used my significant illustration skills to make this very clear: Basically, every part of the screen is translated in a different way. Maybe one is singular, one is plural. Maybe sometimes the product name is left in English and sometimes it’s translated. Who knows? It’s a wild west of linguistic chaos. The result is that we end up with this awkward Frankenstein-ish blend of localized content. And other than the fact that it’s disorienting for users, it’s also completely disrespectful. Do you want your users in other markets to feel like they’re an afterthought? Because that’s a surefire way to make them U-turn straight to the competition at the first chance they get. This is a rant, but it’s also me begging you to be proactive about this. If you’re a linguist and you get a request to overlook 100% matches, make sure your client knows exactly what they’re asking - and exactly where it might lead. And if you are a loc PM… Please, just don’t, OK? I’ll send you a scone.

For ages, there has been an unspoken consensus that when creating UX content, you need to adapt your writing for localization. This convention was born out of necessity, understanding that localization is not a simple linear process. It involves a network of interconnected tasks, each with their own set of intricacies. Considering the numerous variables and complexities involved in localization, it makes sense to simplify the source. Uncertainties in the original content could exacerbate and cause significant disruptions down the line. Let's consider a UX copy created for an English-speaking audience, featuring idioms or culturally-specific references. If this copy were to fall into the hands of someone not so familiar with the source culture, it might be localized without any adaptation. And it may certainly be confusing for a non-English-speaking user. An unadapted phrase like "raining cats and dogs" might lead a Spanish user to expect literal felines and canines, rather than a downpour. It's clear that any foggy areas in the source content could snowball into significant issues when transferred to a different cultural context. Therefore, it becomes clear why we've adhered to the practice of "writing for localization" in creating UX content. By taking the time to adapt the copy, says the industry, we can streamline the localization process, mitigating the chances of misunderstanding or misinterpretation. We also help to ensure a more user-friendly experience in every market where the product is available, affirming the global nature of our digital age. Should we write for localization? But the mandate to "write for localization" led us to strip our copy of all its personality, resulting in clear but stark and lifeless writing. We removed any cultural references, nuances, or distinctive voices to ensure absolute clarity. The result? Text that was precise but as engaging as a tax form. This goes against the trend of the past few years, where conversational, engaging language has become the gold standard for UX copy. We've migrated from stiff, formal language to a more conversational, engaging approach. This shift reflects our increasing understanding of the user's need for intuitive, interactive, and human-like digital experiences. Think of the messages that pop up when you're filling out an online form, the words on a button, or the subtle instructions that help you navigate an app. Today's microcopy is often personable, aiming to create a friendlier user experience. Gone are the days of "Invalid input"; now we're more likely to see "That doesn't look right." However, when we put this vibrant, engaging UX copy under the lens of localization, the picture gets a bit complicated. The cultural context, idioms, and informal language that make copy engaging also make it tricky to localize. While maintaining the clarity and accuracy of our copy is vital to avoid any localization-related issues, there's a growing need to keep our UX copy engaging and inspiring for users, aligning with the original source as much as possible. It’s a balancing act between maintaining the spark of the original and ensuring clear understanding across multiple languages and cultures. The challenge we face now is adapting to this new gold standard while maintaining the clarity needed for successful localization. Can we do it differently? There is an alternative method to achieve this - providing detailed guidelines for each string to the linguists, outlining the context, and the key messages we want to convey. Instead of leaving the translation team to guess the meaning or the importance of a certain element, these guidelines provide clear-cut instructions. Imagine you are localizing a banking app. In its source form, the app uses professional yet approachable language, with clear instructions and perhaps a touch of finance jargon. It is intended to project trust, security, and user-friendliness. Let's take a simple example: the copy for a button that initiates a money transfer might read, "Swipe to send money securely." In this case, the string isn't just instructing the user to swipe; it's also reinforcing the app's focus on security. By providing linguists with context and intent for this string, we ensure they understand the dual purpose of the text. They'll know that the localized copy should not only instruct users about the swipe action but also reassure them about the security of their transaction. But here's the catch: The level of detail required in these guidelines demands a substantial time investment. For every piece of copy, there needs to be an accompanying set of instructions. Writing these guidelines is a painstaking process, demanding a deep understanding of the product, the brand voice, the intended user response, and the specific nuances of the source language. Additionally, these guidelines need to be clear, precise, and easy for the translator to understand. The time drain doesn't stop at writing the guidelines. They also lengthen the translation process. The linguists now have an additional document or set of texts to study and comprehend before they can even begin translating. Enter: technology The advent of AI and LLMs (Large Language Models) has transformed the landscape of machine translation. These groundbreaking technologies have expanded our toolbox, adding new capabilities that can be game-changers in the localization process. AI and LLMs can be likened to quick learners. They are capable of receiving complex, detailed instructions and processing them at a rapid pace, outmatching any human capacity for speed. This ability makes them particularly useful in the context of localization. They can absorb and interpret extensive guidelines for each string of text, thereby aligning the localized output with our preset criteria. Let's revisit our banking app example. Instead of a human translator pouring over pages of instructions, we could provide these guidelines to an LLM. The LLM could quickly analyze these directives, comprehend the context and intent, and try to accurately translate the UX copy accordingly. Even complex tasks, such as understanding the dual function of the 'Swipe to send money securely' button, may very well be within the capabilities of advanced LLMs in the near future. Unlike traditional Machine Translation (MT), which is limited by rigid algorithms and fixed phrase databases, LLMs are designed to be adaptable. They can handle nuances and generate unique solutions tailored to specific cultures when provided with ample multilingual data. Can AI translate alone? While LLMs and AI bring numerous benefits to the localization process, like any technology, they're not without their problems. One such problem is their tendency to "hallucinate." They sometimes generate content that, while plausible, wasn't originally included in the source text or the provided guidelines. Returning to our banking app example, an LLM might take a phrase like "Swipe to send money securely" and interpret security in a broader sense. Consequently, it might generate a translation that implies additional safety features, like fraud protection or insurance, that the app doesn't actually offer. These extraneous details, while well-intentioned, could mislead users and create unrealistic expectations. This is where the role of detailed instructions becomes crucial. It's akin to providing our LLM with a map that clearly outlines the boundaries of its creativity. These instructions not only guide the LLM in understanding the context and intent of the original copy, but they also set clear limits to prevent the addition of unwarranted content. Moreover, despite the impressive capabilities of AI and LLMs, the human touch remains an invaluable part of the localization process. A proficient human translator or a localization expert should always review the LLM-generated content before it goes live. They can spot and correct any deviations or hallucinations, ensuring that the localized copy stays true to the original message and intent. The secret is in the combination The interplay between advanced LLMs, detailed instructions, and human involvement brings us to a promising juncture in the localization journey. It allows us to balance speed and accuracy, maintain the engaging qualities of UX copy, and prevent misunderstandings due to overzealous AI translations. It's an exciting step towards redefining what it means to write for localization. This synergy between LLMs and detailed instructions can create a multilingual UX copy that is more fluent and less robotic than what we would usually get. Additionally, LLMs can expedite the creation of these instructions. We can feed the AI a brief summary or even a recorded explanation, and it will efficiently write the guidelines for us. All these advancements prompt a reconsideration of our practices when it comes to "writing for localization". We don't have to make our copy characterless anymore; instead, we can start articulating our intended meanings in a more engaging way. As we ride this wave of change, let's embrace this evolution in writing for localization. This technology is new, but it's growing and evolving at an extremely fast pace. Our goal should be to keep our content lively and clear, make sure we're explaining our intentions, and, yes, also use technology to make the process more efficient. With this mindset, we can change localization from a task into an opportunity to improve the experience for our users.

Truth: In a world that's more connected than ever, language barriers shouldn't stand in the way. We want everyone to be able to benefit from the incredible tech available, no matter the language they speak. Essentially, that’s where localization experts come in, right? We swoop in like caped heroes. Armed with translation superpowers and ginormous cups of coffee, we make it happen so that apps, websites, software - are available to everyone who speak our language. But here's the thing. This is the age of automatic machine translation. Soon (if not today), humans will no longer be needed to just move words from one language to the other. Bots can do that, and they can do it faster and cheaper. You’re skeptic, right? “Ah, those bloody bots… they’ll never write as well as I can. It’s ridiculous!” You’re right. For digital user experiences, bots will never write as well as humans - as long as those humans know what they’re doing. Writing for digital experiences – apps, software, UI in general – is complicated. The words we get for translation are just the teeny tiny tip of the iceberg. Underneath the surface, there are countless hours of discussions and piles of information. The people who first create the source copy – called UX writers – work based on data-proven methodologies to create copy that does its job. But once the source copy is created, it’s sent out for translation. The people who translate the copy are also UX writers. With two differences: They do it in another language They don’t know how to UX write Except for very few people, translators don’t know UX writing. Even though they write copy for user experiences every single day. Today, this changes. In this article, we're going to dive deep into the world of UX writing to learn why it's a superpower that every localization expert should have. So, whether you're a localization expert wanting to level up your game or just a curious person wondering what the fuss is all about, stick around. By the time we're done, you'll be itching to sprinkle some UX writing magic into your localization efforts. What is UX writing? UX writing, or User Experience writing, is the art of creating user-friendly interfaces that speak the users' language. UX writers create clear, concise, and user-centric text dedicated to helping users achieve their goals (all while helping companies achieve some goals through those users, too). UX writing ensures that the words on your website or app not only make sense, but guide users smoothly through their journey. It's like a trusty GPS system, gently nudging users in the right direction without making them want to throw their device out the window. When done well, good UX copy can even go the extra mile, adding a touch of personality and charm. This helps companies create stronger, emotional connections with users – ones that last longer, promote trust, and make all interactions more effective. Imagine a world where error messages don't send users into a fit of rage, but rather calm them and help them solve the problem. Or a world where button labels are so convincing that users simply have no reason not to click them. That is the power of UX writing. That makes UX writing a key to unlocking the full potential of a product. And when localized properly, it helps companies make the most out of their localized products, too. And YOU have the power to help them do that. When words make or break the experience Let's put UX writing under the microscope and examine some real-life examples. These case studies will show you the good, the bad, and the creative side of UX writing – and how it can make or break a user's experience (no pressure). Good UX writing: A warm welcome and a guiding hand Imagine you’re signing up to an app. You enter your name and email and then… you get this screen. Yes, it’s technically an explanation, but it’s: Stiff, dry, technical, and impersonal Not very clear (doesn’t really explain what you need to do) Heavy with redundant information (who knows or cares what a one-time password is?) If you’re a savvy internet user, you probably already know what to do. But if you’re… An older person A child Someone with low technical abilities Someone who doesn’t use the internet much Someone with visual accessibility issues You’ll have trouble figuring out how to proceed. But what if you get this text, instead? See? This one is Super clear (tells you exactly what to do) Phrased in a way that’s friendly and approachable Contains only important information Pre-troubleshoots two very common issue (email landing in spam and clicking the link from another device) This means that this screen from Substack Reader is much more usable than the one from Audible - thanks to the copy and the way it’s phrased. Not convinced? Let’s see another example. You download an app, decide to upgrade, and make a payment. And you get this confirmation screen. This screen tells you it worked, and you’ve upgraded… But there’s nothing else. No excitement. No brand relationship. No reinforcement that you made the right decision. Wonder do it differently: They’re… Congratulating you for the choice you made Reinforcing it by calling you “pro” and telling you you’re going to “enjoy” Showing + creating excitement with their “Let’s go!” button It’s just a few words, but it makes a huge difference in the way users will feel when they see this screen. Get the impact? Good UX copy makes a significant difference - which is why companies invest in it. More and more companies are hiring UX writers worldwide. Why should localization experts care about UX writing? First, it’s fascinating, especially for wordy people like us. But there are more reasons why localizers should learn about UX writing. To stay in demand Let's face it – with the rise of AI, non-specialized professionals may find themselves gradually replaced by machines. They work faster and get increasingly better at it over time. So to stay relevant and in demand, you need to adapt and upskill. That's where mastering UX writing comes in. By adding UX writing to your arsenal, you become a linguistic superhero who can tackle both localization and crafting user experiences, making you indispensable in the industry. To collaborate well and get respect Regardless of whether you're a freelancer or an in-house localization expert, a crucial part of your job – if you’re localizing UI copy – involves working closely with product teams. These teams include designers, developers, UX writers, and more. They’re all working hard to create a seamless user experience. But if you want to get a real seat at the table, get treated like a professional and have their respect, you need to be able to speak their language. Having a firm grasp of UX writing concepts and terminology will allow you to communicate clearly and effectively with product teams. And when you show you truly understand their goals and the way they work, you’ll get a chance to share your ideas, provide input, and get your feedback taken seriously. To create better experiences As a localization expert, you already possess a valuable skill: bridging language gaps and making digital content globally accessible. But let's be honest, translation alone is no longer enough to impress users. You need to widen your skillset to create copy that's not just linguistically accurate but also makes for a great experience. UX writing enables you to create digital experiences that resonate with users on a deeper level. By mastering the art of crafting clear, concise, and culturally relevant copy, you can make localized interfaces feel more natural and user-friendly. Where can localizers learn UX writing? The good news is that there's no shortage of courses and resources to choose from. Whether you're seeking a comprehensive paid course or just dipping your toes into the world of free resources, there's something for everyone. Here are a few options to get you started: 1. Paid courses: Localization Station's UX Writing course for localizers: Currently the only course designed specifically for localization professionals, this course offers a comprehensive tailored program to mastering UX writing skills, with a focus on adapting content for different languages and cultures. It’s great for localizers who want a deep dive into the UX writing skills relevant to their work, but prefer to skip additional skills they don’t need. UX Writing Hub's Academy: This course provides a thorough overview of UX writing principles, with modules covering everything from the basics to more advanced techniques. They have a highly-recommended mentorship plan with plenty of opportunities to learn from real-life UX writers and experience the work they do. UX Content Collective Fundamentals Course: Another option for those seeking a comprehensive understanding of UX writing, this course covers a wide range of topics and includes hands-on exercises and projects. It’s an online course that’s self-paced, so you can take it on your own time. 2. Free courses Localization Station's Free Email Mini-Course: Get a taste of UX writing for localizers with this email-based mini-course, which delivers bite-sized lessons straight to your inbox. You get 7 lessons delivered through email, and it’s completely free. UXcel's Free UX Writing Course: This comprehensive course provides a solid foundation in UX writing principles and practices, giving you the tools you need to create engaging, user-friendly digital experiences. The UXcel course covers a range of topics designed to help you understand the ins and outs of UX writing. UX Writer in 15 days: This unique and engaging email-based course delivers a fresh UX writing prompt straight to your inbox every day for 15 days, helping you build your skills and confidence one step at a time. By tackling a new UX writing task each day, you'll not only learn the core principles and techniques of UX writing but also practice applying them to real-world scenarios. In addition to these courses and resources, don't forget the value of networking and joining online communities. Engage with fellow localizers, UX writers, and other professionals in the field to share knowledge, ask questions, and gain valuable insights. As you dive into the world of UX writing, you'll discover a wealth of learning opportunities that will help you become a more versatile and in-demand localization expert.

If you haven’t yet, now’s the time to acknowledge the hard truth: We’re way past the point of no return, at least when it comes to AI usage in localization. Machine translation, artificial intelligence, and automation powered by AI are transforming the way companies localize. and buyers are clambering over each other to get on the tech train. And really, why shouldn’t they? For starters, these latest technologies are already saving companies millions, and passing on that opportunity makes no business sense. If there’s a revolution, the ones who’ll benefit most are the ones at the forefront of it. But it’s not really all about money. All that newfangled tech not only helps cut costs and save time. It also makes localization an achievable goal. As the entry barriers lower, we're seeing an increase in global accessibility, which can only be a positive development. To put it simply: In a few years, even tiny, niche products will localize their UI into multiple languages, because it’ll be so easy to do (not to mention, cheap). And that means people all over the world will have more access to new tech, new opportunities, new tools, and ideas. Think about the social implications: increased access to information, equal opportunities, and cultural exchange. Who knows what global growth this revolution will lead to? I certainly don’t, but personally, I’m here for that future. But while the AI revolution is taking over the loc industry with staggering speed, it does beg a big question: How can we maintain great quality in this new age of automation? In this article, I'm going to suggest a framework designed specifically for this digital landscape we find ourselves in. In a nutshell, I’m proposing we use this change as an opportunity. Not to invest less in localization (less time, less money, less effort) – but to invest in other aspects, instead. By shifting our focus away from manual processes and file transfers, we can finally zero in on what really matters: providing mind-blowingly good experiences for users across the globe. So, grab a coffee, and let’s start by addressing a very important question. In this guide What is quality in UX The old way to measure quality in localization A new framework for UX localization quality Implementing the quality framework Step 1: Understanding the potential breaking points Step 2: Prep your team and process Step 3: Design a process that brings better results Step 4: Test for quality Step 5: Put the data to work FAQ The very important question: What is quality in UX? Quality is a term we throw around a lot, but when it comes down to it, we often struggle to define it. How this was done in the past: The translation quality matrix Traditionally, translation companies used a quality matrix to measure translation quality. The metrics included gave companies a standardized framework so that they could compare translations and translators, giving each of them a numeric quality score. For example, companies would often ask testers to rate a translation for: 1. Severity Higher severity rating was given to more significant errors, those that impacted the meaning or the readability of the test. A common classification system could be, for example: Critical: Major errors that significantly change the meaning of the text or make it incomprehensible. Major: Errors that lead to a partial loss of meaning or significant confusion, even if users would still manage to understand the text eventually. Minor: Errors that impact the meaning or readability a bit, but nothing too critical - like minor inconsistencies or awkward phrasing. 2. Error category On top of severity, testers were asked to classify each error into categories, so that companies could do a more detailed analysis of the translation quality. Common error categories include: Mistranslations: Incorrect translation of words, phrases, or concepts. Omissions: Missing words, phrases, or content from the source text. Additions: Unnecessary words or content not present in the source text. Grammar: Errors related to syntax, morphology, punctuation, or other grammatical aspects. Style: Inconsistencies in tone, register, or terminology, as well as inappropriate use of idiomatic expressions or cultural references. Generating the quality rating Once they got the results, companies would organize them in something called a quality matrix. They’d use this to get a clear and comprehensive overview of translation quality and calculate the translation’s quality score. Basically, each error got a specific point value based on its severity level. The total number of points is then divided by the total number of words or segments in the translation. The result is a final quality score that can be compared across different translations or projects. Translators and reviewers would often get a rating scale. They could assess translations based on the quality score and the error matrix, and give them a final “grade”, such as: Excellent: Minimal errors, with no impact on meaning or readability. A translation of outstanding quality. Good: Some minor errors, but overall a high-quality translation that conveys the intended meaning effectively. Fair: A moderate number of errors, with some impact on meaning or readability. The translation may require further revision. Poor: A high number of errors or significant issues with meaning or readability. The translation is likely to require extensive revision or retranslation. Quality in UX: The quality matrix doesn’t cut it anymore The quality matrix was widely adopted because it was, first and foremost, easy to use. It’s so much easier to evaluate how things are going when you can just slap a grade onto each piece of copy or every linguist. When buyers asked about how quality was managed, vendors could say they “only work with the highest-rated linguists” and wax poetic about high standards and processes that maximize quality. In reality, it’s incredibly hard to quantify and measure good UX copy. Because of how subjective it is, and how fluid audiences can get, trying to define high-quality copy in numbers only is a bit like grasping at clouds with a pair of tweezers. For this reason, companies dealing with UX localization have to develop a more comprehensive understanding of translation quality. It’s simply essential if we want to have any real control over the quality of the localized microcopy results we get. Sure, a product with subpar UX might still work – people could understand the text and figure out how to use the product. But the experience would be, well... not so great. 😕 And who wants that? Quality for UX: A new framework When we talk about quality in UX localization, we're not talking about the number of errors in a translation or how well date formats were converted (though those are important too). The components of good UX writing are more like the users themselves – flexible, widespread, and varied. You can't easily put a number on them. However, some sort of framework is definitely needed if we want to be able to methodically evaluate the quality of our localized UX copy. This is especially true since we’re almost never able to actually read the localized UX copy (we rarely speak the language). We’re putting our trust in other consultants, reviewers, and proofreaders, basing our efforts and evaluations on their feedback. A joint frame of reference is even more critical in that case. It evens the field and creates mutual ground for discussions. The framework I’m offering for quality in UX localization focuses on three key dimensions: Fluency (or "naturalness") Usability (or "helpfulness") Personality (or "uniqueness") Let’s break each of these down to see exactly what they mean. Fluency (naturalness) Fluency refers to how well the localized copy reads in the target language. And yes, fluent text should be grammatically correct, free of spelling and punctuation errors, and follow the conventions of the target language. But it goes way beyond those basic technical requirements. In essence, fluent text reads as if it was originally written in the target language. It doesn’t feel like a translation at all - which means it often drifts far apart from the structures of the source copy. Fluent localized copy is also often full of interesting and unique language structures, idiomatic expressions, cultural references, and colloquialisms. Of course, these are adapted appropriately to ensure that the text feels natural and engaging to the target audience, and not just a pale imitation of the source. It’s hard to describe how fluent text feels to those who only speak one language, especially if their native language is English. But the multilinguals reading this can surely imagine. Copy can be 100% technically correct, and still completely non-fluent. It would feel stiff and alienating, while still get a perfect score in the traditional quality matrix. Usability (helpfulness) Usability is all about how effectively the localized copy helps users navigate and interact with the product. Good usability means that the copy should be clear, concise, and informative, guiding users through the product's features and functionality with ease. The text should be easy to understand and follow, avoiding ambiguity or confusion. It’s useful to start by following the source copy, but often, making localized copy as helpful as possible requires some adjustments. Each culture approaches challenges and tasks differently, so naturally, the instructions and help texts accompanying those should be different as well. From the way information is organized to the phrasing chosen. Evaluating copy for usability is hard to do without testing it with users. Even if you’re lucky enough to work with testers who match your user persona, they naturally know much more about your product than the everyday user. Therefore, to truly measure copy usability, you’ll need to run user testing - just like you would with your source copy. Personality (uniqueness) Personality is the distinctive voice of the brand, designed to reflect the brand identity and appeal to the target audience. A strong and consistent personality helps create an emotional connection with users, making the product more engaging and memorable. A strong brand voice can be a wonderful differentiator and an overall significant asset for brands. Despite that, brand voices are rarely used in localized copy. Getting the brand voice to be reflected in all languages requires significant prep and tight collaboration with the linguists themselves. Most companies aren’t equipped for that, as they follow protocols that prioritize speed and cost over quality of experience. On top of that, personality is rarely taken into account in the quality matrix - though it’s sometimes mentioned under “fluency” as an afterthought. Since it’s not highlighted as a priority, linguists don’t invest as much time to make sure the voice is reflected in their localized copy. This means that the brand voice is usually one of the first ones to go, resulting in a poorer experience for those localized languages. Implementing the quality framework for UX localization Evaluating our localized results based on this framework would be a big step forward. Instead of checking box after box of technical data, we’ll be checking the copy actually supports a great user experience. But even with a clear framework in place, measuring quality is tricky, for several main reasons. To make sure our efforts actually lead to success, we start by preparing ourselves and understanding what can go wrong. Step 1: Understanding the potential breaking points If we understand where things might go downhill, we can proactively tackle the problems before they get too big - for an overall smoother localization journey. Mapping the localization process To kick things off, we need to have a clear end-to-end understanding of our localization process. This means identifying all the people, vendors, and departments involved, and figuring out who and what is impacted by their work. You can ask yourself these questions: Who are the key people in the process (e.g., translators, writers, developers, designers, project managers)? Who is dependent on whom, and how do they interact? Where could things potentially break down, and what would be the consequences of these breakdowns? Once you've mapped out your localization process, it's time to take a look at each point and assess the impact it has on the overall quality. Identifying quality impact points Each point of data transfer and each person involved have the potential to implement the quality of the results. Now that we have a framework to work on, we can think about what can be done to improve quality at each of these crossroads. We can also consider what shouldn’t be done - what practices can break things or damage quality in other ways. Not all breaking points will have a direct impact on quality, but some may have a ripple effect that ultimately influences the experience for the end user. For example, developers may not write copy, but their work can impact quality in other ways, such as: Ensuring that the product can handle different languages, scripts, and text directionality Properly implementing localization tools, such as translation management systems Providing ample support to translators and other localization professionals during QA Similarly, designers can have an impact on copy quality by: Creating layouts that allow for text expansion Providing context-rich information including screenshots and mockups Choosing the right typography for each market Adapting visual elements to align with cultural preferences and norms. These are just some examples. Get creative and try to list all potential pitfalls. You can even work with an AI brainstorming tool to mine for things you haven’t thought of yourself. Understanding your markets Before you go ahead, make sure you have a deep understanding of the markets your product is serving. Don’t just count on your linguists or vendors - as professional as they are, it can’t replace having first-hand knowledge of the culture, social circumstances, and other elements that impact user behavior. Having that knowledge will prove infinitely helpful when you need to anticipate potential breaking points and adapt your localization strategy accordingly. Consider the following questions as a starting point: What languages and cultures are you targeting? Are there any unique challenges or opportunities associated with these markets (e.g., legal requirements, cultural sensitivities, technological constraints)? Who can give you more information? How can you leverage local expertise to improve the quality of your localized UX? You can use the Localization Station market analysis template for localization to help guide you through this step. After thoroughly analyzing your localization process, identifying potential breaking points, and understanding your target markets, you can go ahead to the next step: Prepping your team to create the foundations for higher-quality UX. Step 2: Prep your team and process When you’re all better prepared, you’ll notice the problems don’t get a chance to grow. Your team identifies them long before and is able to figure out exactly how to solve them. Here’s how you get everything ready. Empowering your team members You want to begin by helping each person on the team understand their role – as well as the impact they have on quality. Those insights you got in the previous step? This is where they come into play. Often, team members who are not directly involved in localization don’t even know how much of an impact they have. They’re not familiar with potential issues, so they don’t know to look out for them as they work. They assume localization quality is only determined by the skill of the translator, but we already know this isn’t the case. The first thing you need to do, in that case, is to help them learn. This means you want to clearly communicate each team member's responsibilities when it comes to localization, as well as the expectations around quality. You want them to understand what quality means for your company and for the product, and what parts of their job have an impact on those results. If needed, provide training and resources that will help them improve their skills and contribute to a better user experience. This can be training on localization management, UX writing, user experience design, communication practices, or anything else that you feel could be helpful. Overall – and this is true for any endeavor – strive to create a culture of open communication. Team members should feel comfortable discussing their challenges when it comes to localization. And they should be encouraged to share their ideas for improvement. Who knows, their unique skills could actually lead to significant breakthroughs in your process. Establishing periodic checkpoints Now that everyone is engaged and ready to make localization magic, you want to keep that energy alive. Bake periodic checkpoints into the localization process, so that you can all work together for better localized UX. These checkpoints can look different based on your company culture, the way you’re used to working, and the preferences of your team. For example: Have multi-team meetings to discuss progress, challenges, and opportunities for improvement Create metric review sessions to analyze performance data and identify areas of concern Set QA sessions with cultural consultants from your target markets, to ensure that localized content is accurate, relevant, and culturally sensitive Run user tests to gather real-world feedback, then review that with your team to fine-tune the user experience Whichever format you choose, these checkpoints can help you create a more structured, collaborative environment that’s truly committed to (the right kind of) quality. Learning more about your local market Lastly, understanding what constitutes a great user experience in each of your target markets is crucial. Don’t assume you know this. The assumptions you make based on your own culture may be way off base, and you’ll find yourself wasting time and money. To gain those valuable insights, you can have exploratory sessions with consultants or local experts in each of the markets you’re localizing into. These sessions can help you: Identify what potential pain points you can address for your users in those markets (they may be the same as those in your original market, or slightly different) Understand the cultural preferences and norms that could shape users' expectations and experiences Discover opportunities to delight users and make your product stand out in each of these markets Once you and your team are ready, you can start running through your localization process. Step 3: Design a process that brings better results As you go forward, you want to make sure that the process you’re using supports good localized UX - i.e. that it’s helpful in creating translated copy that’s fluent, possible, and on-brand. These days, with machine translation and automation, this means something a bit different than before. A lot of manual labor is being phased out, and new, unique challenges arise instead. To set yourself up for success, there are a few things you should keep in mind: Keep humans in the loop Yes, tech has come a long way. Yes, nowadays we’re using chatGPT for anything from planning trips to planning recipes. But human expertise still plays a critical role in great UX writing. Machines can translate text quickly and accurately, but they can't fully grasp the nuances and cultural sensitivities involved in crafting a truly localized experience. The quality of copy you can get out of your MT depends on several factors: The language pair, the context matter, the type of MT you’re using… You can try machine-translating your UX copy and evaluating the results, but even in the highest-resource language pairs, you’ll still need a human eye to tweak the copy, for a few reasons: For now, MT can’t take into account any visual context. Your AI translator won’t be able to tell where the copy you’re asking it for will be placed, or if there are any supporting visuals. This means poor usability. MT also doesn’t consider the knowledge level of the audience, nor what they did before they reached this specific UI point. It has trouble nailing copy that fits within the flow of the product. Again, bad for usability. MT has a tendency for literal translation, since it can’t really take in any of the surrounding context. It also happens since the corpus used to train MT engines was often written in stiff, formal language - while UX copy tends to be more plain and straightforward. This is a significant issue in UX translations, where copy is split into small strings that are seemingly distinct from each other. And, of course, it’s not ideal for fluency. And, for the moment, MT fails spectacularly on the personality front. ChatGPT’s been getting more flexible when it comes to voice, but it has a hard time nailing the exact brand voice - and that’s when it’s given exact voice guidelines or plenty of examples. For localized copy, MT almost always defaults to that generic bot-like voice. Snooze. Working with MTPErs Who Understand UX The humans you work with? They should not only have a strong command of languages — but also understand UX and know how to write UX copy. Especially in MTPE, it’s less about the grammatical correctness of the copy, which MT can handle fine. It’s more about taking that raw MT output and turning it into a useful, unique, natural user experience. Once you work with the right MTPErs and have enough confidence in their abilities, you can give them a bit more freedom and flexibility. Creating fluent copy under stifling, strict rules is nearly impossible, because language is flexible on its own. Letting your linguist veer off the course of the source copy is crucial if you want their localized texts to feel fluent and natural. Skipping proof and adopting a two-stage QA approach Traditionally, translation and localization projects always include a proofreading step. When projects reach QA, linguists are asked to avoid any unnecessary changes. They’re expected to only flag issues that are very critical, like blunt errors and potentially offensive copy. I would like to argue that proofreading in a contextless environment, or proofing based on screenshots and mockups alone, is far less effective than proofing during QA. A lot can change in the final version, and you want to give linguists the option of changing things around once they actually see the copy live. Instead of the traditional proof-and-QA process, consider skipping proof and implementing a two-stage QA process. In the first QA round: Allow testers to make any necessary changes to the copy. This stage is all about identifying and fixing issues that may have been missed during the initial MTPE process. After testers have completed their revisions, let the original MTPErs/linguists review the changes to ensure they work well within the context of the product and maintain the intended meaning. Finalize the changes and implement the copy to get things ready for the second (final) round of QA. In the second QA round: At this stage, most of the copy should be good. Now you can focus on high-level comments that either highlight definite errors or have a significant impact on the user experience. Require testers to justify each comment they make during this stage. This approach encourages critical thinking and helps ensure there are no unnecessary preferential changes being made. Step 4: Test for quality The tests you run during QA should also be ones that prioritize the user experience, focused on the 3 dimensions of localized UX copy quality. The texts are just one part of the overall experience, and all pieces are tied together. You want to give your testers the ideal conditions so that they can assess the quality of the final experience. If you’re having two QA steps as suggested above, you’ll want these conditions to support them as they improve the experience – through changes and adaptations of the copy. Providing enough context Conducting QA in a contextual environment can significantly improve the results, as you can probably imagine. Of course, there’s no way to perform QA without context. Usually, testers are either given screenshots or a testing environment for them to use. The more context you can provide, the better they’ll be placed to analyze and improve your localized experience. Based on that logic, performing QA within the actual app – live or through a testing environment – is the ideal way to go. It lets testers understand exactly how well the copy will fit within the overall design and layout. That being said, combining this with in-context editing in the localization tool can be a game changer. Not only can testers evaluate how the copy looks now, but they can see exactly how it’ll look after each fix. This can dramatically decrease the amount of iterations you’ll need after QA. Either way, make sure you also provide testers with the full context of the product, including its purpose, target users, and the state of mind of the users as they use the product. Those are critical to understanding the experience and addressing potential UX issues in the localized product. Gathering both qualitative and quantitative results Quantitative data is easy to analyze and simple to visualize. And it can help inform your decisions about which markets need work and which linguists you want to keep working with. To collect it, you want to ask your testers to rate the copy in terms of fluency, usability, and personality. Ask them pointed questions like: Does the copy feel like it was written in your language? Is the copy clear and easy to understand? Do you feel like the users would be able to navigate this product easily? Is the brand voice reflected in the copy? To get a true understanding of the quality of your localized UX copy, you can’t stop at numbers. The information you get from quantitative data is painfully lean. Not only that, but quantitative data alone can lead to plenty of misunderstandings, especially since you and your testers come from different cultures. If you have testers explain – in their own words - how they feel about the copy’s fluency, usability, and personality, it’ll help you make sure you’re on the same page. You can even ask follow-up questions and gain more insights into their thought process and reasoning. Plus, qualitative insights will help you get a deeper understanding of the three dimensions, and how well they’re implemented in the localized copy. A fluency rating between 1 and 5 is significantly less detailed than a long-form free-text answer explaining how fluent the copy feels. Scheduling out-of-sprint tests Often, companies only perform QA when a new feature is launched or some new copy is added. This puts the spotlight on new copy only, without looking holistically at the entire product. Older copy doesn’t get tested after its initial release, especially if it’s not placed near the new copy in the product. Adding out-of-sprint checkpoints can help with that. By reviewing the entire product from time to time, you can identify and address any issues that may have been missed or that came up later, while new copy has been incorporated. In these checkpoints, you can have testers or linguists review the product, just like you would in a regular QA task. Only the QA script does not focus on a new feature, but on key contact points in the product as a whole. Alternatively, you can test the localized product with real users, watching them as they experience the UX themselves. These checkpoints will help maintain a consistently great experience in all languages. Testing with real users, too QA testing with linguists and language testers is a critical step, and one that can help you weed out the critical mistakes. But your linguists are not your users. If they’re professional, they can give you valuable insights into the copy’s personality and fluency. And they can make educated guesses about usability, too. But they can’t know for sure if your copy is truly usable. The only way to get this information is through user testing. As with QA testing, you want to combine both quantitative and qualitative data in your research, to get your users’ real feelings about your product. You also want to try and use a wide variety of UX research methods. For example, you can do: Usability testing: Observe users as they interact with your localized product, identifying any issues or areas for improvement. Surveys: Collect feedback from users on their overall experience and specific aspects of your localized product. Focus groups: Bring together small groups of users to discuss their experiences, preferences, and needs in relation to your localized product. A/B testing: Test different versions of your localized product to see which one performs better in terms of user engagement, satisfaction, and other relevant metrics. These methods will help you get detailed insights that’ll impact the paths you choose to take later. Step 5: Put the data to work Alright, so you've put in the effort, gathering all that valuable feedback, running tests, and keeping an eye on your UX localization game. Now it's time to make that data work for you. Here's how to take all those great insights and use them to make your localization even better: Analyzing the data First things first, take a good look at all the data you've collected - from both QA and user testing. You want to look at all types of feedback at this point: Specific, pointed feedback (”this is missing a comma”) - This includes comments that refer to objective errors in specific strings or pieces of copy. If there’s too much of this, you’ll want to try and understand why that is. Talk with your loc team to try and pinpoint what went wrong and how you can prevent that from happening in the future. General framework feedback - These are comments that have to do with the fluency, usability, and personality of the copy. Here you want to keep an eye out for any patterns and trends – since those can help you understand what's working and what needs improving. Making a to-do list Once you've got a handle on your data, it's time to figure out what needs fixing and how it can be done. Prioritize your to-do list based on what will make the biggest difference to your users' experience. Once you know what you need to do, share your list with the team. Tell them what you’ve learned and ask for their ideas on how to make things better. Ideally, you want your entire team to be present – or at least go over the insights later. It'll help everyone understand how their work affects the user experience, and might just give them the motivation they need to keep improving the localization process. Using your data to make decisions Finally, after any issues are fixed, use the relevant data to make smart decisions about your localization strategy and process. Maybe you need to focus more on a particular language or invest in better translation tools. Maybe your UI in a specific language needs some work, or the team in one of your languages needs additional investment. Whatever the case, making data-driven choices will help you put your efforts where they count. Keep using your data to make your localization better. Update your guidelines, chat with your team, and make sure everyone's working together to keep the experience the best it can be. Some questions Do you do this for every localization task? It depends on several factors, like the size of the task, the amount of time you have, and budget, of course. I’d do some level of QA after any localization task to weed out the issues. You can then analyze the data periodically to keep improving the fluency, usability, and personality of your product’s UX copy in that language. Who should test your copy? Ideally, you want to work with professional LQA testers - people who have both linguistic capability and the technical skills needed to go over your UX copy. If that’s not possible, I would recommend running QA step #1 with linguists, providing them with easy-to-use assets like screenshots and videos. Then, run QA step #2 with QA testers to find additional usability issues. Got any more questions? Get in touch!

Let's talk about machine translation. Smartling announced last week that they're launching patent-pending tech (woah, big words) meant to completely change machine translation as we know it. They're talking about using advanced prompting to tweak MT output, which basically means it'll give you the option to give your MT instructions on style preferences, voice, gender requirements, and other factors that impact translation results. Your MT will then proceed to take those instructions and use them very literally. Ever tried telling chatGPT to do something? It feels like the dad trying to make a PB sandwich in this very hilarious video. But while their very ambitious claim to fame may be a bit of a stretch, I love the approach they're taking to this. Done are the days when all companies use one generic MT for their every need. In this age, we expect to have custom everything, including the MT engine we're using. The ability to customize our MT output is a long time coming. Despite LSP marketers' love for the term "human-led MT" (fancy code word for "we try let humans look at our MT output"), the industry is moving towards using MT in every loc task and for every language. Translated just announced they're now serving 200 languages with their Adaptive MT offering. That's a massive number of markets about to be served machine-translated copy in various levels of quality. If this is our new normal, it's about time we start thinking about how to make that MT ouptut readable to people, not just machines. And for localization, this means a user-centered approach to loc quality, even if it is powered by machines. I'm guessing Smartling's initial results won't be as impressive as promised. But it's an important first step towards getting better copy in all languages. It's a critical understanding – that copy is never a one-size-fits-all solution, and international users deserve to have tailored copy results, too. Do you think Smartling's custom MT prompting is a game-changer or a false promise? Michal

Croatia is rich in cultural and linguistic diversity with three main dialects, each with its own variations. These add complexity when localizing user experiences into Croatian – especially when an informal tone is in order. Read on to learn about the historical origins of the language and how its challenges can be managed in localization. Even though English is now the world’s lingua franca, many consumers are still not fluent enough to use products with instructions, descriptions, or interfaces in English. Others are simply more comfortable reading in their first language. Statistics have confirmed this many times. For instance, more than 72% of consumers are more likely to buy from sites in their native language, and 87% of global customers wouldn’t buy from a website written exclusively in English (Can’t Read, Won’t Buy Research). Localization in smaller markets Linguistic and cultural adaptation is often associated with globally robust economies, such as Germany, France, Brazil, India, or China. But localization is too valuable to overlook smaller markets. Croatia is one such market – a small country at the crossroads of Central and Southeast Europe. With its four million inhabitants and a large diaspora, this market is small but far from negligible. If you add other neighboring countries such as Slovenia, Bosnia and Herzegovina, Montenegro, and Serbia – who can all understand the Croatian vernacular – you suddenly get around nineteen million speakers. Thanks to its geopolitical position and education system, Croatia is a country with very high foreign language proficiency. In 2022, the country ranked as the 11th in the world for English proficiency. But people still use localized products. In one of my polls on LinkedIn, I asked professionals and highly proficient English speakers (ninety respondents) whether they have their phone set to English or their first language. To my surprise, the result was around fifty-fifty. If we broadened the demographic structure, this result would certainly grow in favor of localized versions. A small yet diverse language With a surface area of only 56,594 sq km, Croatia is six times smaller than Germany. Yet its cultural and linguistic diversity is truly unique. The country has three main dialects, all named after the interrogative word “what”: Shtokavian (interrogative word “što”): the most widely spoken dialect in Croatia, including in the eastern regions. The standard Croatian language is based on the Neo-Shtokavian subdialect of the Shtokavian dialect. Here, it’s important to note that the Shtokavian dialect also forms the basis of the Serbian, Bosnian, and Montenegrin standards, which makes these languages so similar. Kajkavian (interrogative word “kaj”): the dialect spoken in the northern and northwestern parts of the country, including – to some extent – the capital Zagreb. Kajkavian is close in the dialect continuum to the Slovene language. A person from the north of Croatia will often feel a greater linguistic connection to a neighboring Slovenian speaker than to the Croatian speaker living in the east or on the Dalmatian coast. “A person from the north of Croatia will often feel a greater linguistic connection to a neighboring Slovenian speaker than to the Croatian speaker living in the east or on the Dalmatian coast.” Chakavian (interrogative word “ča”): the dialect primarily spoken on the North Adriatic coast and across the entire Istrian peninsula. Similarly to Kajkavian, it greatly varies from the Shtokavian dialect, and can’t be easily understood by people in other parts of Croatia or other neighboring countries (Bosnia & Herzegovina, Serbia, Montenegro). All the above dialects are a source of cultural and literary wealth, and are still very much alive in everyday interactions. Another important thing to notice is that the dialects include rich linguistic variations within themselves with each town or village speaking differently. As a high-school student, I often found myself having trouble understanding what my school peers from different nearby villages were saying. The language of localization A standardized version of Croatian developed in the nineteenth century, and it became the favored language of the Croatian elite. It was further codified in the twentieth century, mostly by language institutions and academies such as the Croatian Academy of Sciences and Arts and the Institute of Croatian Language and Linguistics. The standardization aimed to overcome dialectal differences and create a language that everyone in the country understands. “A standardized version of Croatian developed, aiming to overcome dialectal differences and create a language that everyone in the country understands.” The standard variant is the official language that people can use in different settings, mostly in official and formal settings. It’s used in literature, newspapers, TV, government institutions, business, and education. The standard language is a variant that nobody acquires naturally ­– its rules have to be learned at school. It is an important tool of national identity and of urban–rural class distinctions, in which people are often labeled as “educated” or “uneducated” based on their control of the standard variant. This can lead to negative phenomena like linguistic prescriptivism, exclusion, and even discrimination. Because of social changes linked to the Croatian War of Independence against the Yugoslav (but Serb-dominated) army (1991–1995) and its aftermath, proponents of new Croatian standards have ensured the standard has moved away from the Serbian language. In an atmosphere marked by purism and prescriptivism, speakers’ language choices could hint at their relationship with national sentiment and belonging to the Croatian homeland. New words and new rules were introduced, some of which were often criticized as absurd by the speakers themselves. Nowadays, those negative trends are fading away, as Croatian has become an independent standard language that its speakers use with confidence. Croatia’s joining the European Union in 2013 certainly helped bolster its status. The standard Croatian language is typically used to localize any product or service that an international brand wants to place on the Croatian market. Business partners? Friends? Or maybe both? Croatian society has strong status hierarchies, which is evident in the use of formal and informal address. In very simple terms – people use “ti” (the informal you) only with family, friends, and close people; they use “Vi” (the formal you) with everyone else – when addressing teachers, older people, or anyone else they don’t know (from supermarket cashiers to doctors). Formal and convoluted language has been popular in Croatia for decades. People use it to show that they’re educated, and that they know how to speak and write properly. When I was a child, all the brands and their commercials used the formal address. However, globalization and trends of familiarity between businesses and their customers completely disrupted this linguistic and cultural reality. I’d say the lines started to blur from 2010 onwards. Suddenly, brands became intimate friends. This overnight change didn’t resonate well with many people, and they expressed their dissatisfaction loudly. They didn’t feel respected. “Suddenly, brands became intimate friends. This overnight change didn’t resonate well with many people” With time and the rise of social media, informal address became a standard for brands that target younger audiences or that want to convey that they’re cool and trendy. But formal address is still a must for brands that want to grab the attention of people who look for a sense of seriousness, trust, quality, exclusivity, or even luxury in a brand. IKEA uses informal address to appeal to a large audience who value simplicity and low prices. In contrast, the regional furniture leader Lesnina formally addresses their customers, who have deeper pockets and who are looking for high-quality products: In addition, it should be noted that, linguistically speaking, it’s much easier to localize content using the “formal you” as we can completely avoid grammatical gender in the past tense: Zato što ste gledali (EN: Because you watched; formal address – one form for both male and female gender) Zašto što si gledao/la (EN: Because you watched; informal address – two forms, one for male, the other for female) The two forms for two genders in the past tense can be solved by showing only the relevant gender for the signed-up user. However, this would require intervening in the code, and that’s something that companies rarely want to do. One possibility would be to use the passive form for verbs, which is often not recommended in Croatian. It can sound so impersonal that it’s often better to leave the clumsy two-form verb ending. For example: Zato što si gledao/la > Zašto što se gledalo Because you watched > Because it’s been watched The other, better option is to try and rephrase the sentence in order to change the perspective. Zaboravio/zaboravila sam lozinku > Ne sjećam se lozinke I forgot my password > I can’t remember my password Or we can simply use the verbal adjective “Forgotten password?” (Zaboravljena lozinka?) to completely avoid expressing the subject of the action. When localizing their content, brands should carefully consider both forms of address, and cultural differences between languages. What works in English may not work in Croatian, and vice-versa. And if a brand opts for the informal version, they should be aware that this will inevitably create linguistic challenges. Whatever option they choose, consistency is crucial. Otherwise the consumers will be confused, as was the case with Wolt’s website. Localizing informality – mission (im)possible? Brands who want to communicate informality all want to be friendly, straightforward, playful, fun, approachable, and innovative. But wait, there’s a slight problem. Standard Croatian language wasn’t made to be any of those things. So, if you want to sound very informal, some rules have to be broken. To sound conversational, we’ll need to take some words that are not standard. But which dialect do we take them from? Whichever dialect we opt for, one thing is certain – some speakers will feel excluded. When it comes to regional forms, the urban Kajkavian dialect (spoken in the capital Zagreb) is seen as socially prestigious. And this prestige has been heavily criticized (ending in a lawsuit) when the Smurfs spoke the Zagreb slang in a dubbed cartoon shown in cinemas around the country. I’d argue that some regional Kajkavian forms such as the greeting “Hi” (“Bok”) have become so widespread that other speakers won’t hold their use against you, but regionalisms should generally be used very sparsely. This way, we avoid excluding people and hijacking the product for only one geographical region. Rather, we should aim to achieve informality through idioms that are part of the standard language, but that are still used across the whole country. And even though purists like to banish Anglicisms and threaten that they corrupt the language, they are also a better option for achieving informality. As they come from a foreign language, they’re less divisive than dialectal words. Let’s take a quick look at Apple’s copy, which masterfully combines informal language with authoritative boldness. At times, they’re not afraid to move away from the source, while sticking to the same concept. There were cases where the Croatian copy improved the English copy. Apple’s localization is proof that playfulness can be achieved while staying truly local. Pro. Beyond. localized as “Probija granice” (Breaks the limits). As the verb “probijati” contains the name of the model “Pro”, this is a really smart solution that feels local. Photo hasn't been localized as "fotografija", but as "fotka", which is very conversational. It’s also shorter and more impactful. Brilliant has been rendered as "Sve ti je jasno" (literally: "Everything is clear to you"). It’s an idiom that means "You totally get it". The localized text moves away from the sole idea that the picture is clear, and adds the element of comprehension – because the screen is clear, you’ll won’t have any trouble understanding what you’re reading in the bright sun. Even though the translation “Uvijek uključen zaslon. Uvijek spreman.” would be a perfectly acceptable solution, Apple decided to play around by keeping an English word that isn’t a noun and that wouldn’t be used in everyday speech as an Anglicism. “Always-On” and “always” have been retained in Croatian for a surprise effect. Good job, Apple. Recap Because of the rich cultural and linguistic history, localizing into Croatian can be a real challenge. This is especially true when it comes to brands who like to sound informal, playful and fun. Companies should be aware that using informal tone can lead either to inelegant verb endings or complex tech interventions to solve the issue. They should also keep in mind that informality can’t be achieved in the same way as in English. In order to include everyone in the country, slightly more toned-down language is necessary, and creative solutions that are different from those in the source language must be found. After all, that’s the point of localization. If done well, these efforts will most certainly pay off for brands localizing their content into Croatian. About the writer Ivan Fosin is a translator, localizer and copywriter with over ten years' of experience working with top global brands. He started his career as a translator in the European Parliament but soon became a full-time business owner. This allowed him more time to bounce creative ideas for copy around and collaborate with like-minded professionals. You can find him on his website and LinkedIn.

Effective communication is always critical - but it’s especially crucial in localization. Localization experts and product teams need to be able to swap questions and discuss translation choices. This way, they can create a version of the source that will resonate with people in the new target market. Here's how to make this work. Localization experts have an intimate knowledge of their language and culture - that’s basically part of the job description. They know the grammar, the style, the current affairs, the different cultural currents that pulse under the surface. They can tell if a piece of copy would work or sound awkward. If it’d delight people or offend them. And product teams have an in-depth understanding of their product. They take part in the research, talk to the dev team daily, help design the source content. They can say what the product is there to do, how it helps people, and why each piece of copy was selected and phrased the way it’s phrased. The real magic takes place when they come together. Then, they can ensure that the localized version of the product captures the essence of the source. That it still fulfills all the goals the product team charted. Still fits the vision the company set. Still uses the same voice and gives off the same vibes. But at the same time, still a good fit for the new market - not using the original (let’s face it, English) version as a blueprint. But for this to happen, both teams need to fully understand each other’s objectives and perspectives, and work together to ensure they get a localized version that works. Through healthy communication, they can leverage each other’s expertise. But effective communication isn't always easy - and that’s especially true in localization projects. Language and cultural differences can make it difficult for people to accurately convey what they mean, and it can be challenging to bridge the gap between the two sides. Basically, people’s view of the world is based on their cultural backgrounds. So if team members come from completely different cultural starting points, we’ll need to be extra careful to get everyone on the same page. But still, there are things you can do from the get-go to ensure communication runs smoother in your localization project. How can you improve communication in localization? Start by getting everyone on the same page. If you want your entire team to work towards the same goals, you need them to know what they are. If you want them to write good copy for your target audience - they need to know what it is. If you want them to cleverly adapt your brand voice into their language, then - you got it - they need to know what your voice is. Giving them that critical information at the beginning of the project, in a digestible and clear way, is one of the most important things you can do for the success of your project. There are several ways to convey that information. I’ve gotten detailed emails, days-long training, and team-wide video calls before. But most teams go with the tried-and-true localization brief. And it’s a solid method, as long as you create your brief well. Psst: We have a free e-guide on writing great localization briefs - click here to get it. Have a language lead: Get someone who can bridge the gap between your localization experts and the product team. This isn’t always a viable option, and it depends on how much copy you localize in that language on the reg. But if you can justify the cost, language leads can take a lot of the load off your shoulders, and help make the interaction much smoother. Language leads basically act as middlepeople (that’s a word), helping both sides understand each other's perspectives. And since they “own” the language, their watchful eye helps weed out errors before they make it to production. They often facilitate open and honest communication between both sides, making sure that feedback is addressed on time and no queries fall through the cracks. Get to know your linguists: Establishing a relationship with your linguistic team is a great way to encourage open and honest communication. Once people know your face (and you know theirs), they’ll feel much more comfortable reaching out with questions and feedback. As a bonus, they’ll also feel more included and appreciated, which is always a plus when you’re managing a team. Set up a clear process and format: Any query system can get messy fast, unless you’re enforcing some sort of standard. To prevent this from happening, define a clear process and format for communication, and make sure everyone are familiar with it before you get started. Explain the logic behind it, as it’ll motivate people to follow through. Keep your method simple and clear - the more complex you make it, the harder it will be for your localization experts to follow it. Also, let everyone know how important it is to be as clear and concise, provide examples and take time to make sure the other side understood. This will help to avoid confusion and ensure that the replies you provide will be received and implemented. Set up a mid-project status call: Regular check-ins or progress meetings are a great way to ensure that both teams are on track, and address any issues that might have come up. They also help maintain that aforementioned relationship, which is crucial for good communication. Don’t overdo it with meetings, since that would just be wasting people’s time. But even a short 15-minute call mid-project can help you stay on top of things. Stay open to feedback and suggestions: Your linguists are likely to have an opinion about your copy, and about how it’ll be accepted in their market. And while it’s hard to accept feedback from external vendors, set your ego aside and consider their comments seriously. Sometimes, they won’t be relevant. Other times, technical issues will make them impossible to implement. But plenty of the comments will contain priceless cultural insights. These can either lead to some adaptations to your copy, or even contribute to product choices you make later on. By being open to feedback, you can make sure you don’t miss on those valuable nuggets of knowledge. Choose the right communication method: There are plenty of ways for product teams and localization teams to communicate - each with its strengths and weaknesses. Choosing the right tool for your situation will set you up for success. Whichever method you choose, ensure everyone on the team can access it and know how to use it. How can localization teams communicate? There are several ways for localization experts and product teams to communicate with each other, send in queries and questions and get replies. And of course, each has its own advantages and disadvantages. Let’s take a look: 1. Good old emails: These had to be on the list because, well, they’re our main channel of communication these days. Emails let you write freeform and attach any added information you like. If you’re trying to iron out deadlines and budgets, they’re the most convenient method by far. They’re asynchronous, unlike phone calls, so you can take your time and consider things before you reply. Plus, they’re automatically saved - so they’re a great way to keep everyone accountable for the things they committed to do. But other than that, emails aren’t ideal for localization communication. Handling more than one question gets impossible. There’s zero context - as the questions sent via email aren’t connected to the copy or to any visuals. And you can’t access questions asked by anyone else - not for this project, and not in past projects. Overall, I’d be surprised to see any teams using emails for query management these days. The bottom line Pros: Freeform writing Easy to attach additional documents Asynchronous Good for sending out project requests, budgets and deadlines Cons: No context whatsoever Impossible for more than one question Can’t access questions by anyone else 2. The dreaded spreadsheets: Source Spreadsheets are a common way for localization experts and product teams to communicate. Spreadsheets like Google Sheets or online Excel files are free, easy to use, and can be shared quickly and easily. There’s no learning curve since most people know how to use them already. You can track changes (though it’s limited and quite uncomfortable), sort and filter data, and collaborate with multiple team members on one shared document. Overall, that makes them a pretty solid way to collaborate. But spreadsheets do have some major drawbacks. The questions you log there aren’t shown next to the original copy being localized, making it difficult to visualize changes and make edits. You have to keep jumping back and forth between tabs - a frustrating task, and one that very well might make people invest less time in replying. Additionally, they’re disconnected from the copy itself - which means the next time a string shows up in a localization task, the linguist won’t have that query listed there. With lots of lines and languages, everything can get messy very fast, making it hard to track what changed, who replied to what, and what conversations are still going on. So spreadsheets are not ideal for extensive conversations or more in-depth discussions. The bottom line Pros: Free Available to everyone No learning curve Tracked changes Sort and filter Shared online Cons: Disconnected from the copy No added visual context Get messy fast Bad for in-depth discussions 3. Dedicated query, bug, or project management tool: Plenty of product teams already use these bug logging or project management tools like Jira, Asana or Trello to track issues, tasks, and progress. They’re designed specifically for collaboration, making them a good choice for localization questions and discussions. Localization experts can leave their questions in these tools, attaching screenshots and some added context with ease. Even better, comment and conversational features built into these tools make discussions a breeze, and advanced filtering and statuses help teams keep their query system organized. And since teams are already using these, they’ll be more available to reply to questions on the go. That being said, these tools may be new for loc teams, and they’ll have to take time to learn how to use them. They’re still disconnected from the copy - which again, means that those questions won’t be visible localizing similar strings in the future. And since these tools are often owned by the product team, linguists won’t have access to their questions once the project is done. They won’t be able to browse through them in a future project, to learn what decisions were made, and why. The bottom line Pros: Accessible for product teams Great for longer discussions Some context possible Advanced filtering and statuses Cons: Disconnected from copy Requires some learning Questions not accessible to linguists in the future 4. Comments in the prototyping/design tool: If everything’s happening in Figma or Zeplin (or any other prototyping tool), you can have your localization experts leave their comments directly on the screens there. In some ways, this is ideal - because you have the context right there in front of you. You don’t have to switch tabs or look for the relevant screen - or try and figure out which part of the interface your linguist is talking about. Plus, if your team is used to working in that environment, they’ll be more available for comments. Your linguists will get a reply faster, which means fewer delays in your loc projects. But working with a prototyping tool has its drawbacks. Keeping comments alongside their context is great, but comments are not linked to the specific piece of copy. Move or delete the screen, and you’ll lose your context. Use the same piece of copy somewhere else, and you’ll have no way of viewing discussion history. And, you’ll have to trust your linguists to find their way around your organization system and give everyone linguists access to the file. Depending on your plan and the tool at hand, it may get pricy - or force you to compromise security by sending out open links. The bottom line Pros: Easy visual context Accessible to product teams Cons: Disconnected from copy Linguists need to figure out the file’s organization Linguists need access to the file 5. Comments in the localization (CAT) tool: Image: Comments in Localazy If you’re already past the two-screen stage, it’s likely you’re using some kind of CAT (computer-assisted translation) tool or TMS (translation management system) to localize. CAT tools have plenty of useful features designed to make localization faster, more efficient, more consistent, and overall better. And as part of the package, they also include commenting capabilities. Teams can use those to discuss any questions right there by the string (i.e. the piece of copy localized at a specific moment). Sometimes, linguists can also access questions from other linguists on that specific string - giving them added context - but that’s not always possible. Still, using these comments to discuss localization questions is a great option, as the discussion happens right there beside the copy. If you’re using a 4th-generation CAT tool (i.e. cloud-based and continuous), you’ll be able to keep coming back to those comments if you ever need to remember what questions were asked. However, when handling comments in the localization tool, teams are forced to visit there to reply. They’re usually not there to begin with, which means the whole question-and-answer cycle grows longer. And while you have textual context, you don’t always have visual context - or information about the specific place of this text in the flow. That depends on the capabilities of the CAT tool you’re using, and the amount of prep work that went into the file. The bottom line Pros: Discussions connected to the text Comments in all languages visible (sometimes) Comments saved for future reference Cons: Slower response time Limited visual and flow context Conclusion Whatever you choose to use, make sure that you have a clear process set for communication between your localization experts and product team. Build-in deadlines so that all feedback and queries get addressed on time. And instruct people to keep it clear and concise, and provide examples when possible - it’s like that not everyone on the team is a native English speaker, on both the localization expert end and the product end. Unless clarity is prioritized, cultural backgrounds and language barriers turn misunderstandings into localization mistakes.

Tooling up for localization? Check out this comparison of the top tools for teams working in Figma. As a team working on UX, it's very likely you're using Figma as your main design tool. And while it's great for designing interfaces and user flows, managing all of your copy can be a bit tricky. There's no built-in way to manage different versions of your text, so working on text components in Figma can get messy fast. Yes, UX writing or CMS tools that integrate with Figma can help with managing your microcopy when you've only got one language on your hands. But when you're handling several languages, you need a tool that can handle localization as well. And that's a much bigger challenge. But there's good news, too. Localization teams have really been spoiled for choice in past years. There are dozens of new-age localization tools out there, with a lot of them designed to fit within a product design cycle. In fact, the Figma plugin store is overflowing with plugins created to help you handle design-stage localization without losing your mind. Using these plugins, you can pull your text into your tool, get it translated, and push the translations back into Figma - all without ever messing with your design environment. But with all of these options, it can be hard to decide which tool is the best fit for your team. What's a localization team to do? Worry not. I went over some of the more popular localization tools on the market so you don't have to. Check out this comparison to see the features their plugins offer, how much they cost, and what else you can use them for. Some of these can also integrate with other tools and environments. You can use the filters on the localization tools page for a more detailed comparison. Why use a Figma plugin for localization, anyway? There are a number of reasons to use a localization plugin for Figma. Perhaps the most obvious reason is to easily send text content from Figma to be translated into multiple languages. By using a plugin, you can save time and hassle by not having to export and import files every time you need to update your translations. These plugins also allow you to quickly create localized designs - either with actual copy or pseudo translations. If you're working on a design that will be used in multiple countries, it can be helpful to have a tool that can automatically generate versions of your prototype in different languages. This way, you don't have to manually copy and paste texts to create each version yourself. Plus, using a Figma plugin can really improve communication with other people in the product team. Using a plugin, people can access the most up-to-date versions of the text and design, which can help avoid confusion and mistakes. You can even use screenshots or Figma prototypes as visual context and help your translators make better decisions. So, without further ado, let's take a look at some of the best Figma plugins for localization. Crowdin The Crowdin plugin for Figma This is one of the most popular localization tools on the market. It's a cloud-based tool that helps you manage your translations and get them done quickly and efficiently. The CrowdIn Figma plugin lets you pull your text into Crowdin, get it translated, and push the translations back into Figma. The plugin was installed over 2,000 times and has been recently updated by the Crowdin team. What can you do with the Crowdin plugin for Figma? Pull texts from Figma screens into Crowdin for translation Push localized texts back into Figma for preview Automatically pull screenshots from your Figma environment Add existing strings to new screens and designs in Figma Manage placeholder tags to make it easier for developers Automatically generate key names based on predefined patterns What's missing? Can't mark untranslatable strings Can't add pseudo-translations to your design Can't see which strings were previously translated or deleted Does Crowdin have a trial plan? Yes. Crowdin's free plan lets you have unlimited public projects with up to 60,000 words total. Note that any translations you upload on the free plan will be uploaded to Crowdin's public translation memory - so that may not be a good option long-term. But it's a great way to give the interface a try and see if it'll work for you and your team. How much does Crowdin cost? Crowdin offers 3 paid plans: A Pro plan starting at $40/month (billed annually), a Team plan starting at $140/month (billed annually), and an Enterprise plan priced individually. Lokalise The Lokalise plugin for Figma ‍ Lokalise is a localization tool that helps you streamline your translation process and manage your translations all in one place. The Lokalise Figma plugin lets you quickly add translated content to your Figma designs without having to go back and forth with your team members or doing tiresome manual work. The plugin was installed by over 6,000 people and has been recently updated by the Lokalise team. What can you do with the Lokalise plugin for Figma? Pull texts from Figma screens into Lokalise for translation Push texts from Figma to Lokalise for translation Automatically generate key names based on predefined patterns Match Figma texts with existing Lokalise keys and their respective translations Automatically pull screenshots from your Figma environment Set character limits for strings in Figma Manage plural and singular versions of strings in Figma What's missing? Can't mark untranslatable strings Can't automatically view and remove deleted texts from your project Does Loaklise have a trial plan? Yes. All Lokalise plans have a free 14-day trial. This means you can cancel your plan anytime in the first 14 days and you won't be charged. There's no credit card required, so there's really no risk at all. You can try the Lokalise plugin and see for yourself. How much does Lokalise cost? Lokalise offers 4 paid plans: A Start plan at $120/month (billed annually), an Essential plan at $230/month (billed annually), and a Pro plan at $585/month. There's also an Enterprise plan priced individually. POEditor The POEditor plugin for Figma The POEditor Figma plugin lets you create new projects directly within Figma, or work with projects which already exist in POEditor. You can also send texts from Figma files to POEditor translation projects and fetch translations from POEditor to Figma. What can you do with the POEditor plugin for Figma? Create new projects or work with existing POEditor projects directly from Figma Send texts from Figma to POEditor for translation Import translated texts from POEditor back into Figma for preview Use the text layer ID from Figma to identify each key View terms deleted in Figma and remove them from your POEditor project What's missing? Can't batch together several instances of a string Can't add pseudo-translations to your design Can't automatically view and remove deleted texts from your project Can't generate placeholders or tags to support developers Does POEditor have a trial plan? Yes. You can create a project and use POEditor for free for 10 days, no credit card required. During that time, you can translate up to 30,000 strings. After the 10 days are over, your account will be transferred to the free plan, which allows you to translate 1000 strings with unlimited contributors, projects, and languages. How much does POEditor cost? POEditor offers 4 paid plans: A Start plan at $14/month, a Plus plan at $44/month, a Premium plan at $119/month, and an Enterprise plan at $199/month. If you're looking to localize an open-source project, they'll give you unlimited strings for free. Textunited The Textunited plugin for Figma ‍ Textunited is an end-to-end translation platform that allows your team to work together to create multilingual digital content. Using the Textunited Figma plugin, you can add translated content to your Figma designs or machine-translate your entire design with just a few clicks. The plugin is maintained with the most recent version released in September 2021. What can you do with the Textunited plugin for Figma? Send texts from Figma to Textunited for translation Machine-translate texts automatically or have texts translated by the Textunited translation team Apply translated texts from Textunited back into Figma for preview What's missing? Can't automatically generate key names based on a set pattern Can't pull screenshots from the Figma file into Textunited Does Textunited have a trial plan? Yes. Textunited has a free plan you can use to translate up to 1000 words. They also offer a 14-day trial on all paid plans, which means you can give your plan of choice a try and see if it's a good fit. How much does Textunited cost? Textunited offers 3 paid plans: A Basic plan at €60/month, an Essential plan at €210/month, and a Custom plan with individual pricing. The Figma plugin is only available for users on the Essential plan and up. Smartling The Smartling plugin for Figma ‍ The Smartling plugin for Figma seamlessly connects your designers with Smartling’s translation management system in just one click. You can submit prototypes and get professional, machine, or pseudo translation. Then, use the translated content to see what your localized environment will look like before you go live. Note that the Smartling plugin for Figma only works on the Figma desktop app. What can you do with the Smartling plugin for Figma? Automatically pull screenshots into Smartling for your translators Submit copy for professional, human translation, or machine translation Generate pseudo translation to get an idea of how your product will look when translated Turn untranslatable text into placeholders Edit key IDs within the plugin Automatically exclude strings that only contain numbers or symbols What's missing? Can only be used on the Figma desktop app Can't automatically create specific key IDs based on a predefined pattern Can't apply translated copy with one click (though this can be done using JSON file import) Does Smartling have a trial plan? No. Smartling doesn't offer a trial plan or free tier. Customers need to go through a sales rep to sign up and get access to the platform. How much does Smartling cost? Smartling offers 2 paid plans: A Growth plan and an Enterprise plan. Prices aren't available on the Smartling website, and can only be accessed through a sales rep. However, customers can sign up to see a demo of the platform. Transifex The Transifex plugin for Figma ‍ Transifex is a cloud-based translation management system that allows you to manage and translate your digital content with ease. The Transifex Figma plugin seamlessly integrates the two platforms, allowing you to submit copy for translation, preview localized designs and boost collaboration between designers and translators. This Plugin is priced separately, and can be purchased through Transifex support. What can you do with the Transifex plugin for Figma? Submit copy for translation Apply translated copy to preview localized designs Automatically pull screenshots from Figma into Transifex Manually remove unneeded strings as you sync copy to Transifex What's missing? Can't automatically generate key names based on a set pattern Can't generate placeholders or tags to support developers Does Transifex have a trial plan? Yes. Transifex has a 15-day free trial plan - no credit card required. Customers can also sign up through support to see a personalized demo. How much does Transifex cost? Smartling offers 3 paid plans: A Basic plan starting at $70/month, a Premium plan starting at $105/month, and an Enterprise plan with individual pricing. Note that you'll have to pay separately for the Figma plugin. Localazy The Localazy plugin for Figma ‍ Localazy is a continuous localization platform and web-based translation management system (TMS) that set out to make the localization experience efficient and enjoyable. It's meant for anyone, from individuals to large teams. We did a detailed review of the Localazy plugin for Figma here. What can you do with the Localazy plugin for Figma? Automatically pull screenshots into Localazy for your translators Submit copy for professional human translation or machine translation Continuously upload new copy for translation ("auto-pilot") Generate backlinks to Figma to use your prototype as visual context Push localized copy into Figma for preview Use the text layer ID from Figma to identify each key What's missing? Can't edit key IDs within the plugin, or generate specific key IDs based on a predefined pattern Can't set specific pieces of text as placeholders or tags Can't automatically view and remove deleted texts from your project Does Localazy have a trial plan? Yes. Localazy offers a 7-day free trial on all plans - no credit card required. They also offer a free tier with 200 source keys, which you can use to give the tool a try. How much does Localazy cost? Localazy offers 4 paid plans: A Professional plan at $9/month, an Autopilot plan at $49/month, an Agency plan at $99/month, and an Enterprise plan with individual pricing. Lilt The Lilt plugin for Figma ‍ Lilt offers end-to-end language services and technology for global organizations. They work with professional translators and an in-house service team to help companies do content localization at scale. Using the Figma plugin, companies can translate and test out designs in every language. What can you do with the Lilt plugin for Figma? Send Figma copy for human or machine translation at Lilt Push localized copy into Figma for preview Pull texts from any translation memory in your Lilt account See the translation status of each piece of copy in Figma What's missing? Can't add pseudo-translations to your design Can't pull screenshots into Lilt for translators Can't set or edit key IDs from Figma based on a set pattern Can't set specific pieces of text as placeholders or tags Does Lilt have a trial plan? No. Lilt does not offer subscriptions, and therefore does not have a trial plan. However, their services are priced per-word, and so clients can start with a small project to test them out. Clients can also schedule a live personalized demo. How much does Lilt cost? Lilt users pay by word, with prices depending on the type of service (machine vs. human), language, and many other factors. Smartcat The Smartcat plugin for Figma ‍ Smartcat is a solution allowing companies to tap into a global marketplace of freelancers and professionals. Their built-in translation management system helps companies create automated workflows and manage large and small localization projects with ease. The Smartcat plugin for Figma makes access to Smartcat translators even faster. What can you do with the Smartcat plugin for Figma? Send texts from Figma to Textunited for translation Get human or machine translation at Smartcat View localized versions of the copy quickly in Figma What's missing? Can't pull screenshots from the Figma file into Smartcat Can't set or edit key IDs from Figma based on a set pattern Can't set specific pieces of text as placeholders or tags Does Smartcat have a trial plan? No, but it does have a free tier. The free Smartcat tier offers a lot of robust capabilities, on top of 10,000 translatable words. It's a great way to give Smartcat a try and see if it'll work for you. How much does Smartcat cost? On top of its free tier, Smartcat has 3 paid plans: A Rise plan at $249/month, a Unite plan at $549/month, and an Enterprise plan with individual pricing. The Figma plugin is available on all plans. Phrase The Phrase plugin for Figma ‍ Phrase’s translation management system enables teams to efficiently handle design, writing, and development, and create a great user experience anywhere. Their Figma plugin is designed to overcome communication barriers between the product and translation teams, and build a bridge that'll streamline localization work. What can you do with the Phrase plugin for Figma? Pull texts from Figma screens into Phrase for translation Push localized texts back into Figma for preview Send copy for machine or human translation within Phrase Generate key names based on layer names in Figma, and edit key names directly in the plugin Clearly see which strings were already sent to Phrase Automatically pull screenshots from your Figma environment Connect several instances of a string and set one instance as a source of truth What's missing? Can't manage placeholder tags to make it easier for developers Can't automatically generate key names based on predefined patterns Can't use pseudo-translations in your design Does Phrase have a trial plan? Yes. Phrase offers a 14-day free trial on all plans - no credit card required. The trial plan doesn't limit strings, words, or languages, so you can really play around with it quite a bit. There's also the option to book a personalized demo. How much does Phrase cost? Phrase has 3 paid plans: A Basic plan at $23/month, an Advanced plan at $35/month, and an Enterprise plan with individual pricing. Note that these prices are per user, but the Advanced plan requires customers to subscribe at least 5 users, while the Enterprise plan is only available for 10 users and up. These tools all offer translation management systems that can help streamline your localization process. Depending on your needs, one of these solutions may be a better fit for you than the others. Almost all of them offer free tiers or trial plans to get you started, so it's worth giving them all a try to see which one works best for you. Happy localizing!