"Yay, you did it!" "Congratulations!" "Awesome!" Little digital affirmations like these, known as success messages, are an important part of making our apps, software, and websites feel great to use. However, these messages aren't one-size-fits-all. The way we celebrate and convey success can differ a huge amount depending on where we are in the world. Picture successfully setting something up, completing a task, or unlocking an achievement, only to be met with a digital response that feels wildly inappropriate. It's a jarring, immersion-breaking experience. As UX experts, getting localization right for these tiny but key bits of microcopy can be the difference between your product feeling genuinely tailored to a global audience, or culturally tone-deaf. Our idea of success is shaped by our culture — and this has a widespread impact on our choices when it comes to localized success messages. For example, for many Western cultures, achievement is an individual thing – it's about effort, winning, and personal gain. Our success messages reflect this: "You nailed it!" or "You're a star!", or in the case of this message from Bloom, "Beautiful work". In contrast, some other cultures emphasize harmony and the collective; overtly celebrating personal success could seem boastful or insensitive. And that’s not all of it. Essentially, we understand and express our feelings about success differently as well. In some cultures, a quiet, satisfied "Well done" might be the most effusive response, while in others a burst of celebratory emojis will have a much more positive impact. Take a look at this Starbucks message - would it work in your language? It's not always about happiness Hang on... I just talked about happy celebratory moments, but success messages don’t always fit into that box. Surprisingly, success isn't always a good thing. Consider the success message you might show after a user deletes data, or unsubscribes from a service. These actions might be necessary, even a relief sometimes, but do they really warrant a joyful message? Probably not. Take a look at this message from Turo, for example. Cancelling a trip warrants some confirmation - but it's very likely we won't be happy about it. And, of course, this is where localization can get even trickier. People from different cultures may expect different kinds of acknowledgment, even if the outcome is neutral or bittersweet. Imagine canceling a service after a negative experience – a tactful confirmation like "Your request is being processed" might be the most culturally sensitive response. Yet, in a different market, that could read as cold or even passive-aggressive. Triggering the right emotions (and avoiding the wrong ones) Okay, so localizing success messages is about way more than just swapping out words. It's about hitting the right emotional notes – but how? Here's where collaboration with in-market experts is vital. And this comes into play in several ways: 1. Work with cultural advisors to adapt the tone of voice: Is it formal, friendly, or playful? Success messages should align with the product's established tone, but this can be flavored with cultural nuances. Cultural advisors can offer deep insights into how successful outcomes are understood and expressed within the target region. These insights are priceless. 2. Allow some creativity, especially in celebration & encouragement: Instead of generic "success" messages, consider ways success can provide value to the user.  In our busy digital lives, users often appreciate success confirmations that offer additional value. Instead of just saying "Email Sent!", the message could ask, "Want to send another?" or provide a direct link to the outbox. This blend of acknowledgment and action saves the user time and effort - just like Wise did here, nudging you to add some money to your account while you wait for your card to arrive. When designing these messages, keep the audience in mind - since they could have a different effect than you’d expect. For example, showing the next steps may be motivating for some audiences, while telling users to ‘relax’ might be better for others. Sweetgreen is telling users to "sit back and relax". Will that work for your market, or will it make users antsy and agitated? 3. Think about visual Accompaniments: It's not just about the words! Visuals like icons, animations, and images will help you make the success experience better. They can reinforce a humoristic tone, lighten up a heavy message, or make your content a little bit more relatable. Check out this message from Gojek below - did the illustration enhance the experience in your opinion? Certain shapes or icons may carry positive associations in the region that could be incorporated, making the message feel more familiar, personal, and natural. Some pitfalls to avoid 1. Don’t expect the English copy you wrote to be effective everywhere. Even if you've tried to write your English-language success messages with sensitivity, there are always nuances you'll miss if you're not intimately familiar with the target culture. Seemingly simple phrases might evoke an unexpected reaction (positive or negative) depending on context. Example: "You crushed it!" sounds enthusiastic to a Western ear, but directly translated might come across as excessively violent or aggressive in a different cultural market. It’s a good best practice to run user testing with people from the target region. That’s the most reliable way to uncover unexpected meanings. Provide them with your English message and ask them what feelings and associations the message evokes for them. Remember, YOUR cultural norms aren't the baseline. Test those messages on users representative of your target region. 2. Don’t assume you know better than your local experts. Have a discussion instead Localization specialists and cultural advisors bring expertise that, by definition, you don't have. Overriding their suggestions because something "sounds better" to you risks undermining the entire localization process. Example: Your cultural advisor might suggest a success message that sounds wordy or even a little subdued to your ear. However, that might be the perfect tone for the target market, and pushing back could lead to a message that comes off as culturally inappropriate. If you’re still not sure, always ask why. Have your in-market experts explain the cultural reasons that a phrase or tone works better than your initial idea. This is a fantastic opportunity to deepen your own understanding. 3. Don’t go for "fun" at all costs Humor is one of the hardest things to translate. It’s built on shared references, expectations, and wordplay, all of which are incredibly difficult to translate accurately. A harmless attempt at humor can easily turn cringeworthy, confusing, or even vaguely offensive in another language. On top of this, overly enthusiastic celebratory language can feel ironic or even cynical. A more understated, almost factual acknowledgment of the user's progress can be cooler and more in line with certain market segments. Example: A punny success message like "Nailed it!" is delightful only if the user recognizes both the literal meaning and the celebratory slang use of the word "nailed". If the phrase is translated word-for-word, it's likely to simply be confusing. So when in doubt, keep it understated, especially for high-stakes interactions. A neutral-positive tone is much safer than attempting to replicate a sense of humor that might get lost in translation, literally and figuratively. By the way, that doesn’t mean the source copy has to be stripped of its creative or fun side. A localized version can stray from the original as long as it maintains the same overall meaning. Extra Credit: Related contact points to consider 1. The opposite of success: failures and errors How do you convey that something hasn't quite worked, or needs extra information with cultural sensitivity? 2. Micro-celebrations Even small bits of progress, especially on complex tasks, can benefit from messages tailored to the market. And you don’t have to stop at words. Tiny visual cues, like a delightful animation or a subtle color shift, can convey positive feedback in a way that feels universally understandable. 3. Sound for success Don't neglect audio cues! A subtle celebratory sound effect for micro-wins, or a reassuring tone to accompany progress updates can work across language barriers. As always, ensure the sounds are tested, as the same celebratory fanfare might not always be interpreted as positive. 4. Timing of the celebration When success is a slow burn process (think multi-step applications), is immediate gratification valued? Some users in a high-speed culture might enjoy instant positive affirmation, while others might find it distracting until the larger task is complete. That's it - hope these tips gave you something to think about! Now go forth and localize some fantastic success messages. Good luck! :)

