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!