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.