What's the best way to make progress in localization? Aglaia Pavlerou, a localization expert and manager, joins us on the Localization Process Pod to share how incremental improvements brought on a big change. From better localization quality to a more positive approach towards localization, and even business success. Audio Text video Key takeaways Dedicated localization teams offer more value than just localization. Their attention to detail and holistic view helps them support other teams with unique insights. In-house teams allow more direct management and quality control compared to outsourcing entirely to LSPs. Understanding the processes used by vendors is important to identify areas for improvement. Consistently using the same translators offers improved quality, thanks to their commitment and their familiarity with content and terminology. Showing quick wins can help get support from management for localization initiatives, and enhance collaboration with other departments. About Aglaia Pavlerou Aglaia is a localisation expert passionate about product localisation and translation quality. She has 16 years of experience working for LSPs and advertising agencies, as well as in the travel/hospitality and music/ticketing industry as a resource manager, project manager, account manager and localisation manager, as also an independent localization specialist for start-ups and well-known brands. Enjoyed the Localization Process Pod? In every episode, we'll be learning from one guest about the way they do localization for digital products. Subscribe here, on LinkedIn, or on the Localization Station website to get notified about the next ones. Transcript Michal: Hi, welcome to a new episode of the localization process pod. It's been a while since we met. Some unsettling developments in the world meant I had to take a moment to regroup. But I'm so glad to be back to talk about the best ways to create localized digital experiences for international audiences. So just to quickly refresh your memory, in every episode of the podcast, we meet with someone from a different company to grill them on what they're doing right, what they're doing wrong, and how they are optimizing their processes for a better localized experience. Today, I'll be talking with Aglaia Pavlorou, a localization expert with 16 years of experience in the field. Aglaya worked as a resource manager, as a project manager, account manager, localization expert, and localization manager. So she did it all. And she has some fantastic insights to share with you all today. So Aglaia, thank you so much for taking the time to be here and share your experience. I think we're going to talk today about a role that you have been doing, but not doing at the moment, right? It's a previous role. Aglaia: Yes. Michal: Yeah. So you want to tell me a little bit about it? Aglaia: Sure. I started as a translation project manager for a company. It was a B2B company in the travel industry. So a hotel wholesaler that would then provide a selection of rooms to different travel agents across the world. So I initially started working there alongside the content team, the team responsible for checking all the information attached to the hotels and the rooms and writing bespoke hotel descriptions for these locations. And we would just be exporting all that content, sending it out to an LSP. And then it was just coming back and fed back into the system. So before I joined, there was the intention of having this content coming back, reviewed by internal language speakers. And there were quite a few of them because we had quite a few salespeople responsible for different markets in Europe. However, it was not their main responsibility as it happens in many companies. This is an additional task that sometimes due to the workload, people cannot really pick up. So the company felt that they were investing a lot in translation, but there was no one there to check the quality or ensure that this is exactly what they need, provide some feedback, provide some guidance to the translation agency. So when I joined, I started looking at the content that was coming back. I had a few meetings with the translation agency trying to figure out what their process was, understand how they were approaching these exports that we were sending. I started looking into organizing that content better. So potentially rather than sending any new hotel descriptions that we were writing, we wait and do this once a month and maybe group them by destination or some other form of organization so that there is some consistency in the content and it's not just random things coming in for translation. I also asked that we use exactly the same translators every time and because there was no sort of big time constraint on our hands, we could wait until the team is available to pick up this work again, provide some consistency there. And then I looked into providing some very top line feedback. Everybody who works in localization and translation, they can... if not proofread, at least proof check some of the languages. So sometimes just looking at things in bilingual view, you can already look at anything that can go wrong, you know, punctuation, all this kind of like top line things. So I would provide feedback at that level. But then of course there was a lot of content and there was not enough progress as we would have wanted. So I suggested that we just take some time to regroup. Look into what is the most common feedback? What is it that we're missing? And we realized that it was mainly the terminology that that particular industry was using that we were not getting right. And even if, you know, sometimes the translators would get it right, there would be no consistency through every batch. So I suggested to my manager to bring in some freelancers to help us kind of create those reference materials in the first place. My suggestion was that we bring in a team of translation freelancers, ideally specialists in the area of travel. We just bring them in for three months. They have discussions with internal language speakers. They learn how do we speak to, you know, partners in our local markets, understand the lingo. They bring also in their expertise and we take three months to put together a glossary and some style guides for every market and set the standards that we would then share with the translation agency. At the same time, the best way to put together these reference materials is actually starting to translate the content yourself. That's how you discover exactly what is needed. So, We did this, I think it was at the time when remote working for full time employees was not really an option. So we had to build this team in-house in London and it was really a great experience for me. The company sort of thought this was a great idea, but they did not really want to invest so much in that. So I did the recruitment myself, through translation platforms that I was also using as well, getting in touch with some of the universities in London that I had collaborated in the past. And I put together a team of 80 translators. So that was for French, Italian, German, Spanish, simplified Chinese, Japanese, and Brazilian Portuguese. And the results straight away were spectacular. And that's because when translators come in and they start looking at the content, they don't just look at it from the point of translation. They just analyze it, they double check it, you know, they question it. So we started seeing the results, not just in terms of building up these references and all the translation quality that the team was producing, but also productivity and how that had increased due to putting together this very detailed process. It was really amazing. So we ended up extending the lifespan of that team and the whole thing became permanent. And that was kind of like the first step. And then we continued with a few more, but that was kind of the big first step that helped us to very quickly show the business what was the value of having these people in house and sort of committed and focused to that content full time. Michal: That's amazing. So first of all, what I like about this. We're just at the beginning and you just started telling me about it, but I really like that you kind of took control over what you're doing in localization. I think a lot of the times companies, they relinquish that control to the LSP, to the vendor, to whoever's kind of managing their process. And then you don't know what to fix, right? You know something is wrong, but you have no idea how to fix it because you don't know what's going on. I think... you say that hiring linguists was the first step. I think that was the first step. It's kind of just taking control over it and saying, okay, we need to understand what's going on so we know how to fix it, so we know how to improve it and optimize. That's amazing. Aglaia: I think this is a really big challenge when you join a company, when you're client side and you come in, you have to assess where in the, kind of like, localization journey this company is and find the best solution for them. It's quite nerve wracking. It's a big responsibility, something that you take on yourself. You coming in as a specialist, you're the only person that is specialized in that area in a company where everybody else is interested in something else. That might be hotels and rooms and swimming pools that are closed for the month, you know, causing issues. And you're there thinking about language and terms and things that they're not really important to most of the company. So it's a big responsibility and It's also very difficult to make a decision that would also make sense down the line considering how quickly things change and how quickly companies grow. Michal: Yeah, absolutely. if you were the only person, kind of, advocating for better localization, how did you manage to convince your colleagues, your management, to go ahead with this? Aglaia: At the time I had great support from my manager, who was the marketing team lead. We were set up under marketing. And... not speaking just English, I think that already gives someone more insight into why translation is important and why it is something worth looking at. She was very supportive and we basically put together a business case where we showed the expected return on the investment of just having these freelancers in for three months time. It was very difficult, obviously, because we're making a lot of assumptions about potentially the money saved down the line. But also, and this is, I guess, a topic it's always coming up in discussions about how to influence the localization process in a company is how do you attach a value to translation quality and content quality. Because it is very difficult. And that's how we started this conversation. How can you prove that translation quality has directly affected great results in the market. It's very easy to do it when there is localized content or not, but it's very difficult to say, okay, this exact percentage of increased sales in the market is due to the fact that the localized content reads so much better now. Michal: Yeah. The experience is better and not just exists. Absolutely. I completely agree. So how do you manage to prove that? How did you manage to say, okay, localization is better now because we have invested into this process and hired people who are more invested in the quality and then it led to better results. How do you manage to prove that? Aglaia: It sort of happened a little bit indirectly. So, for myself, this is the thing that I could sort of put forward, that with the same budget that we allocate to translation every month to outsource it, in three months time, I can set up this team. Which obviously, you know, having a team in house, it also has all these overheads, you know, so I took that into consideration. I propose that we can make this investment, bring this team in and obviously get to translate the same amount, but also at the same time, look at all these important quality questions and put together all these references that we think are very, very important. So once I managed to show that this budget would be more or less the same and we'll be getting more out of it, that was the first step. So that was an easy comparison to make. But basically what happened down the line was that... Because the content was organized better before sending it to translation, so putting it together in batches where, you know, we would just work on translating descriptions of hotels around the same area, it was easier for the translators to also provide feedback to the content team. So whilst we were doing this process and we were sitting right next to the content team, we were able to flag either inconsistencies on the content or maybe mistakes in the descriptions, typos... Obviously, whenever you put something through a translation platform and you keep repeating certain words and the typos are even more obvious from the beginning, the moment you open up the file, you see something is 97 percent match and then you see the typo. So they're very easy to pick up. So we started having these conversations, or maybe sometimes arguing about what color is the roof of a certain hotel. Between the content team and the translation team, there were some fun moments. And we then realized, having brought all these experts... because this is another thing that I wanted to do when putting together the team. There were some younger linguists that might have just left university. They were very eager to work and I know how difficult it is sometimes to find an in house translator position. So I know this is a very exciting opportunity. You know, there was a lot of drive on their side, but also I had some more experienced translators. Some of them had actually worked in other travel companies and they brought a lot of expertise with them. So I basically opened up the space and I let them take the lead and influence the processes and bring in all this expertise. So at the time I was actually really young and I was just there as a translation project manager. I was just there coordinating and bringing everybody together and ensuring that we're using a process where all of this work can be documented. As we kept working, I realized that there is a way that we can organize this work because the content, in a way, it was repetitive, but there was no consistency. So, what we suggested to the content team is... why don't we organize all these hotels based on their areas? So, what if we would break up London, let's say Central London, in six or seven different areas that make sense? How people would look for them, you know, when they want to book a hotel, they will probably look for West End, Covent Garden, Liverpool Street, you know, around either transport hubs or areas of entertainment. And then once we have decided how to split this, then we can just write really nice area descriptions. And then whenever we have a new hotel in that area, we just drop that description there. This means that we have this consistency every time, mentioning the same sites and means of transport. And then this means that also the content team can save about 15 percent of their time when they write a new hotel description. Then there was a lot of practical information that was kind of repeated all the time. So whether there was a private parking facility in the hotel, if it was a parking facility nearby, if there was a swimming pool available... So then we said, okay, how about we standardize all the sentences, but we always describe this in the same way. So we prepared this kind of defaults and this is how to describe the swimming pool, the parking facilities, et cetera. So, by doing all this work, the content team started saving about 20%, I would say, whenever they were writing a new hotel description. That, times the amount of work that the team was going through... I think at the time they had maybe six or eight writers that were also doing a lot of fact checking and a lot of other tasks, but that was the main task. That brought huge savings. But also that meant that when we moved to translation, we had translated that area description once, and then that was a match every single time. Same with all the other kind of default description sentences. We translated this once and then it became a translation memory match. And that also kind of brought up our productivity. At some point, the team was able to go through 5,000 words a day. Which was amazing. So the more we invested in the process and looking at the content and rearranging and reorganizing it, there were savings on both sides on both teams. And at the end of the day, this is what the leadership of a company wants to see. Savings, either time savings or cost savings. And at the same time, we're able to improve the quality of the English content and the translations. And then that sort of started coming through. As I mentioned, indirectly – feedback from either the sales teams, receiving feedback from the local travel agents saying how the content is really great. It's very consistent. It's very easy to look at the hotel descriptions and kind of compare and explain to clients what are the hotel's best features, because the rest of the content is kind of similar, so you don't have to read through carefully, you just look at what is different and you can focus on that. That also helped the company secure some partnerships. So bringing in this great quality English content and translations helped them work with some really famous brands. One of them was a very big airline that also provides holidays under the brand. So they would kind of link their flights booking option with. a hotel booking option and that would actually fit through our system. Because it would not only bring the allocation and the competitive prices, but also would bring in our content. So that was one of the pluses in the process. I think the markets where the quality of translation really was shown through was in China and Japan. And I think this is where there were great sales wins because the content was really, really great. And we would get this feedback especially from Japanese sales team, that the content was one of the biggest draws for travel agents to work with that company. Michal: Why do you think it was so dramatic in those markets? Do you think that it was just by chance you had really good linguists, like increasingly better content for those markets? Aglaia: That's a very good question. I think it might be a combination of the two. I think there's also an added layer of difficulty trying to break into these markets from Europe or a brand from these markets breaking into Europe, there's another level of difficulty. In a previous job, I was the person responsible for resourcing translators for a luxury jewelry brand that was aimed at some of the Asian markets. So they had really great, beautiful ads and great content. And we had to adapt these for Japan and for China, Taiwan and Hong Kong. When we won the business, we had to do several tests to see sort of what teams of linguists would work best. So we had a small pool of translators who were specialized in that area. And then we would do tests with different content to see what is the best combination, who should be the editor, who should be the translator, swap the roles around, swap the teams around to find the best match. And what we found out was that the best results we would get was when the translator was based in country. And when the editor was based either in Europe or in the U.S. The translation was always correct to begin with. And then we would get that kind of like final finish from maybe translators who are based in Europe or in the U.S. and have kind of like a better understanding of the marketing and branding nuances that are sometimes sort of hidden in maybe the artwork or the copy. So that was the winning combination and we sort of stuck with that. Which was also making work a little bit different, working with all these time zones. So, I'm not really sure, but I think, and I've also seen it other times, being able to bring the translators in house, even on a part time capacity, and expose them to how the company works, and involve them in different processes. I think this is where, it's not just a job where you just open a file, you translate, and then you send it back. You give them the opportunity to immerse into everything that the company is about. So you don't just see the content, but you also see the values of the company, the goals, the long term strategy. And obviously the more time you spend being attached to a certain brand, the more you sort of...become part of it as well . And I've also seen it for myself when I have been freelancing, when you get a better insight into the company and how it works and what happens to the content before it comes to you, what happens to it afterwards, you get this kind of like full view of how things are working and how small decisions or small details influence the process before and after. Michal: Yeah, absolutely. I want to take us back a little bit in the conversation. You mentioned that you proved the value of the quality improvement in the savings for the company. Which is a really big aspect of it, but I'm also curious if you managed to test how that improvement influenced the way that your users and customers behaved within the website. And were you able to collect any data that kind of showed that improvement in localization actually? Affected the bottom line, the usage rates, any analytics or data in that space. Aglaia: So that was not really possible in that specific scenario because the company at the time did not have their own website because it was a B2B company, not a B2C company. They were sort of plugging all this content into other websites. Michal: I see. Aglaia: It was very difficult for us to be able to get that direct data on this, other than having the information from the sales teams on other feedback they got from the ground or how they use this updated and improved content as an additional tool to get new partnerships signed. That was something that I was not able to look into at the time, but it is something that I'm interested in and I'm looking to different ways to implement it in my current position. And I'm just thinking if it is possible to actually break down feedback on the user experience to look into how the language has affected that. I think it's very difficult to do that because it's not just the language. It's not just translation. It's also how the design interacts with every language and then how far this is localized and adjusted to the local market. The localization process also plays a role, whether linguists are able to look at the whole website page and work on it in one go, or do they get just one paragraph without context that then gets plugged in, and they have no overview of what comes before and after . It is difficult to break that down and break down the user experience between the functionality and the language. So it is something that I'm looking into and trying to find different ways to measure that, apart from potentially including a few questions about that in surveys sent out to customers. Michal: Yeah, it is really hard because I think, first of all, like you said, it's really hard to differentiate what really impacts the user patterns and the way that users behave on your website because it can be a result of a lot of different things, both cultural and design and localization, content... it could be a lot of different kind of things and a lot of different things combined and even the state of mind of people at that specific area and that specific day, it could really vary. So it is really hard. What I find is the best way is to just design tests for that purpose, because otherwise it's really hard to just be able to isolate that very, very tiny aspect and see what impact it has. And so if companies do want to be able to measure localization quality, they need two versions of localization. And no company has two versions of localization unless they're actively trying to create them to actively test the impact of localization quality, which is, you know, it's out of preference. It's not something that a lot of companies put at the front of their agenda. But I do think that if companies were to give it a try and even do just small tests every once in a while, every year. Just to see how much your quality can improve or how much impact it can have. They really do stand to gain a lot. And I think the story that you're telling here is, is really a testament to that. Because I think you took some sort of leap of faith, right? You came and you improved localization without actually knowing that it's going to make an impact. And it made a huge difference for the company. I think it's something that you have to just leap and do. You have to really believe that it works and try it because otherwise I'm not even sure if you can... because the opportunities for improvement that you have discovered during localization, I'm not sure if anyone could see them in advance, or from the outside. Aglaia: Yeah, absolutely. I think something that localization brings in any company and any process that it is involved is... Most of my colleagues and a lot of my friends who are in the industry, we always bring in organization process improvement. We're always looking at ways of improving the ways of working. We're always looking at ways that improve accuracy, attention to detail, improving timelines, reducing costs. I mean, no one wants to do three rounds of review because somebody forgets to send the updated version or the updates on the line, you know, everybody wants to be very efficient and we kind of bring these qualities everywhere we go. So whenever you change roles and you find yourself in a different environment, such as the one where I'm now, you kind of bring all this experience with you and you start asking the difficult questions. Who's going to review this? Who's going to sign off this? And you basically bring these efficiencies together in any process. This is something that always, always adds value. And it's kind of like the start of a journey that you never really know where it's going to go. Because we always look at the content and the copy in a more kind of like systemic way. If that makes sense. We're always looking at the content thinking, what's the best approach for this? Should this be translated, localized? Is this just maybe creative translation? Does this need to be transcreated? So we're always looking at the best possible process for the best possible outcome. Michal: You mentioned that when you made this significant improvement, the biggest thing you did was bring linguists into the team and kind of have them work with you and have them really get invested in your brand and your needs and company's needs. So why do you feel that this made such a difference compared to the way that you worked before? Aglaia: I think it has to do with the brand and the content in question in every case. It might be that if the subject was maybe a little bit more, I don't know, mainstream or easier to translate. I mean, hotel descriptions, it's something that everybody's familiar with. I think this is something that kind of is part of a bigger conversation. What is the quality expected? This kind of ties in with why some of the biggest translation companies in the world seem to be more focused on sales , but they seem to not focus so much on what it is they're delivering back to their clients and also not treating their translators in the best possible way. How can someone get away with this? And I've seen it in practice many times that sometimes the client expectations are not really high. It might be that we, as professionals, we always try to get 10 out of 10. Sometimes for a client, a 7 out of 10 is acceptable. And I've seen it in the past. We would do a very detailed process of translation, editing. Then we had an internal terminology team checking, making sure that everything is implemented, the client glossary, the client style guides, and then we would send them out for review to the local marketing offices and no one would get back to us. I think this is why sometimes translation agencies will deliver things that might not be a 10 out of 10. And sometimes that's okay, because also the expectations are a little bit lower. But the moment that I feel that if I'm involved in something, my expectations are always higher. Michal: I think it's all tied together, right? Because if it's so hard to define quality, and it's so hard to measure quality, then people learn not to expect quality because they say, okay, so it's just impossible. It's just impossible to achieve. So why should we focus on this? Why should we invest our resources or time or effort onto this when it's just not achievable? And I think the more that we put the focus back on quality and how to define it and how to measure it, then maybe it'll become more feasible for companies too. And then maybe they'll focus a little bit more on just giving more attention, if they're not part of the localization team. Like you mentioned, the marketing teams, the product teams. I think once they understand that it's feasible and it's doable, then it becomes more of a priority, because it becomes... Something that's actually possible to do a real possibility. Aglaia: Yes, I think it's also very difficult to be objective when it comes to translations. And I think this is one of the main conversations that we will have all the time, no matter which side of the fence you are, getting feedback on translation saying, "Oh, I'm not very happy with this translation. It sounds like Google translate." This is my favorite kind of feedback for translations. So it's very, very subjective to define quality. Especially when it's not discussed between localization professionals where we can sort of break things down and be more specific. Sometimes it's very difficult to have these discussions with people who are not part of my industry. And I think this is one of the main problems. It just makes things even more complicated when trying to explain why quality is important, why localization is an investment and not just a cost, and why sometimes the end client is not getting what they want because they have not been able to express it in advance. Michal: Sometimes there's also a lot of emotion. You mentioned feedback and how hard is it to get objective feedback. Cause you can't really be objective in language and it's the same in writing. It's the same when you localize. I think whenever you deal with content, there's always kind of subjective feedback and it's subjective not just because it's your own opinion, but also because sometimes you're in the market, sometimes you're not in the market when you're localizing, sometimes you know the brand well, sometimes you're an external vendor and you don't really know the brand and then that feedback doesn't make sense to you because you're not so invested into how the content is written for them. I find that a lot of times when you take the ego out of the conversation and you say, it's okay that there's feedback. Cause it doesn't mean that any of us is wrong. It just means that maybe something is more right for the brand or something is more right for the market. And when you take that emotion out of it and it becomes much more of an efficient conversation because we're no longer talking about what you did wrong, what I'm doing wrong. Or I'm no longer attacking you for something that you did. We're having a conversation about what's best for the brand or what's best for the audience. And we have a shared purpose, I guess, or a shared goal. And then it becomes much more efficient and much more beneficial sometimes. Aglaia: I really agree with this. This is why we need these contributions and the feedback from the local markets to get to the right point. And I brought this comparison up a couple of days ago, discussing some internal feedback. When we put together an English copy for something that will be highly visible, maybe go out to clients, partners, it usually is seen by 10 different people within the company. It will be potentially the copywriter, some of the stakeholders. If it has to do with the product itself and the product managers will have a look to ensure that all the technical details are correct. And then it will probably go through a few rounds of revisions. And we think of this process as a process that makes sense, that it is productive. So why do we feel that once the translator works on this exact same copy, it should be ready, adjusted for the market, ticking all the boxes. But I feel that sometimes the local teams think, oh, this is not what I expected, but they don't understand that they should be part of the process. And this is a very long process. Even if you work exactly with the same translator and provide this feedback, there will be improvement, this is a longer process to get someone to adjust their style to your expectations. It's very easy to say, okay, this is how we'll be translating these terms, and this is how we'll address the audience, you know, singular or plural. These are usually being done. But when it comes to finessing the style, to reach a point where the local team will have to make no changes? That takes quite a bit of time. Michal: Yeah, because right now when people started working with like generative AI for writing, for creating content, then it becomes really expected that you get this kind of rough draft. Then you have to give feedback on it, you have to adapt it, and at the end you get a result that you like. But it takes a while. And it's funny because it is the process that's supposed to be when you write with a human as well, because nobody can really understand everything you're expecting in one go. It's really hard to do. And so you have to have that kind of iterative process of doing something, getting feedback, and doing it again, and getting feedback, and sometimes even bringing it to market and getting more feedback. To get it as optimized as possible, as effective as possible. And it's so reasonable for us when we work with machines, we work with Gen AI. It's not really reasonable for us when we're working with humans, despite the fact that we have more bias and more our own opinions and we bring more of our own emotions to the table. So it should be even more reasonable, but I think maybe we're not used to it still. Aglaia: Yeah, I agree. And it would be great if that was the wider sentiment behind this, but I don't think it is. And this is something that was sort of expecting, that the moment you start this process of putting your translations through local review and requesting feedback, you open up a very big can of worms. You have to be ready for it. And this is also one of my questions when I'm recruiting for translators is how do they handle feedback? Whether that feedback is reasonable or unreasonable. How do you handle this? How can you defend your work? What is it that you fall back onto when people will say, "Oh, but I don't like this. This should be not X, but Y". As you said, it's nothing personal and you need to take on feedback. You need to accept it. You don't have to take it personal and you have to be open to it because this process is not really perfect. It's just, there's always room for improvement, as you said. So it's just difficult to manage everyone's expectations. Michal: Yeah, but I also, I think, because I asked you before, why do you think that bringing people into the team made them better linguists? And I think it's part of it. I think when people are feeling like they're part of the team, it could be the same linguist. I think when they're working within the team versus when they're working as kind of an external freelancer that's not part of the team and not part of the process. They will provide different results. You'll get better work when the person is actually invested into your company. When they actually feel like you expect more of them, then they will provide better work. Even if it's the same person. So I think this feedback and this kind of iterative process, it's also part of it. Because when you do the iterative feedback with a person, then they feel like they're part of the team. They don't feel like... a toaster or something that you put the bread in and you take it away. They feel like they're part of it. And I think it makes them do better work as well. Yeah, I compared people to a toaster. I'm sorry about that. Aglaia: For me, what I consider a success when I join a new company is when I try to come in and bring in a new process and maybe introduce the translators. At some point we reach this kind of benchmark moment when the local team will say, you know what, we don't even need to look at this. We trust that X translator has done a great job. They know what we are talking about. They know how we would like to express ourselves. So we don't need to have this review step. We just go forward and we're going to have a look at the final artwork and then we're ready to go. This is what makes me really happy. We're about one year into having this translation team looking after the bulk of translation. So it's great to see how the translators are also invested on the brand, how they will themselves flag things that we should be looking into or using the product, noticing things. They are also invested because they feel that the output of what we're putting out there is part of the work. They want to feel good about what it is that is available within the market. And they feel that it also represents them. So I'm very, very happy about that because I feel that the responsibility is sort of shared, but also the great results can also be shared across all of us. Michal: I'm curious. Can you share what the previous company was or is it like a mystery company? Aglaia: It's not a mystery company. It's a small B2B company based in London called Travco. It's been about almost 10 years since I've worked there. So... Michal: Oh wow. Aglaia: Yeah. A lot of things have changed in the company. And yeah, sometimes I will pass by and still see the office there. Michal: Where do you work today? What company do you work for today? Aglaia: At the moment I'm working for Dice, it's a music ticketing app based in London, and it is available in a few markets... the UK, the US, France, Italy, Spain, Portugal, Germany, and now expanding to India, and a few other markets. And I'm responsible for the localization of the app and all the partner tools and communications. Michal: So I'm curious... What difference you see from the work that you did 10 years ago, for the travel company, to the work that you're doing today? What kind of the major differences in the way that you work? Aglaia: I think the main difference is that translation technology has really changed and improved since then. And this is one of the reasons why I find what you do very exciting and very interesting because I think all translators who are working on the localization of apps are also UX writers for their language. And this is something that I would like to introduce as a process in my company. So... be able to look at any new or updated features, and work on them for each language alongside the UX writing. Being able to look at the user journey for that particular feature Michal: Or on the localization station email list for updates. Aglaia: and be able to design the content in the best way for the local language. And also being able to give feedback on the design while this is open to discussion and not after everything is finalized and checked and wrapped up. Michal: We touched on so many important topics. And there was so much that you said, I think would really resonate with people. Thank you so much for taking the time to share everything. Cause really, I think there are a lot of lessons to be learned here. Aglaia: Thank you for this opportunity. I didn't think that I would have a lot to say that might be useful or important, but it was a great, great conversation. Really good questions. Michal: Yeah. This was really fascinating and there was a lot of things that people can kind of benefit from hearing. I was really surprised to hear that was 10 years ago, because that felt like a really modern approach. There are big companies that are not doing half of the things that you did 10 years ago. So that's really impressive. And then seeing how you're starting to iterate on UX content and UX localization these days in your company, I'm sure it's going to lead to really great content at the end. And I really support that too. I think that the more localizers are treated like writers in the climate that we have today and the way that we're doing content today, the better content is going to be and the easier it's going to be to create that as well. Aglaia: Yeah, absolutely. I think the conversation that you have started is really, really important, is not for linguists to kind of like put themselves into boxes, because I think this is something that we struggle a lot in the industry. We're very worried about stepping out of our comfort zone and picking up new things and picking up new skills. And I think this is a great way. You see this happening, you know, in other industries and in other areas around what we do. People move from one kind of like aspect of this world to another. And it should be the same of us. The fact that we might be working in a different language, which is not English, should not be restrictive. So that makes me feel very excited and optimistic about the future opportunities for localizers and translators. Michal: Yeah, absolutely. That's been amazing. So thank you so much for being here. Thank you for sharing your experience and sharing your tips and your ideas. It has been really, really interesting. Also, thank you, my listeners, for caring and staying passionate about localization. I was really inspired by Aglaia's take on localization quality and her actionable outlook. I hope you'll take something from this too and try to make localization better at your company, step by step. If you're as passionate about localized user experiences as I am, make sure that you join our community. There's a link on the Localization Station website and it's where we have really interesting discussions about localization quality and technology. There are job postings, so if you're interested , please join the community. We would love to have you there. And if you want to hear about new episodes of the Localization Process Pod, be sure to subscribe on Spotify, on YouTube, or on the localization station email list for updates. I was Michal Kessel Shitrit and this was the localization process pod. I really hope to see you again for another localization process review soon. But until then, I hope you have a great day.

