35 items found for ""
- Pushing for change in big orgs with Gilad Almosnino
How much change can you really create in big organizations? What can we do to help integrate localization from design to development? How much of an impact can localization teams have? And what does it all have to do with standardization? Listen to the full interview with Gilad Almosnino to find out. Audio Text video Key takeaways Mentoring and consistent engagement with feature teams can significantly reduce bugs and improve the quality of localized products. Implementing systems like champion programs helps in integrating internationalization from design to development. Larger companies often set trends that smaller companies follow, making standards adoption critical. Standards like those from the Standards Institute of Israel can drive consistency and better UX in bidirectional language support. Modern advancements in technology and AI can now make gender-specific localizations more feasible and cost-effective. Overall, continuous improvement and adaptation to new technologies will be crucial for the future of localization. About Gilad Almosnino Gilad is a creative innovator in Localization and Internationalization space with a proven track record of driving local market requirements across product design at Microsoft, Diligent, and Tinder. He excels in providing user-centric international product leadership, leading multidisciplinary design and development programs, and producing targeted market research used for strategic, industry-changing decisions. As the head of the Standards Institute of Israel Hebrew Support Committee, he is leading first-of-a-kind industry standards for UI mirroring and developing more inclusive gender-related Localization standards that aim to improve user scenarios across the Middle East region. Gilad is currently developing independent AI-related Internationalization market research and GPT-powered solutions that will challenge AI technology to become more practical for products seeking to build locally relevant experiences for users across the world. Enjoyed the Localization Process Pod? In every episode, we'll be learning from one guest about the way they do localization for digital products. Subscribe here, on LinkedIn, or on the Localization Station website to get notified about the next ones. Transcript Michal: Hi everyone. Welcome to the localization process pod. This is a podcast where we focus on different localization processes and different companies. We talk to different localization program managers and product managers and project managers to kind of learn what everybody are doing and what is working and what is not. So we can all learn from each other and kind of find the best processes that work for our specific company and our specific team. Today I have with me for the first time in an actual live recording, Gilad Almosnino. Hi, how's it going? Gilad has worked for 19 years at Microsoft in the international space in different kind of various positions, as well as a product manager consultant at Diligent and Tinder. And a chairperson for the Standards Institute of Israel for standards for bidirectional languages. I hope I covered all of it. Gilad: Yep, you got it all. Michal: But it's quite a bit. Gilad: Yeah. Michal: So, thank you so much for being here. And, from what I remember, most of, a lot of the work that you've been doing in the past years has been around kind of internationalization. Gilad: Yes. Michal:So, do you want to tell us a little bit about that? Gilad: Wow, yeah. I was fortunate to actually get into the international space by accident. Michal: How did that happen? Gilad: So I was a student at college at Bellevue College, learning communications and multimedia and the team at Microsoft needed software testers for the international version of Windows. And so they needed native speakers. And I was fortunate enough to get in on a really fun job as an international tester. For, the localized Hebrew version of Windows. It was kind of a funny $15 an hour job. And I did enough of an impression that they, after a year, took me as a full time employee. And that's where I started my formal journey at Microsoft as a full time employee on the Windows international team, which was quite fun and taught me a lot about how the software actually worked. I later on became a Program Manager in the same team. So I transitioned into that role after we did some reorganizations of things. And later on, I actually hopped on and became product planner, which basically helps the product managers plan ahead and think about some of the features that they want to build into the operating system. So it's quite a fun role as well. So that's the Microsoft part. Somewhere along that timeline, I moved back to Israel and also left Microsoft. Which then I became a consultant for both Diligent and Tinder for the international space as well. Mostly focusing on bidirectional languages, Arabic, Hebrew, anything from right to left. Kind of the same thing I did at Microsoft. And then I wrapped that up I think a couple of years ago. Today I volunteer as the chairperson for the Standard Institute of Israel, the Hebrew Support Committee. So we basically are building standards for a few things. One of them is a brand new keyboard that's supposed to come out in a few weeks, hopefully, when Microsoft releases their next version of Windows. It's a new keyboard layout. It's not going to be the default keyboard layout, so nobody has to worry that we're changing keys around, but it's a keyboard that's more compatible to the English layout. So it makes typing a little bit more efficient. There's a great guy named Yuval Rabinovich that worked on that. And we're also working on a very exciting Hebrew UI layout standard for bidirectional languages. So, how to design a right-to-left UI in the most natural way. So, quite a few things, yeah. Michal: So, as a chairperson in the Israeli Institute of Standards. Gilad: Yeah. Michal: So essentially, you're the person looking out for us as Hebrew speakers or bidirectional speakers, Arabic speakers in Israel, trying to kind of find better ways for us to access digital services. Gilad: Right. We're trying to basically standardize the way software providers lay out the UI and support these languages more naturally. And we also have on the committee one of the members is actually doing a PhD to see how, from a cognitive perspective, how that impacts the user. So it's quite interesting. It's the first of a kind, I think standard that's actually backed up by usability studies. I don't think there's another one in the world that does that. Michal: Okay. That's amazing. And do you find that companies. Are kind of happy to collaborate with you and make those changes, make those adjustments where... Gilad: We haven't reached that point yet. I think once we have the standard fully baked and approved and we could reach out to some of the companies. We do have members from those from the big tech companies working with us. So we do get input on the standard. It's, it's kind of an interesting game, you know for bidirectional languages. I think no company is fully invested in making those research and development investments. So basically, even during my time at Microsoft, it was very hard to convince teams to And management to invest in bidirectional languages because they don't see the ROI. Michal: Yeah. Gilad: And it's, it's a huge overhead. And from my end, I always wanted to be super professional and try to get usability studies to justify some of the design decisions that I made along the line. And so what I do see for companies as an opportunity is to have clear guidelines or a standard which they don't have today. So basically today what you see across the industry, especially around bidirectional languages and UI layout is that some the smaller companies will many times look at what the bigger companies are doing and then base their design decisions on that. Their assumption is that somebody in that company is actually... orchestrating the entire UI design for those particular languages. Michal: That's not a correct assumption. Gilad: And that's, and that's an incorrect assumption because no company, not that I know of, not many have somebody, for example, that looks at the entire end to end story for those languages. And so you may see inconsistency, and you may pick up the wrong element and lay it out incorrectly because you assume that Facebook or Microsoft or Google knew what they were doing. When the reality is the y probably Googled it. Michal: Yeah, okay. They asked Gemini or ChatGPT. Yeah, there you go. How do I a right-to-left layout. Gilad: Yeah, something like that. So I think we're trying to at least eliminate the idea of assuming that those companies know what they're doing. It also is going to help those companies to kind of figure out, hey, this is what the requirements are for the Israeli market. The idea is to, to create a Israeli standard, but I also am a liaison member at the Unicode consortium, which is the intersection where all the standards kind of get baked into Microsoft, Facebook, Apple, Google, they all sit there and mostly deal with text handling. And the idea is to maybe use the Unicode standard to kind of make sure that we're reaching out to the big tech companies and also regionally. We're not looking to just make a standard for Israel. We're looking to reach out to other players in the region that require the same requirements and kind of work with them to ensure that everything is kind of integrated together. Michal: That actually is really interesting. And it brings me to my next question. How much collaboration? Because. For Israel, bidirectional language is really critical, but also we're a very small market. Gilad: Right. Michal: And Hebrew speakers are a very small subsection of like global users of digital companies. But Arabic speakers is a huge market. Gilad: Yeah. Michal: And they have a very big need for bidirectional language. And I think in many ways, Hebrew speakers kind of get the benefit of that big market. We... if bidirectional language is available, if bidirectional layouts are available, so... we kind of benefit off of that, but no one is doing it for us. Gilad: Right. Michal: So how much collaboration can you really manage? Gilad: So currently what we're working on is a local standard. We are hoping to make it good enough so that the adjustments that are needed when we reach out to the regional players is gonna be minimal. The differences between Arabic and Hebrew is very minimal in terms of text handling and certain positioning of certain characters. Like the percent symbol or the question mark. You know, there's minor differences or digit handling. And so for us, we know that at least the big load is the UI handling, the directionality of the UI. Most of that is gonna have consensus. And the rest of it is going to have to be market specific adjustments. The biggest challenge in front of anybody that we have to present this to is that they tend to group everything together. And so, to a certain degree, that's right. But to, to other degrees, it's not. So, they basically, what I've seen along the lines is, like, the Israeli market leverages the Arabic user base around the region to make sure that the investments are made. And that's very correct. That's what I did at Microsoft for years. Yeah. You know, you're not going to be representing a smaller market and forgetting about the, the larger user set. More so, the Arabic market is less inclined to use English. Michal: Okay. Gilad: So it's a more pure Arabic market. We see that happening quite a bit which is great. Michal: Yeah. So bigger ROI as well. Gilad: Right, right. So when you represent the region, you have much more leverage to kind of ask for changes or improvements or investments. So that's quite nice. So the idea is to, when you approach some of these larger bodies and corporations, they tend to group things together and when you say, hey, you know, Hebrew needs the question mark in a certain way and Arabic needs the question mark in a different way, they tend to tell you, why don't you agree on it? Why don't you, why don't you go and figure out what... Michal: Sit together and agree, why not? Gilad: Figure out what direction you want the question mark. It's like their, their failure to see that different markets have different requirements, right? And I'm sure other markets have, like, basically some European markets may speak ... there's differences between them. Nobody is asking the two to sit down and kind of figure out what the right solution is, because they just kind of respect each market for what it is. And so when it comes to the smaller pieces where we have to do market specific adjustments, the idea is to actually present that in a way that says, you know, 95 percent of the things are the same. And then there's 5 percent differences between markets. And that's just a market specific adjustment. Michal: Yeah. Okay. Gilad: And that's something to bake into the engineering. Which is what we're gonna be asking for. Michal: Do you find that it gets easier with how technology is advancing and development technology is advancing? Do you find that maybe there are kits or scripts that make it easier for companies to utilize right to left. Gilad: So I've actually, you know, in recent months, I've been thinking about how things turned out at Microsoft and was it sustainable? Basically the weakest link in this whole equation is the person. Michal: The user or the developer? Gilad: No, no, the program manager that has to make design decisions or planning or whatever for internationalization. There's two reasons for that. The internationalization foundations that were put at Microsoft were put around Windows 2000, and they were very good. They were very robust. People accepted them for what they are with all their limitations, which for many years made sense and for many program managers it's easy to be in the comfort zone. So they're not looking at the foundations and saying... we need certain adjustments. I've never had that tendency, which made me a bit of a nuisance to certain people because, you know, you can look at certain limitations and say, you know, we need changes. So that we can progress forward, so we can enable more localization scenarios. So when the person leaves, the knowledge leaves. And so the idea is these days when it comes to engineering systems is to be smart enough to bake the requirements and the robustness in the engineering systems. So that when you build software, you're not going to have all these bugs. Michal: Yeah, kind of like a design system as well. Gilad: Yeah, a couple weeks ago, we sat with a company that's trying to bake localization into the design space, which is quite exciting. That's what we did at Microsoft after a few years when we figured out that that was the better way to go. The idea is to strive to get upstream into the design phase, but also strive to have the engineering systems kind of have the requirements baked in to a certain degree so that developers, for example, that want to build a media control, just get a media control that's mirrored correctly, you know, Yeah. Michal: They don't have to think about it. Gilad: They don't have to think about it and they can't screw it up. Michal: Yeah. Gilad: We're noticing with the initial usability studies that when you don't implement UI mirroring correctly or consistently, we're seeing impact to users' ability to be productive. Michal: Yeah, I have to say, I do find that there is kind of a hunger in the industry from the people who are actually creating the interfaces. So maybe not companies like top level directors, but designers, writers, localization experts, developers for guidelines that are very clear and that they can just take and use as is, right? I think a lot of people, they work in this vacuum and they do what they can, but nobody tells them exactly how it needs to be done. Gilad: Right. Companies have to put themselves in a position where they grow subject matter experts. I think in localization teams in the international space, you see... just my, you know, unofficial view of things across the many years. What I saw is that people tend to stay in that space longer. It's, it's a full career. Michal: It's a comfort zone as well. Gilad: It's not a comfort zone as much. Well, for some people it is. Sure. There's some people that, for others, it's just exciting. You know, I'm able to bring my skill set to a new feature, a new release, a new whatever. And they grow. Like.... I didn't come in into Microsoft as a subject matter expert. I came as a 19 year old college student that needed a part time job. It took me about 10 years to become a subject matter expert. It's not something that you, you, you develop over a year. Michal: And people don't stay for 10 years at a company these days. Gilad: It depends, right? Like in the international space of Microsoft, you saw people that are 20 and 25 years. Michal: Yeah. Gilad: And in certain years, it had, you know, accelerated growth and different technologies and, and the localization team was actually contributing to the core product product. And then working with international standard bodies to make sure that we're with better interoperability. What we see today is like, You know, with iOS and Android and PCs and Macs all working together and... they do it rather seamlessly on the international aspect of it. Nobody should take that for granted. That's a lot of work. That's a lot of people that I think have less visibility have done over the years. By the way. They're the coolest people have conversations with. Michal: Well, I think that's a lot. That's usually the case, though, right? Gilad: I had one experience at Microsoft with with person that developed the Unicode algorithm. They took that and they moved it to Unicode, so that becomes a standard. So one of the things that does is select text. Everybody knows that when you try and select bidirectional text, it's a bit of a problem. Michal: Yeah. Gilad: And I think during my first few months at Microsoft, I approached that person and said, this isn't working correctly. And again, older Microsoft people were less politically correct. And so he did not appreciate, he did not appreciate the way I initiated the conversation, "this isn't working correctly" because he worked on it very hard. I got yelled at again. It brought me to a point where I was able to think about why I approached that person in a certain way and what impact that had on the international space. Does this area need change today? It does. That's probably the next standard we're going to be working on. In fact, when Microsoft just heard that I was going to be working on a standard like that from the Israeli Standard Institute side point, they immediately contacted me because they knew that would cause them to have to make... Michal: Did they contact you in fear? Gilad: No! Michal: No, no, they were happy. Gilad: Sure, yeah. Michal: They were excited. Gilad: No. I think what they wanted to put together is actually Microsoft and Google and Apple together. So we're able to put a user experience that is good for everybody. That all three of them would implement because if you look at today's platforms and software on top of that, you have Microsoft running on top of Google and Google running on top of Apple and all kinds of stuff. The international space is one of those places where things are not competitive anymore, like these teams have to strive to work together. Michal: Yeah, well, I mean, because at the end your goal is to have everything the same, you know, as, correct, I guess, as possible. Gilad: The issue is that everybody's maintaining everything now. So you have to demand that they make a change because as long as Microsoft and Google and Apple are concerned... those are three big platform companies from the operating system perspective. They'd leave tech selection as is. Right? But that being said, Microsoft changes its design systems all the time. So every five, six years, they tend to kind of keep going. And so you have to rebuild this. Michal: Yeah. Gilad: Things don't, don't kind of come together automatically. And so, it's quite interesting. I'll give you a very good example of how, uh, we can impact localization as internationalization PMs. So today I think there's like 15 or 16 different languages that require masculine and feminine form. And so the solution that the localization industry provided is to go gender neutral. Make gender neutral localization, which makes a lot of sense. It's very inclusive and and strives to get to the broader set of users in a direct way. But nobody asks why did we get to the point where we only have one version of the language, right? Like if I want to translate a certain application to masculine form and having the same application in feminine form. I'm not able to do that today. Michal: Yeah, so explain a little bit about that, because I remember you told me about this a few months ago, and I did not understand. Gilad: Okay, great. Michal: So, how do you mean we can't? Gilad: So, we can go way back. There's something called the resource loading technology. It's something that Microsoft came up with in Windows 2000. First of all, it separates the strings out of the code. And then also, it basically says, hey, for every language, here's where all the resources fall, right? And then you can basically swap around. So if you want to use French one day, you can use French, then you can swap it to Hebrew, basically changing the UI language. That's something that in the past you couldn't do. Because the resources were baked into the code and it was very hard to localize and they had to compile it and send it on a CD or whatever. Michal: Yes, and now it's very common to keep the language kind of separate from the code. Gilad: Right, and all of that is basically based on what they called at the time MUI technology, multilingual UI . That's something that Microsoft came up with. A few years went down the line and Microsoft passed that on to Unicode and basically said, whether it's Android or Windows or anything, we need to have this language system. It was a great invention, it pushed things forward. One of the mistakes they did is they didn't have variations per language. Like for Israel, you have Hebrew Israel, that's it. You also have Arabic, Saudi Arabia, you get the point. But if you have one version of Hebrew, you're not going to be able to adjust it per user setting. Michal: Yeah. Gilad: And so what we do have today is a gender neutral translation, which is a compromise. We should strive to give the users what they want. Like, if I want to be referred to in masculine form, I should just be able to pick Hebrew masculine form. I don't know, give it a better name, or you could be selecting Hebrew feminine form. Because we didn't think about the internationalization aspect of it to the full detail of things, we're not able to provide the localization industry with more variations of languages. Michal: But do you think that companies will like more variations, because it does add a cost if you have to create two versions or three versions of each language, it does mean you have to invest more money. Gilad: I actually proposed this to, at Microsoft when I was working there at a very early stage and I was thrown out of the room. I was just thrown... Michal: Like that meme, exactly. Gilad: Yeah. Yeah Michal: Through the window. Yeah. Gilad: Yeah. It was a very good conversation, but it was thrown out of the room. And actually the person that I sat with was the director of the team at the time. And he invest, invented MUI. He's quite a fun person to talk to. Very knowledgeable. Always an interesting conversation. And he, at the time, basically said, look, me and my wife, you know, we didn't have cell phones back then. Me and my wife, we use the same profile on the computer. How are you going to solve that? Right? Michal: But that's not the case today. Gilad: But that's not the case today. Nor was the case at the time, also, Microsoft at the time was investing about a million dollars per language for localization. And you can multiply that by 120 languages. Michal: Yeah. Gilad: It's quite a bit, even for Microsoft. At the end of the day, no division manager wants to see a 120 million bill for localization. And so at the time, what they did is they actually came up with another set of resource management, and they basically say, we're gonna extract and localize only the first level UI and localize that, and that's 50, 000. Michal: Mm hmm. Gilad: And so It was a cost issue at the time. And I said, Hey, why don't we take the first level UI and use that technology to translate into masculine feminine form pick which one, you know, you want to translate for a million dollars and pick which one you want translated for 50, 000, I don't care. It was a cost issue and a technology issue. They did not want to invest in the resource loading technology. They were too scared to touch it because it was working. And also from the cost perspective, they didn't want to... They didn't see the inclusive wave coming in. But moving forward 10, 15 years, we have a very different scenario. We have cell phones, you have smartphones that basically are all yours. You don't share them with somebody. Localization cost has dropped. Machine translation is increasingly more accurate. And now with the AI revolution I think you're able to take a set of strings and turn them into feminine or masculine form rather easily. And so we're at a very different stage right now where maybe now this idea is more mature to the point where it's cost effective and easy to implement. Michal: Simpler and cheaper. Gilad: Yeah. Michal: And so maybe it's worthwhile. It's a good point. Gilad: Well, what's stopping us today is the same thing that stopped us 20 years ago, which is the resource loading technology. And so today Unicode is responsible for that. And that's one of the items that I tend to or want to bring up with them. Because there's 15 or 16 different markets that require translation to, in the case of gender, to different genders. The Japanese team, by the way, when I proposed this idea, had a very different idea around it. They basically said, you know Japanese children from age, I think, 7 to 12 aren't able to read Japanese as adults. They basically need a simplified version of the language. Why don't we use this to create, you know, Japanese kids variations so that they're able to use computers more easily. Michal: Yeah, it's true. And you can take that in different kind of, like, formality levels. Gilad: Yeah. Michal: On different variants of languages, I would guess. Gilad: Right. The gender is what I started with at the time, because that's what I thought about. It's probably the largest piece of cake, right? Michal: Mm hmm. Gilad: But if you look at the ability then you're able to, to do all kinds of variations. Michal: Yeah. Even age variations, maybe, if you want to explain something in a more detailed way to some people, but then have a simpler explanation. Gilad: And so that's a perfect example of internationalization. At it's very core fundamental version it can impact localization scenarios. Michal: Yeah, amazing. So I have another question. But I'm taking you back a little bit because you said... You mentioned that to get Microsoft, to implement some kind of fixes, you worked on usability studies. Gilad: Well, at the Institute of Israel that's what we're doing. Microsoft didn't want to invest in this. Michal: Yeah, so that's exactly my question. How do you convince your employer or a company they work for to actually invest in usability studies, to actually prove that localization or better localization is worthwhile? Gilad: I don't know that you need to invest in usability studies for everything. I think once you have some certain established standards and industry industry knowledge that is fairly stable, then you're able to make design decisions. So at Microsoft, basically what they used to do is you get the English UI and then you make design decisions for Hebrew and Arabic based on that. You say this has to be mirrored in a certain way. You give the requirements and... I think the biggest advantage that I had is that I was very senior in that space. And had a lot of years behind me, that people that I worked with along the years counted that my decisions were correct. And I used to tell them, I take full responsibility for any design decisions that I make and ask you to make. Because I had to influence without authority across my entire career at Microsoft. I never had a team with the exception of the test team of direct reports. I was a subject matter expert. I was able to scale at a certain point because we put in a system. I think the windows organization was a few thousand people in various positions, and we were a team of the international team localization and internationalization and quality assurance was about a hundred people. So you had to scale. And you have to pick and choose who you engage with. But the idea is once you become a subject matter expert and, and make yourself available , and prove that you're able to basically make the investments more time efficient, then teams tend to come to you for help. They tend to say, Hey, I have a question about X rather than going and figuring out on myself by myself, I'll just reach out to the right expert. In the international team, we, we actually put in a system that was very good for that. Michal: What kind of system was that? Gilad: So we basically suffered from total chaos in localization for many years. Michal: Mm hmm. As localization experts do. Gilad: Yeah, right. More so on larger scales and bigger corporations. I think because you're working with more players. Resources tend to be problematic. More so if you're building a platform, platforms like operating systems tend to be interesting, every once in a while there's a reinventing of the wheel to a certain degree. So that never makes anybody happy because you have to bake in again, everything you just did on previous versions. Michal: Yeah, and I would imagine that this position is a free agent kind of where you're connected to all the departments, but not connected to any of them... Gilad: Right. Michal: Does also contribute to that chaos. Gilad: So that kind of brings to the, you know, the career story at Microsoft. When I was on the quality assurance team I filed a lot of bugs Michal: They did not like that. Gilad: No. Michal: No. Gilad: No. Some were localization bugs where the reading order is bad and you have to insert Unicode control characters, very straightforward issues. Michal: This full stop is not in the right spot. Gilad: Yeah, I mean, you just say, you know, the reading order is incorrect... and so the localization issues are less of a problem because you're dealing within your own team, right? That's on the localization layer. The more complex bugs are the code issues. Something that isn't mirrored correctly. Something that doesn't function correctly when mirrored. Design change requirements for internationalization. Hard coded dates, hard coded fonts for localizability. Hard coded strings for localizability, all kinds of things like that. Not thinking about international users at all and how they might use this specific features. Those are not just code bugs. Those are what they call or classify as design change requests. And I had many of those. Michal: Okay. Gilad: And most of them were taken. None of them were taken easily. So it was always an ongoing conversation. Some teams were more receptive, some teams were less, depending on the design change. But it was basically selling. Selling. And I think it tends to be an easier job when you're not afraid to step out of your square. Michal: How do you mean? Gilad: People tend to go into their comfort zone and say we have internationalization support. Why don't we just build on top of that? And then somebody like me comes and says, well, I'd like to have Hebrew in two forms. Michal: Yeah, it needs to be a little bit better, right? Gilad: Right, it needs to be different. And so for me, it was easier to go to those teams and say, you know, we need certain design change requests or certain design changes to make this happen. And work correctly across all markets. And you get all kinds of responses. Some of them were just PMs shaking their head and going, I didn't think about this. Others were, oh, we just shipped to like 16 markets, and then you have to explain to them there's no such thing in Windows. You can't make language decisions on a feature basis. Certain teams might assume that they're shipping to a set of markets and then realize that they're shipping to 120 languages. And that they're being localized. And so that's really interesting because it's a very big eye opener. Michal: Yeah, how does that happen without that team actually knowing that it's going to... Gilad: They hand off localization resources. That's a battle on its own. The localization PMs have to sit there and beg them to send the resources on time. More so on a waterfall-type release. More so with the Technology that was a little bit older where you're sending it to the vendor across the seas and you're getting it back every two weeks or every week and you have to integrate it into the build. And then 20 things have changed by then. And the feature team changed the string and it's just one of those things where you're like, we're being... there's shots from all directions, there's shots from all directions. What do you do with this thing? It's just a back and forth exchange. Again, if you invest in the engineering system. I think you can avoid a lot of these things, and it just goes to show that at the end of the day, even today, the AI revolution is going to be very helpful, but it's not going to replace the human nature of not making things very organized sometimes. Michal: Yeah, and not wanting to change, make changes. Gilad: Right, right, right. Michal: So let's say that you have your system, you have your standards. Mm hmm. You still have to inform people. Gilad: Right, so.... Michal: And kind of get them to actually use them. Gilad: So the journey at Microsoft was really funny. Because... One of the releases, we had a fire drill. The last three months of the release was just fire drill, fire drill, people working 16, 18 hour days just to fix bugs, just to prioritize things, just to get things out of the way. It was a very stressful release. The senior leadership team really didn't enjoy that. And then, you know, after all that was done we basically sat down and said, how do we avoid this moving forward? Because what happened here is that we, for persistently for two years, we said, you're delaying things too much. We're going to have requirements. We're going to have bug fixes. The international build is broken. It's just not working. The quality assurance team isn't able to even install it. How do you make sure these things don't pile up at the end again in the next release? And so what we developed at the time is a system that basically... we called it the international walkthroughs. And it basically goes hand in hand with the feature teams to design, develop, and localize features with internationalization baked in across the entire life cycle from the design phase. And we also had to divide the team so that... we couldn't handle all the different teams at Microsoft or at Windows. And so what we did is a champion kind of program where every feature team had to give us. a person that was responsible for internationalization in that team. They would pair up with somebody like me, and I would mentor them. But not only mentor them, I'd do the design walkthroughs with them, with the features and the specs and everything. I'd go shoulder and shoulder with them across the entire life cycle. If they had questions, if they were triaging the international bugs and they had interesting questions around those, we would help them triage them and make sure that their priorities are set correctly. And I actually have really interesting numbers around that. The bug life cycle dropped in almost 15-20 percent, the bugs disappeared a lot quicker. The number of bugs was a lot smaller. 10-15 percent bug count drop. And so we actually saw a persistent drop in every m that we could think about by engaging very early, having very direct conversations with the feature teams around what we'd like to happen, baking it into the specifications and working with them across the entire life cycle, across the design, the development of the different milestones to make sure that we're making the right decisions along the line. It made their life easier. It gave them more visibility into internationalization, and it also grew the internationalization aspect of things across feature teams because the tenant champions that were responsible were not direct reports to the international team. They're inside the organization. So now you have, you know, 100 people inside the organization that are able to speak about internationalization more naturally. Michal: So did you find that it really changed their approach, these champions? Gilad: Yeah. The champions were great. Michal: Yeah? Gilad: The champions just dove head first in this thing. Because you have somebody mentoring you. You have somebody that's shoulder to shoulder with you. You know, the, the classic scenario of localization teams, more so in larger localization teams, is that let's say we have a certain feature team and there's design requirements for bidirectional languages, for European languages, for Asian markets, all those. Each one of us used to approach that team individually and I used to call it the gun to the head. We need X, Y, Z. And so that poor team is coming back to us and saying, hey we have like three of you approaching us. What should we work on? And that's a very valid question. And so when we started the design walkthroughs and actually had meetings where we go through the spec and then have meetings where the UI designer used to show the UI flow and then we give them notes on... Here's what we have to put into consideration. All that kind of started to make the international voice more consistent. And I think that was our biggest challenges. How do you get the international voice to be consistent? How do you have the subject matter expert for Asian language and subject matter experts for Middle Eastern languages sit together and say, you know what, we need to make a priority decision here. What's more important, right? And so that's actually an internal conversation we need to have. When we see the larger picture and say, you know, maybe support for certain bugs need to get fixed for the Chinese market, much larger market, much bigger impact. Maybe we need to put that in priority instead of other things. Michal: So what kind of roles did these champions come from? Gilad: We had them come from all different aspects of the development. So we had developers, and we had testers, and we had PMs, all of them. Michal: But not designers, not writers. Gilad: The designers were really hard to crack. Michal: Why? Gilad: Because the design team at least at Windows, wanted to work in as much of a sterile environment as they could. They were building based on research. And everybody has a design idea. And so it kind of overwhelms them. Michal: Yeah. OK, I can see that. Gilad: And when you want to orchestrate a design change, like Windows 8. Windows 8 was a paradigm shift in design change for Microsoft. A less successful one. Michal: Yeah, I remember. I do remember. But it was a big change in terms of how it looked. Gilad: It was a huge change and the team was siloed basically by design from the higher ups to work on that. Michal: Do you think that was a good decision? Gilad: To silo the design team? I think just overall the robustness of the design was something that we always struggled with because they kind of siloed themselves in. And also wanted to surprise. Every release I used to kind of wait for the last two weeks. Because the design team wanted to surprise with something. In Windows 8, for example, they wanted to... you know when you have long strings and you want to to make them shorter, you usually put the three dots at the end, right? That's called text trimming. The design team decided that they want a fade out effect. Michal: Okay. Gilad: Rather than three dots, fade out effect, make the UI more readable. I don't know. That was the idea. And that's great. I, I can't argue with them on that. You know, they're the designers. The only issue is when you bring something like that at the last two weeks of the project without consulting your international counterpart is that you tend to have bidirectional text trimmed from the wrong end. Michal: Oh, no. Gilad: So the leading edge of the string is being trimmed... Michal: At the beginning. Oh wow. Okay. Gilad: Being screwed up there. Unreadable. And then you approach the design team and say, Hey, you know, unless you fix this bug, we're not gonna be able to ship this. That's where the very, very difficult conversations happen because they escalate very quickly at the end of the project. Michal: Yeah, that's really critical. Gilad: Right. Michal: It's unusable. Gilad: And unfortunately, even inside the international team, some of the entities often like to stay in the comfort zone. So they're not able to have these difficult conversations. And it goes up really fast, really quick. We're looking at minimum director level decisions to take this or leave it. And you struggle across multiple stakeholders. The localization team has their own triage. The feature team has their own triage. Above that, you have the, what they used to call the war room. And above that, you have, that's the feature team war room. And then you have the division-wide war room, um, which I thought was always quite entertaining. It's not a very politically correct place. It's very... you know, there's very strong leaders there that want answers and want solutions very quickly and are not there to hear anybody complain about why this went so bad. And so in that particular decision, I had to go to the Windows war room and, and say, Hey, you know, we've never had a scenario where we trim the text from the leading edge of the string and making the UI completely unreadable. And the design team thought that we could just fix this down the line, which I thought was quite interesting because they basically didn't even understand the impact of certain markets and they didn't want to. They were so fixated on English and the left to right languages that they said, Hey, but these smaller languages or whatever, they can suffer there. And so I never saw it that way. Michal: Well, it's completely unusable. I think if you, if you think about it, even in English, if you cut the beginning of a sentence. Gilad: You always say, you know, if we're not able to reach an agreement, we're going to have to have this escalated to the... I've never escalated things in hostility. I say, why don't we write an email together? We'll say, here's the two kind of viewpoints on this thing. And we need a decision on this. And have the directors make a decision on this. And so that's, that's always quite interesting because that brings a very different dynamic into the game. Michal: Yeah, I think it's more of a shift of perspective because if you say, okay, our interests are actually shared, you're not two competing teams where we have two competing kind of arguments and one of us gets to win and the other gets to lose. It's like we have a shared goal. Gilad: It's more... how do you not burn bridges? Michal: Yeah. Gilad: Right? Michal: Definitely. Gilad: Because you're going to be working with that same feature team in about two days. Michal: Yeah. It's not even not to burn bridges as much as if you empower, I think, localization teams to understand the impact that they can have. Gilad: Right. Michal: And then come from this from a point of confidence. Gilad: Right. Michal: So they don't come into this defensive. It does not become as much of an argument and as much of a fight as it could have been. Gilad: Yeah, exactly. I think it takes a certain set of elements to put that in place. You have to have a leadership team in the international space and the localization space that enables their their direct reports to go out of their comfort zone and engage teams upstream. Put some sort of engagement framework across that. Make sure that you translate some of these things into engineering systems down the road, so you don't have to reinvent the wheel every time and not have developers make mistakes and the quality assurance team busy with bugs that repeat themselves. Michal: Yeah. Gilad: They have to convey that to senior leadership and they have to engage with them in the same manner on a almost weekly basis. Michal: Yeah. Gilad: So that everybody knows that everything is going correctly and that we're able to kind of clear the road for the release. And also recognition is a huge thing. That's the other part, by the way, of that program with tenant champions, is giving them recognition. You know, managers always struggle to find new opportunities for their direct reports. Internationalization is great. Localization is great. You know, if you're able to convince the leadership team to bring these champions in and provide them with value so that at the end of the day in their, I don't know, annual one-on-ones or evaluations they're able to say, Hey, you know, I grew as a internationalization expert, right? I helped the team steer around the international space. That's a growth opportunity for individual contributors within the feature teams that normally don't deal with these things. Michal: Yeah. It's like an added skill that not a lot of people have. And it's very easy to add on. Gilad: Yeah, I think that's a thing for us in the space to acknowledge that we want to enable more people to care about this and be knowledgeable about it. Michal: Yeah. And definitely find that when people start learning about localization, specifically people who are not from the space at all. Gilad: Yeah. Michal: First of all, they get really excited. It doesn't matter... Developers, designers, writers, anyone who's not in localization, they learn about localization, they get really psyched about it. Because they like, Immediately understand what impact they could have on lots of people around the world that they've never thought about. Gilad: Right. Michal: And never considered. And then they get really excited. They really want to be part of this and they really want to be able to help make it better. Gilad: Mm-Hmm. Michal: And it's something that I've been seeing. Once they hear about and they really understand the impact of localization, it gets them really excited. Gilad: Yeah. It's it's clearly that. Enable people to make the right choices and be part as an active contributor. That's been the, I think the strongest thing that we were able to do with these design walkthroughs. Across the entire windows division. By the way, one of the teams that got really inspired by this was the accessibility team. They said, wow, we're struggling just like you. And we said, why don't you just hop on the train because we already have a system in place and we can just have you go into these walkthroughs and put your requirements. And find the champions, of course, that can champion accessibility across the board. Again. That was, I think, one of the better investments we've made. Because if you look at the impact of making inclusive products at the last, I don't know, 10 years... the timing was perfect. You enabled the right team at the right moment with the right kind of mindset for the entire market. Michal: I think there's also a lot of similarities between accessibility teams and localization teams in the sense that they both make content more accessible to people and the adjustments that are needed are sometimes very similar in terms of font sizes and font types and colors and whatever. Sometimes the changes are even the same changes. And so I think there's a lot of value to be brought in that collaboration. Gilad: Yeah. All that is one of those things where when brought together in a very efficient way brings value to the organization. Michal: Yeah, absolutely. Gilad: Right. So... yeah. Michal: I mean, I understand the value of making it more usable, but I'm not sure it would actually add profits. So they don't have any interest in making it better, in that sense. Gilad: Right. Sure. Yeah. That's the long going conversations of... what's the return on investment. Michal: Yeah. Gilad: I see it very differently. If user X in country Y is paying for software and user Y in country X is paying for the same software and they're both paying the same thing. Why is one of them getting a different user experience than the other? Michal: I mean, I understand what you're saying. As a person preaching for better UX, I am supposed to agree. And I do generally agree, but it sometimes feels like companies are more focused on value to their bottom line than they are on value to the UX, even though within the teams, the people who are actually working, they do want to make things better for people. But at the end, what drives. The way the company reacts to things and how they act in general in the localization space is profit, right? Gilad: I think that's why at the end of the day, some of the standard institute work is quite interesting from the UI perspective. Standards are typically a requirement to get into the market. Michal: I see so they have to... they're forced to use them. Gilad: In certain countries, they have to. We're not talking about smaller application developers. Nobody's going to approach Tinder and say you're not adhering to local standards in terms of UI mirroring, for example, or text selection. But for larger companies like Google or Apple or Microsoft that have government contracts. Michal: So they have to. Gilad: Say we're seeing that it impacts productivity in the country, for example, text selection or incorrect UI mirroring. So we come and say, we have these standards, we're going to be working with you on implementing them. And that's going to be something that we'd like to put into government contracts moving forward. And then you have everything trickle down to the rest of the market. Michal: I see. So if Google and Apple and Microsoft are doing it, everybody will do it. Gilad: Well, it goes back to the beginning conversation of, like, a small app company wants to see how to do UI mirroring. They install, I don't know, Android and look at it and go, oh, that's great. We'll do that. You know, so it kind of trickles down. Michal: You just went straight to where you can actually drive change in a way that's going to trickle down all the way to the... Gilad: I'd rather not have to work that entire mechanism. But unfortunately, that's a harder route to take. Right? Michal: So it's a very strong position of influence to be in. Gilad: Nobody puts you in that position. That's another thing about the industry. Nobody puts us in a position to make decisions and say, do X and people go and do X. You have to get buy in. Michal: Yeah. Gilad: You have to show experience. You have to show impact on the market. I was able to change the Unicode standard at one time. It was a group effort, of course. It's something that I spearheaded. It was paired brackets. Anybody in localization for bidirectional languages knows that sometimes with the reading order, the brackets used to be unpaired. Have you noticed that it's been gone for a few years now? Michal: Well, yeah, of course. Gilad: So one of the reasons that it's gone because there was an idea inside Microsoft that Michael Kaplan at the time pushed. And he said, you know, we could make an algorithm that just pairs the brackets in the rendering engine. Really simple. So that's really interesting. There are a lot of very small things that we, as users, or even as... people are involved in this, but not in the very technical kind of aspects of it. We say, oh yeah, it just got better, right? Technology is better. Can you imagine the impact on the localization space? But, basically, so, the algorithm that renders the text had to have another change that basically says, here's a mini algorithm that says, here's two brackets... it took me two years to push it inside Microsoft. Michal: Oh, wow. Gilad: And the reason it took two years is because we had two text rendering engine, three actually, inside Windows. One for the browser, one for the modern UI, and one for the legacy UI. Michal: And you had to implement in all three? Gilad: And you had to implement in all three because each one of the teams used to come to me when I approached them and said, yeah if team X and Y implements them, then we'll do it. And they all knew each other because they all kind of built off each other. And so they're... I always thought that they sit in a secret room and go, don't do it, don't do it! Never! Don't, don't listen to him! And... Michal: They probably did. Gilad: Yeah. They're probably going to be watching this video and go... Michal: Oh, they're on to us. Gilad: But so, but, but it was quite a bit... you know, text rendering engines are very complex things. I'll give them that I, I wouldn't want to touch it. It's fragile. You never know what you're going to get. And it's one of the funnest things to work with... I mean, rendering engines people are really smart people. And so sitting with them and hearing about the different scenarios and the edge cases and things like that... But sometimes you have to just say, you know what, yeah, there's going to be edge cases, but like 80 percent of the time, we're going to see great things. Right? And it's better than not seeing it at all. So getting one team to just build a prototype was what broke the ice. It took them a week. And then they said, Great, well, yeah, it's a fun prototype. See you in a few years. And so again, it took the director level escalation of saying, Hey, how do we move this forward? The reason we moved this forward was actually bug data that we had from a previous release. We had over a thousand bugs across the Windows operating system for paired brackets. Those were a thousand bugs that we had to send back to the localization vendor and say, please insert the correct Unicode control characters to make sure that these parentheses worked. And so one of the key points is have data and have an expert present the data and say, you know, we had a thousand of these bugs. If we're able to change this, we're not only changing it yet for Microsoft, for Windows. We're changing it for any application that runs on top of Microsoft. And so you're able to not only make an impact on the operating system level and avoid these thousand bugs because the next release they weren't there anymore. We had maybe a dozen bugs for paired brackets on very complex strings inside UI that me and you would never see, the device manager or something like that. And so we were able to see the impact immediately. Michal: Wow. Gilad: And we never measured the impact outside Microsoft. Like nobody said, wow, all these bugs are gone. Thanks. Somebody must've changed the Unicode control. Being able to change these things shifts the industry to a better place so that they're able to work less to produce more. You know, a thousand bugs is a thousand bugs. Michal: Yeah, no, I mean, even the time that for us as localizers, that we don't have to invest in copying that right to left character. Pasting it into the editor, and then doing that again and again and again, every time... Gilad: Are you still doing that today? Michal: No, but I used to have to. Back when I worked with Trados Studio, I used to have to. And now I don't anymore. Gilad: Why not? Michal: It just works. Gilad: Oh, it just works. Michal: Well, I'm actually not sure if CAT tools automatically insert that character, or I don't know exactly what's happening in the back end, but I don't have to. When I type a bracket, usually it goes into the right place. Gilad: Right. And that's cost effective. You know, you're able to produce localized versions quicker with less bugs and less engineering overhead and less fixes from certain teams. And so you have to have subject matter experts that are willing to take the risk and stick their neck out and say, something here needs to improve. No matter how big the players, and usually there's three or four big players, we need to take this in and do this. And sometimes they need the forcing function. Sometimes even the teams internally need the forcing function. If you talk to the localization folks at Microsoft and they say, Oh, you're going to have a standard for UI mirroring and it's going to be a forcing function. Great. We can go to the feature team and ask for certain things. But that's, I think... if a company needs a forcing function to improve something, then they're not thinking about their international users as much. By the way, it's true across all big tech companies. You know, maybe I'm picky. Michal: No, but I would imagine because there's turnover and people, you know, retire or leave, and then new people come in that don't necessarily know exactly what things were or how they should be done. And there's no kind of internal training function, I guess, for localization, because why would there be? And there's no standard, so that's what happens. I think in localization in general, there's no training. Gilad: Well, nobody can teach you how to challenge design. Michal: Yeah. Well, maybe that's what people should be taught is how to challenge, not specifically design, but how to challenge the people around them to make sure that localized experiences are as good as they can be. Gilad: I think that's true. I think that's also something that just on a interpersonal level organizations have to enable that. Michal: Yeah. I don't know if that's the case for internationalization, but I find that localization teams... and it's very similar to writing teams as well. They're not expected to make noise, but they have to if they want to actually be able to do their job well. So it is a movement within the industry. Gilad: Yeah. Michal: For people to learn that they need to make noise that they need to demand better design, better decisions, better collaboration. Gilad: You know, one of the things is the risk versus reward equation. Like, is the risk bigger than the reward or is the reward bigger than the risk. And so I was able to say, you know, what's the risk for you? And feature teams say, you know, people from the market might come back and say, this isn't good enough. And so I'd always say, if that's a risk for you, customer feedback or having the market reject this, or... I'll take that risk. You can take the reward. And I'd highlight that, you know, at the end of every milestone I sent an email to their manager and said they did great job because they were willing to take a risk on this. And we're now seeing that this feature is in much better shape. And so being able to mentor your feature teams, rather than just come begging or holding a gun to their head is a much better approach, I think in general. Because it's much more constructive. Michal: Yeah, that makes sense. Also, you come from a place of, again, confidence and kind of, I know what I'm talking about. So people are more inclined to trust you. Gilad: Everybody has impostor syndrome. Michal: Yeah. Gilad: Right? Everybody, even I had imposter syndrome. You know, I'm not the smartest person in the company for certain things. Whether it's design changes or bug fixes or just strategy moving forward. I put together a multi release strategy for bi-di investments. That was a first of a kind. But I had to sit down with some people, for example, that built text rendering engines. And they're, I mean, they're in a different level. And if you're able to identify who the key person is to make that investment, they'll walk you through it. You're going to be learning a lot from them and they're going to be able to get the confidence that if something in that scenario that you agreed upon, didn't go correctly, I'll take the responsibility. I asked you to do this. This is a scenario. I want you to enable. If you know how to enable it better than I do in terms of the technical edge cases and whatnot. I'll work with you on those will prioritize them and anything that goes wrong with this thing. As long as I sign off on it, it's mine. I've asked you to do it, I'll take the responsibility. And I think that's the difference between somebody who's willing to just work within their comfort zone to somebody who becomes a subject matter expert. Because nobody comes and says, you my friend are a subject matter expert. Congratulations. Here's your badge. But that's the way to achieve it. Michal: Yeah, you pick it up and run with it. Gilad: Yeah, and take responsibility. Be able to stick your neck out there and say, I'm making design decisions. Michal: Okay. I think that's a good note to end with, I have to say. Gilad: Yeah. Michal: Yeah. I think so. So thank you so much. Gilad: Yeah. Thanks for having me. Michal: Fascinating. Really. And so interesting. And I really enjoyed every bit of it, and I'm sure other people are going to benefit off of hearing everything that you've managed to achieve. So thank you, and thank you for sharing. Gilad: Yeah, and let's keep pushing forward. Michal: Definitely, for bidirectional languages, and in general as well. Gilad: Yeah, I think we're very fortunate now to have the AI revolution approach us, or is already there. And I am hoping that we're able to spearhead some new ideas around internationalization and localization. B ecause We're really here to see things move forward very quickly. So it's quite interesting. Michal: Exciting stuff. Gilad: Yeah. Michal: Yeah. Okay. And thank you for joining us on the Localization Process Pod. If you found this interesting or any other episodes as well, then feel free to look us up on www.localizationstation.com or on Spotify or on LinkedIn for more Localization Process Pod episodes and more processes from other companies as well. And until the next episode, thank you for being here and have a great day.
- Achieving cross-company collaboration with Aglaia Pavlerou
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.