Here's something I know to be true: Big, industrial-like localization flows dehumanize linguists. 🔵 Ideally, we want our linguists to think big and be proactive 🔵 But when people are treated like a cog in the machine, they're bound to stay inside their tiny little cog space*. * I don't know machine lingo but I'm committed to this metaphor, OK? If we want quality, we need to start humanizing translators again. That's exactly what I talked about with Marta Boer in this episode of the Localization Process Pod. If you haven't given it a listen, now's your chance to add it to your list. But if you're in a rush (aren't we all? Always?) and want to make sure you get the gist, here's the bullet point version just for you: Emphasize trust When you're hiring translators, trust is your best friend. Invest time and energy into building relationships with your vendors. It keeps everyone commuted and engaged, and it's essential for long-term success. Humanize the process Translators should be treated as valuable team members rather than just service providers. A humanized approach leads to better engagement and higher quality work. Give language leads some autonomy Allow language experts some level of autonomy in choosing other team members. A sense of teamwork can encourage individuals to contribute more effectively to the project. Give feedback its place Providing clear guidelines and constructive feedback is important for the growth and improvement of translators. Sharing style guides, glossaries, and project instructions upfront can set the stage for high-quality work. If possible, get a vendor manager Having a dedicated vendor manager can be beneficial for managing translator relationships effectively. If a full-time position is not possible, assign this responsibility to a capable team member.

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

A few months ago I got a lovely gift: A watch. It may have been a hint. I used to be a punctual person, but with an overloaded plate of routine tasks, I might have teensy-bit neglected my commitment to timeliness lately. But anyway. It was a nice watch and I liked to wear it, and be the person people came to for time advice. That joy lasted for a while, but then... The watch tragically stopped working. And that meant I had to do one of my least favorite things in the world... Reach out to customer care. You already know I'm a content person. And the fact is that many companies have got gorgeous front-room content. Beautiful ad copy. Glorious site wording. Marvelous checkout texts. But then, once customers make the purchase, there's a significant drop in content quality. 🔵 The templates are often poorly written, are so far from the brand voice they may be on another planet, and are full of grammar mistakes. 🔵 The people editing those templates (customer service reps) are often not fully fluent in the language they're meant to be writing in. 🔵 Localization makes this worse, as the already-poor source makes for a bad starting point, and there's rarely enough context provided as templates are meant to fit many cases and get adapted later. This is the response I got this time, from this Spanish watch company. The fact is that to create a great experience for our customers and users, we need to embrace a 360 approach - for both source and localized content. Yes, you can start with one piece of the puzzle. Real improvement is incremental. But in your long-term plans, you should always strive to have every single touch point on-brand and strategically phrased. Post-purchase content or edge case copy are just as critical, and can have a huge impact on things like stickiness, retention, and more. So in this newsletter, I wanted to send over some resources on creating content for those areas. I hope these will help you place the spotlight on some neglected gaps in your company's content. So in this newsletter, I wanted to send over some resources on creating content for those areas. I hope these will help you place the spotlight on some neglected gaps in your company's content. Six localization tips for multilingual customer support Gabriel Fairman for BureauWorks Read now Content design and legalese: Collaboration within constraints Panel by the UX Writing Hub Watch now Improving the help center experience with user-centered design Sulaimon Salako for UXCC Read now When life gives you lemons, write better error messages Jenni Nadler for Wix UX Read now Writing user feedback requests: Five guidelines Anna Kaley for Nielsen Norman Group Read now Boost conversions with transactional emails: A dummy guide Samavia Malikfor Unlayer Read now Are there any other often-neglected touchpoints you think should be covered?

What do you think the future of UX localization is? I'm an early adopter at heart, so more than anything, I'm curious to see what the future brings. But while we can find any number of predictions for the future of localization in general (ranging from: "the robots are coming, run for your lives" to "ignore the doomsday prophecies and carry on'"), I think UX localization just might take a different path than the rest of its loc siblings. Why? First of all, the metrics we use (or should be using, ehm), to measure success are different in UX. It's not all accuracy and correct punctuation. It's emotion and engagement and experience. And if what we define as "success" is different, it's likely we'll also go about achieving it in different ways. But the ingredients for success are different too. Think about it: To do many types of localization, you need proper context, subject matter knowledge, and a good grasp of the source and target languages. But that's not enough to create a good user experience. UX localizers – just like UX writers – need to understand the flow of information, design principles, and development constraints, just to name a few. Yes, it's a lot. And most of all it means that as UX localizers, we need to make our own predictions about what's going to happen. To satisfy my curiosity and my incessant need to always be prepared (not a girl scout but will take the cookies if offered), I've been walking around and asking people what they think will happen. I've gotten a bunch of interesting replies, and thought I'd share them with you. The doomsday approach Time to find a new career, but no rush No need to expand on this one, I think. Some think this is the end of human linguists in localization, UX included. Despite that, even the most pessimistic of them agree the robots will take longer to gobble up UX localization jobs, compared to other translation niches. That's because companies still hesitate to use MT for their UI copy. If you're a linguist, this means you'll have longer to find your bearings in your new profession. If you're a buyer, it means you still have time to get a feel of the land and find the best MT-based workflow for you. The happy medium approach It's adapt or die, but you can definitely adapt Others think humans will always have a role in UX localization, but the focus might shift. I agree with this one the most. I think in a decade, we'll have a hard time remembering how we've ever created UX copy (in any language) without the help of AI tools. But that being said, we'll always be there in some form or another: 🦾 To train and fine-tune the models. 🦾 To curate and direct the results. 🦾 To run some QA and a sanity check. That is especially true for UX localization, for the reasons mentioned above. Experiences are heavily based on culture and emotions, and those shift and change and evolve constantly. Without retraining and fine-tuning, we won't be able to stay up-to-date with current language trends. That is until the flow of information becomes dramatically, futuristically fast (and that should still take a while). The ostrich approach Nothing is happening and nothing needs to change Sorry if it's judgy, but there are still some who say it's all a storm in a teacup. A beautiful yet non-realistic expression, in this case. Here are some claims I've heard: 🐦 "Linguists have been saying that robots are coming for their work for decades. It hasn't happened yet." To this, I say: Have you looked at the going rate for translation these days? 🐦 "There will always be work for good linguists out there". True. But the way the industry defines "a good linguist" is changing. To be considered, you still need to adapt and upskill. 🐦 "Technology will never get good enough to replace me. Look at this ridiculous Google-translated line I've just randomly encountered". But the fact that free machine translation is bad does not indicate that gated, b2b-oriented services are bad. And the fact that it's even remotely usable today is proof of how fast it'll get to human-like content creation. Which approach do you agree with? Are you a doomsdayer 🙀, a balanced middler-grounder 🦾, or an ostrich 🐦? Let's discuss! Heads up 🚨 The UX writing course for localizers is opening for enrollment real soon. This time we'll meet in the mornings (CET) and it's a rare opportunity to see me less tired and in daylight (exciting, I know). I expect this cohort to be in high demand, as there are quite a few people already listed to enroll. So if you're planning on joining, stay tuned to learn when enrollment opens!

In our interconnected world, reaching a global audience is a key goal for many businesses and organizations. However, one challenge that often arises when expanding internationally is ensuring that the user experience (UX) of your product or service remains impeccable across different languages and cultures. UX localization is the solution to this challenge, but it's more than just translation; it's about creating an experience that resonates with users around the world. In this article, we'll explore the top 5 tips for UX localization and the reasons why they are crucial for success. This is a guest post by ProTranslate. 1. Understanding cultural nuances Localization is not just about language; it's about culture. To create a user experience that truly resonates with your target audience, you must understand the cultural nuances that can impact user behavior and expectations. Different cultures have distinct ways of expressing themselves and interacting with technology. By understanding these nuances, you can avoid cultural missteps that could alienate users or even lead to misunderstandings. For example, colors, symbols, and gestures can carry vastly different meanings in different cultures. Knowing these subtleties allows you to design a UX that feels natural and respectful to users worldwide. 2. Prioritizing user-centered design User-centered design (UCD) should be at the heart of your localization strategy. This means involving users from different regions and cultures throughout the design process. Conduct user research, usability testing, and gather feedback from your target audience to ensure that your product or service meets their specific needs and expectations. UCD ensures that your localized UX is not just a one-size-fits-all solution. It's tailored to the preferences and behaviors of your diverse user base. What works well in one culture may not be effective in another. By involving users in the design process, you can identify and address any issues early on, saving time and resources in the long run. 3. Consistency across platforms Maintaining consistency in UX design across different platforms and devices is crucial for creating a seamless experience. Users should be able to transition between web, mobile, and desktop versions of your product without feeling lost or confused. Inconsistent UX can lead to frustration and confusion among users. It can also harm your brand's image. When your UX is consistent, users feel more confident and comfortable using your product, regardless of the platform they are on. This consistency also reinforces your brand identity and message, making it easier for users to connect with your product. 4. Paying attention to language quality While this may seem obvious, the importance of high-quality language translation cannot be overstated. Sloppy or inaccurate translations can not only confuse users but also damage your brand's reputation. Language is a fundamental part of UX localization. Users rely on clear, concise, and accurate language to understand and navigate your product. Poor translation can lead to misunderstandings, frustration, and, ultimately, abandonment of your product. To ensure high-quality language in your localized UX, invest in professional translators who are not only fluent in the language but also familiar with the culture and context of your target audience. 5. Test, test, and test again Thorough testing is the cornerstone of successful UX localization. Conduct usability testing with users from different cultural backgrounds to identify any issues or pain points in the localized version of your product. Continuously iterate and refine your design based on user feedback. Testing helps you uncover issues that may not be apparent during the design phase. It allows you to see how users interact with your product in real-world scenarios and make adjustments accordingly. Testing also provides valuable insights into the effectiveness of your localization efforts and helps you fine-tune the user experience for different regions. UX localization is not just about translating content into different languages; it's about creating a user experience that feels natural, culturally relevant, and user-centered across the globe. By understanding cultural nuances, prioritizing user-centered design, maintaining consistency, ensuring language quality, and conducting thorough testing, you can create a UX that resonates with users worldwide. Investing in UX localization not only expands your market reach but also enhances your brand's reputation and fosters user loyalty. In today's globalized world, these tips are essential for crafting seamless user experiences that transcend borders and languages.

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.

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.

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.

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!

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.

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.