As we approach 2024, the landscape of localization is going through a fascinating transformation. The industry is buzzing with anticipation and a bit of uncertainty, as technological advancements promise to change everything we know about our work. Everyone, from seasoned professionals to newcomers, is trying to find their place. For UX localization, we believe this change brings exciting opportunities. Here are four predictions on the changes we’re looking at in the upcoming year. 1. Localization is going to move further in-house In 2024, we're going to see a significant shift in how product companies approach localization. The trend is clear: more and more companies are bringing their localization efforts in-house. By hiring in-house localization managers, companies are taking the reins of their app and software localization workflows. This approach allows for a seamless integration of localization into the product development cycle, so that users get a more cohesive and consistent experience. And when the content pile gets high enough, companies are also starting to recruit in-house translators. They’re building a dedicated team that deeply understands the company's voice and mission. But why this sudden urge to keep everything under one roof? The answer is control and quality. Having an in-house team means companies can closely monitor and guide the localization process, ensuring that every piece of content aligns perfectly with their brand voice and values. This level of control extends to collaboration as well. In-house teams can work hand-in-hand with other departments – be it marketing, product development, or customer support – creating a synergy that's hard to achieve with external partners. This collaboration isn't just about meetings and emails; it's about creating a shared vision and understanding that impacts every aspect of the product. Going in-house does take its toll on the company, as people do need to work harder and more to facilitate that collaboration. But thankfully, technology is continuously evolving as well (more on that in a bit). Companies will leverage those localization tools to ramp up productivity: Translation management systems, automated workflow management, AI-driven quality assurance, and platforms for remote collaboration. These tools are essential in compensating for the time and resources invested in building an in-house team. 2. Machine translation will finally reach UX Machine translation is already deeply embedded in localization workflows – there’s nothing new here. But up until now, MT wasn’t considered good enough for UX content. The technology wasn’t designed for short-form content, the outputs weren’t good enough, and the risk was simply too high. The accuracy of content in an experience is critical, since there’s limited additional context readers can use to find their way in case of errors or mistakes. In the upcoming year, companies will gradually give MT a chance, even in UX localization. They may need to experiment with different forms of AI-based translation, from neural machine translation (NMT) to large language models (LLMs), to some hybrid solutions. New models released in 2024 will offer improved output, better prompting capabilities and enhanced tuning features that’ll make AI-based UX localization a real possibility. What’s going to be a real game-changer, however, is the evolving capability of these models to incorporate visual context into their prompts. LLMs that can consider screenshots, layouts, and design elements of a user interface will provide more accurate outputs in AI-based workflows. This advancement is crucial in UX localization, where the placement of text, the flow of a user journey, and the overall layout can significantly impact the content. It's a leap from seeing translation as a purely linguistic task to understanding it as an integral part of design and user engagement. But don’t worry: this shift towards MT doesn't mean the end for human translators. 3. Humans will be in the loop, but their role will change Incorporating AI into UX localization workflows will mean companies can leverage the strengths of both humans and machines. The traditional model, where human translators are manually moving content from one language to another, is going to evolve into one that’s more efficient. More importantly than that, it’ll also help companies deliver better international experiences. In the upcoming year we’ll see machine translation being used for the initial, manual translation step, and human experts step in later, particularly during the linguistic quality assurance (LQA) stage. This shift is more than just a change in sequence; it's a strategic realignment of resources. By allowing MT to handle the initial translation, companies can process large volumes of content rapidly, meeting the demands of today's fast-paced digital world. However, this won’t diminish the role of human translators. They will become quality guardians and cultural consultants, adding value through their nuanced understanding of language and culture. The shift will focus their skills and expertise where they are most needed – in ensuring relevance and enhancing the experience for their target audience. The emphasis on in-context LQA is a game-changer in this new workflow. Traditionally, translators and reviewers worked with text in isolation, often detached from the actual user interface or product experience. But as we move into 2024, seeing the translated content in its intended context will slowly become the norm. This approach allows translators to understand how the text interacts with design elements, how it fits within the overall user experience, and how cultural nuances play out in the actual product environment. This in-context review is not just about catching errors; it's about fine-tuning the language to resonate with users, ensuring that every button, menu, and state feels natural and intuitive. Human translators, focusing on the LQA stage, can work more effectively, as they are dealing with content that has already been processed and structured by MT. This synergy between machine efficiency and human insight leads to a more streamlined, agile localization process. 4. Translation and design teams will have better relationships The final pivotal shift we foresee is in the dynamics between translators, localization facilitators, and design teams — moving towards a much tighter, more integrated collaboration. Gradually, teams will establish deep, ongoing communication channels that allow for better flow of ideas and feedback. Product teams are beginning to recognize the immense value that localizers bring to the table, not just as language experts but as key contributors to the overall user experience. This enhanced collaboration means localizers are allowed in earlier in the development process, offering insights that can shape the product from a localization perspective. With translators having a clearer understanding of the product's objectives, audience, and context, their translations can go beyond mere linguistic accuracy. They are able to create helpful, valuable content that resonate with users in different markets. This level of detail and customization can only be achieved through a robust exchange of information and a deep understanding of the product and its users. Companies are investing more in this area, recognizing that effective communication between translators and product teams is not an overhead but a critical investment. The focus shifts from merely translating content to creating an immersive and relatable user experience for each market. This evolving relationship signifies a new era of respect and recognition for the role linguists have in the product development lifecycle. On the linguist side, this requires a commitment to continuous learning and adaptation. Translators will be expected to stay up-to-date of industry trends, technological advancements, and evolving user preferences. In turn, product teams will also be expected to provide translators with the resources and insights needed to understand the product comprehensively. This mutual respect and investment in knowledge-sharing lead to a more informed, nuanced, and effective localization process. Heading into the new year Even with the tech powering forward and industry evolving at breakneck speed, there's still plenty of space for localizers. The key? Stay curious, keep evolving, and keep bringing value to the table. This will be the best way to secure your spot in localization in the upcoming year.

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

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!

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?

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.

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

Here's something I 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.

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

Localization at scale is significantly different than localization at a small company – for better or for worse. The challenges that come from maintaining over 17 languages and several different sections are mitigated by more localization colleagues, and access to better documentation and resources. In this episode, Adi Meller, Localization Operations Manager at Wix, will tell us all about how it's done. Audio Text video About Adi Meller Adi is an experienced Localization operation manager and translator on a mission to make the world of knowledge more accessible with localization. She's been working in the localization field for the past 6 years and gained knowledge and experience as an operations and project manager, vendor manager, and translator for a vast range of fields. Enjoyed the Localization Process Pod? In every episode, we'll be learning from one guest about the way they do localization for digital products. Subscribe here, on LinkedIn, or on the Localization Station website to get notified about the next ones. Transcript Michal: Hi everyone, and welcome to a new episode of the Localization Process Pod, the podcast where we break apart localization processes from companies all over the world to learn what goes well, what goes wrong, and how we can make it better. Today, we'll be learning about a little company that maybe you know, it's called Wix, and I have with me Adi Meller, who is the Localization Operations Manager at Wix. Adi, it's really great to have you here. I have to say, I'm personally really excited about this specific session, hearing how localization is done at Wix, both because this is a company that I've been watching from the first moment that they created their product and seeing them going global and seeing them becoming so big and advanced is really exciting for me. And I would love to hear how it's done and how, I guess, the cake gets made. So thank you for being here. Adi: And also, you have a special connection to Wix. Michal: And I also have a special connection. Yeah, full disclosure, my sister is a UX writer at Wix. But that's not why I'm excited about localization because she does UX writing in English and she's not a translator. No, but I also, I use Wix myself. I have Localization Station. The website is on Wix. And so it's actually a product that I've been using daily. Which is exciting. Also it's an Israeli company, which is always exciting for me. Okay. So, you work at Wix. What exactly is your title? What do you do at Wix? Adi: I'm a localization operations manager, which means I'm responsible for translating and localizing parts of the platform into 21 languages. Some parts get translated to more than 30. Luckily for me, it's just 21. I'm in charge of the CRM, the automations and the OS parts. My day to day job is receiving translation tasks about new features, new products, text changes, AB tests and just getting them translated into 21 languages and also QA-ing these translations to see the flow is clear, there are no bugs, no design issues. I don't know if it sounds easy. It's not easy. From one side I'm working with the product team, I'm working with PMs, I'm working with product managers, I'm working with the developers and I'm working with the UX writers. Thank you And on the other hand, I'm working with the translators and languages. So I'm basically in charge of getting this flowing into each direction. And because we're translating to 21 languages, bugs are bound to show up, you know? At least once in every flow. So yeah, that's up to us, the localization managers to handle and address. Michal: Oh, wow. So you said, "I know this sounds easy", but it sounds really hard. It doesn't sound easy at all. How many localization managers do you have? Adi: Well, it depends because in our team, the localization team, we're about... 12, 13, I think. And there's also the localization team for marketing, which is different from us. But my team is responsible for translating most of the platform. We have in-house writers, we have freelance writers. Everything is done in Smartling and Monday and Google Sheets. Basically everything is on the cloud. Michal: How did you get to this role in the first place? Were you a translator before? How did you get to localization? Adi: At the beginning I was a content writer and editor and manager. But I always like to translate because I take pride in my reasonable English. At some point I realized I'm using a lot of English and translating in my day-to-day job. So about four years ago, I decided after I quit a horrible job as a content editor. I decided to go into localization, I took a Google online course, and they had a chapter in localization and it was like Eureka, that's it! I was looking for a new direction and there it was. And it was so reasonable to me because I used to translate on my former jobs. And also I did a little research and I discovered that in Israel, it's not a very big niche. So for me, it was really great because I wanted to be a leader in this area. And my dream was always to teach. So I said like, yeah, let's do this. Let's learn a new profession. Let's work. And maybe one day I can teach and pass this knowledge on. Michal: So you got from content editing, from marketing basically, UX into localization. Adi: Yeah. After the course, I had a small business and I started to take translation jobs. A year after I did the course COVID struck and I was able to take a lot of freelance jobs. And I was the translator and project manager for a big streaming company, I don't know if I can say the name, but it rhymes with Felix, so you can guess. So I did this role for two years, I had a lot of fun, and I also did translation jobs for Nespresso and for PlayStation and for Airbnb and for Google, so I translated in a lot of different areas. And after two years I saw that Wix is looking for a localization manager and thought " this is the next step in my career". And here I am! Two years later. Michal: It's funny because I feel like a lot of translators, this is kind of how they got to UX. And it's also, it's the same for me. I did translation, just general translation, and then gradually you'd get more and more, I'm guessing, UX, UI, localization, tasks, just because there was more content in that area. And you'd end up saying, oh, this is something that I'm really interested in, right? And it feels like something I want to do more of. This is, for me, this is how I discovered UX writing, and then I started doing UX writing as well. Because I said, Oh, I have the experience from translation and I've been actually doing this for a few years. So I should also be writing. And then I started learning about UX writing and that's... everything I'm doing now. I feel it's a story that a lot of people have. They kind of accidentally land into this. Like you said, a Eureka moment. So it is interesting. I'd love to keep talking about this, but I do want to dive into the process just because feel that specifically for Wix, you have a lot of valuable information to share. And so, tell me how the process looks like on the day to day. You get a task for translation, who do you get it from? Adi: I usually get it from the developers or from the UX writer I work with. I get it by Jira tickets or I get a Monday board or I get it by Slack. It really Depends on like the relationship I have with the UX writer. But I'm super available in each channel. They always know to deliver the key list and also if they have a link for Figma, which is where I see the full flow and what I should recreate. Because eventually I don't just send everything to translation. I also have to understand the flow in order to recreate it in the localization QA. So it's really important. I also get a feature toggle, because a lot of new features are closed to users and only employees can see them. And it changes from UX Writer to UX Writer. some of them tag the keys in Smartling and they just send me tag name. And some of them just send me key list and everything's cool. But it's really important to always have context. That's why I really need Figma, and that's why I always try to recreate the flow before I send everything to translation. It helps me understand the flow, and if the writers, the translators, have any questions, I know how to answer. And also, I can spot localization red flags, before I even send a translation. Like, for instance there's a very long text with limited space. I can say in advance, listen, in long languages like Russian, German, French, this space is not going to be enough. It's going to be cut in the middle or maybe we need an ICU format. If there's a difference between the masculine and the feminine language. So I always try to make the text as dynamic as possible. So the translators have as much freedom in translating. Also if I see date and time formats, I talk to the developers, to enter a certain code that will make the date and time localization friendly. So people in Japan will see the date format they're used to read. And that's it, like, once everything is ready, I send the translation task. The ETA is between three days and a week, it depends how long the task is, and once everything is ready, I do a pre-QA myself. I check the flow in like, two or three languages to see everything was translated, there are no texts left in English. And once I see everything is done I can send the localization QA doc. It takes about... between three days and a week also. And once the QA is done, I can approve to expand the feature into languages. This is the ideal case. If it's like a small feature or a text change, it takes about two weeks, but new features or new flows, they're super complex. It can take up to a month. It can take even more than that. If like new text keeps getting added. So some tasks are time-limited but some of them are ongoing. Michal: So you get the task from the developer and then you check everything you have to check, then you send it to translators. So are those translators freelancers, are those in-house? A combination? Adi: Most of them are in-house. We have a lot of in-house translators sitting with us in Israel, and some of them are working abroad. And some of them are freelancers. It really depends on the language, like the scope of the language. A lot of times there are more than one translator to each language. There are language leads which are responsible for the glossary, termbases, so on. Yeah. So there are translators, freelance, in-house. Michal: And when you localize a feature, is it already live in English usually? Or is the launch in all languages at once? Adi: It really depends on the product. It really depends on the team. It really depends on like the KPIs they want to achieve. It's different between each team and each product. Sometimes I get a localized flow or feature or product which is already open to English and they say like, no pressure, take your time. We'll expand to languages once it's ready. And there are times when the deadline is urgent and they want to open everything all at once. We had a big launch last month of a new product at Wix. Michal: Wix studio. Adi: Woohoo! So the whole localization team worked together to get everything done because they wanted to open everything all at once. So it's really different from product to product, from team to team. But... it's never boring. Michal: Yeah, definitely never boring. So you mentioned context, which I feel... I agree is a critical issue. Adi: Yeah. Michal: How do you provide that context? Because you get a figma file. Do your translators also get a link to that figma? Or does Smartling sync with figma? How does it work? Adi: What I do, I just add, or the UX writer adds, screenshots to each string, to each key. Michal: I'm curious why? Because I know Smartling does have it in-context translation feature. I'm not sure how exactly it works, but they do have a feature that you can translate in-context. So you see the interface and you type and you see the translation populated into the interface. So why do you prefer using screenshots and not in-context? Does it take time to set up? Adi: I feel like the translators already have a lot on their heads. So I don't want to send them locating each text in the Figma. I think it's... My job to do that. And also, a lot of time I recreate the flow even before I send it to localization. I recreate the flow, I trigger a lot of texts, so I just take screenshots myself, and I already prepare, first hand, the QA doc. I trigger the whole flow, I prepare the QA doc, I learn the flow, take screenshots, and the translators can see exactly what they are going to translate, where is it located in the product itself, how much space do they have. And that way they know if they have to keep it short or they can translate it however they feel like it. Michal: Are features usually already developed once they go into localization? Adi: Yeah. Michal: So you already have like a live test environment with the feature in it? Adi: 95% of the times, yeah. The feature is already live but to employees only. And we need to use a feature toggle. It exists somewhere. Michal: Does it happen that you send something to localization, then you get comments that mean that you have to go back to development and fix things or change things? Adi: I usually try to find them myself beforehand. It doesn't happen a lot of time. Because the features get so many eyes testing them and looking for bugs and doing bug hunts and doing QA beforehand. And... content QA. Localization usually comes last. We're the last QA because we only get it after the content is done. And because the content is like almost the final stage, we already get everything when everything is almost ready. So it doesn't happen a lot. There are mostly like issues with texts that appear in English or for some reason, I don't know, I see old texts and I don't know why. It's usually UX issues and not product issues. Michal: Yeah. But you don't have UX issues that are kind of specific to those markets that you localize into? Like maybe a French linguist says, "Oh, for France, this is not going to work" for some reason... Adi: Yeah, sometimes there are comments on the content. Yeah, for sure. Each and every language has their own set of rules, their own grammar. We also expect our translators and writers to flag things that they think is not going to work. That's why I always request the developers create dynamic keys. Then the translators can play with the order and with the format. But yeah, it happens sometimes. For instance today the Portuguese language lead asked me if we can ask the developer to create a new key because the existing key refers only to masculine format, and she needs to translate it in a feminine format. Which is like totally legitimate because you want to give the best UX possible. Michal: If you did localization before development, do you find that it maybe would have made a difference? In terms of how you address queries or feedback from your linguists? Adi: It's hard to say. very good to be involved in an early stage, like in the kickoff meetings. And this is something we always request our product teams to do, invite us to kickoff meetings and to weekly meetings so we can be in the loop and know exactly what's going to happen. And this way we get to know the new products and the new flows. And we can raise flags and say, " Think about localization before you develop it and allow the space to be dynamic and don't limit it in characters or in space. Allow dynamic keys. Think about the date and time formats. I feel the more we work with the product teams, the more they take localization into consideration. And it's really nice to see developers and product managers ask me questions before they send the product into development. Like, " can you tell me how many characters can we put in", etc. So yeah, it happens. Michal: Yeah. Okay. Um... Sorry, I lost my train of thought... it's August. Adi: Yeah. Michal: So you said we, "We come to the kickoff meetings". Do you mean "we" as in localization managers or "we" as linguists as well? Adi: Localization managers, because each of us is assigned to a different company – in Wix it's called company, like a department – and different products. And most of us localize for more than one company. So it's really important for us to be in the loop and know what's the workload that we're facing in the next few months. 99% of the times we can contribute. A lot of people that don't work with content day to day, like developers, they don't think about localization. And it's my job to say, " listen, this product is going to be 21 other languages. And it's almost half of our users. So we need to think about localization. Michal: Big question. You said that you are in charge of localization for the CRM. And for... Adi: And for automations and for the OS, which is the dashboard, menu and some other parts in the platform. Michal: And you do that and then there are other localization managers and they're in charge of the other pieces. So do you make sure that you keep everything consistent in the different sections of the product? Adi: Ah, not always... but It has a lot to do with how our predecessors used to work like five years ago, in... Smartling projects and so on. Sometimes it's very hard to differentiate and recognize which localization manager is handling which part of the platform. It's very confusing because Wix is a super big, super complex product. As time passes, each and every one is more familiar with the product but yeah, sometimes they get confused. Sometimes I get confused. And... Luckily I have my team to back me up. Michal: I would assume that if you have in house linguists, which is a big plus, the linguists themselves can maintain consistency in a way. Do you have more than one linguist for every language pair? Adi: Yeah, sometimes like in bigger languages like Spanish or Portuguese, for instance, or German, yeah. Their scope is big because some products only get translated into these specific languages. So yeah, they use several writers, translators. But each language has a language lead. So they do their best to be consistent. And each language is responsible for the QAs throughout the product and to change and to align the text . They're on it. They're on top of things. Michal: I noticed that sometimes you say linguists, sometimes you call them writers. How much freedom do you give them in terms of what content they create in their own language and how it looks? To create different content that kind of feels fluent and natural? Adi: They don't really involve me in their content choices or their UX choices because they have enough experience and they have enough knowledge and we trust them enough to make creative and smart decisions. We also expect them to make creative decisions. As long as all the texts are aligned, the user understands, let's go. But each and every language has a language lead. So I believe the writers always consult them before they make a very big change. Sometimes they also ask me and I'm super happy when they get creative and sometimes it's a necessity, because... if the choice is between getting creative with the content or asking a developer to change the key, I'll always go for the creative. Michal: So if they have questions, do they have access directly to the UX writers? Can they message them directly and kind of talk things over? Adi: Yeah. But I try to make flow as clear as possible before I send everything to translation. That's why I use context. That's why if I feel like something is not clear enough, I will always add instructions and explanations and if it's something super new and not clear, I will even do a kickoff meeting with the writers and explain the flow before the translation task, so they will get familiar with the flow. Before they start to translate . But on a day to day basis. Yeah, they can tag the UX writers and ask them questions like, can I translate it this way? Like if this translation will get the message of the original text. So yeah, it's nice. Michal: It's good that they have direct access too, because I feel a lot of the problems in localization come from not having that direct connection. And also, I really like that you have in-house translators because this emotional investment that you get from actually working at a company and being part of the company's success, it definitely leads to better content, better decisions. Just being more invested in the content that you create. And so I think it's probably a big part of why it's a success. Adi: Also, Wix is a big and complex platform. So I think it's good that writers are in-house. First of all, it's a very long onboarding. It takes a lot of time and a lot of effort. So we want to invest in the writers so they will create the best UX possible. Michal: Do you give them training on the company's brand, guidelines, and voice and tone and all of those aspects? Adi: Yes. Michal: Yeah. Adi: Yeah. Some of the writers are in charge of it. Michal: Amazing. How do you know if it's a good user experience in those languages? Do you test in all languages? Adi: Only after the product is live and running we can learn and analyze. Of course we really want to learn if the localization is successful by sitting with the data analyst and learning how many users are using the product in each language. What is the success rate? What's the failure rate? That's something I think that each and every localization manager has to know. Michal: I understand time is an issue, it's always an issue. But if you had infinite time, what kind of KPIs would you have looked at? Adi: I think clear message, clear instructions. And how efficient the UX is. If we see that the users continue from screen to screen, without stopping and without rereading and without asking for instructions, then it's a success. Michal: I'm wondering if it's possible to even create those tests to run automatically. It's going to take time at the beginning, but then you have that data always available. Adi: I had it a few months ago, with one of the teams I work with. I wanted to know if... a very big product I worked on, how is it doing? I wanted to hear some insights, to see what our users in Japan and in Germany think about it. And they didn't really have a lot of answers to give me. I think English is, will always be, the most important. Michal: Yeah, it's something that a lot of companies do, is they don't really test a localized product, they only test the source product. Which, again, I getthat time is an issue, and money is an issue, and obviously, you start by testing the source product, then you... Maybe if you have time and you have the capacity, you expand it to the localized product. But... I'm always curious to know how companies manage to justify this really significant investment in localization without actually having the data to justify the investment. You know what I mean? So it's kind of an interesting... Challenge, I guess. I don't know, or maybe companies do justify that, and they do run the data, but they don't want to share it, which is also okay. Okay, let's talk about the QA part 'cause we haven't really discussed that. Do you create kind of a script for people to go through the localized product? Adi: Yeah, we have a ready made template that we can use, and every one of us has a different method for creating the QA doc. I realized that you have to be as clear as possible. You have to write the QA doc as if you're explaining... not to ten year old, because a ten year old will probably know better than I do how to operate everything in Wix, but like... imagine you're explaining everything to your grandmother . You have to use clear words, choose as many screenshots as you possibly can... because you only have words and pictures and videos to explain yourself. And the QAs are very complex and they're very long. So you have to be as clear as possible. You have to write the instructions as if you're writing to someone who never used your product. That's the only way to make it as clear as possible. Some of the companies use Storybook, which is super helpful. Not all of the companies use it, unfortunately. Storybook Simulates real product. And you can change the language and you can test several scenarios and it's super easy to QA, but not all companies use it. So we have to make very long docs and guide the language leads through them. But that's the best way to discover bugs and issues. Michal: You say companies, so do you mean kind of like subsections within the product? Adi: Automations is is a company, Stores is a company. Michal: So different subsections . Adi: Yeah. Michal: Okay. And so you create the QA scenario, the script, and you send it to linguists and they find bugs. What do they do with the bugs? Adi: They flag them. They always write in the most clear way possible because I don't speak Japanese or Italian or whatnot. They always have to give me context, tell me exactly what the issue is. And also to explain as if they're talking to a grandma, which in this case I'm the grandma. And it's all about communication and explaining the needs. I also have to translate these flags to the developers. So if I don't understand what the issue is, I will never be able to explain it to a developer who has no idea about localization. Michal: How do they send it to you? What do they use? Adi: The QA doc. We have a special section where they can flag issues. And I discovered once you make the QA doc clear you explain everything, you have less issues. Building a QA doc can take from one hour to two weeks. It really depends on the product and how complex it is. But if you simplify the flow and if you make it as clear as possible, you will have less issues because you will also discover the issues beforehand and you will report them before you send the QA. So they will be fixed before you even sent the QA. Michal: And then they fix it. You have like a back and forth. And then it goes to production. Adi: Sometimes it takes a day, sometimes it can take a month. But they do their best. Once it's fixed, I test it, or if it's something I can't test because I don't speak the language, I will send it to the language lead, and if it's fixed, yay, we can implement the change, if it's not fixed. It goes back to the developer... Michal: Okay. My final question. If you had to give one tip to companies who are just starting to localize or trying to optimize their processes. What would that tip be? Adi: Ooh, wow. Do your research, learn your audience globally. Also Invest in human resource. There's a tendency to think about translators, yeah, yeah, you see content and you translate, la la la, la la la. And people don't understand how localization is very complex and demands a lot of resources. You have to know two languages, you have to know slang, you have to know the culture. You have to keep learning. You have to do your research and you have to think about the user all the time, but you also have to think about the company and the develop... Especially in big techie companies. It takes a lot of knowledge. So I think it's really important to invest in translators. To teach them. Give them a lot of resources. Invest in the onboarding. Yeah, because eventually localization is a gate to new markets , you know? To new users. I think localizing is like giving access to people who didn't have access before. There are a lot of places in the world where people don't use English content and they want to see everything translated in their own language. And if you give up on them, or if you don't translate it good enough, you lose them. Michal: Yeah, localization is accessibility in many ways, I completely agree. If you're a small business owner and you're able to create your website and go online and have more customers and even reach new markets, thanks to that product being localized, it has a huge impact on your quality of life. And, you know, financial security, and really critical things. Adi: Exactly. Like we saw it on COVID, people moved everything online and our localization department grew so much bigger during COVID, I was recruited during COVID. Michal: I love the we ended on this note on investing in your translators because I feel a lot of times companies get caught up on the technicalities of it. Like, how do you send your files? And, you know, I don't know, how do you calculate the budget, but they don't really focus on the people who are actually doing the work, the people who are actually creating the content, creating those experiences and investing in those people is definitely the biggest thing you can do for your content, for your localized product that's amazing. So thank you so much for giving us a glimpse into how Wix does their own UX localization. So thank you so much. Adi: For sure. Michal: For those who stuck around, give yourself a pat on the back for learning about one more way to do localization. I think localization at scale is significantly different than localization at a small company. For better or for worse, I guess. There are a lot of challenges that come from having 17 languages to localize into, and several different sections in your product. But you also enjoy the support of more localization colleagues, and access to better documentation and resources. So I'm not sure which one is better or easier, but I would actually love to know what you think. So come join the conversation on our UX Localization Slack community. There's a link to join on the Localization Station website and it's open to everybody. I really can't wait to see you there. If you want to get updates on new episodes from the Localization Process Pod, make sure that you subscribe on Spotify or YouTube, or the Localization Station email newsletter, and I promise to only send you the good kind of emails. Until next time, have a great day!

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