Globally Speaking
Podcast 038
How Salesforce Drivesa Global Localization Engine
RThis week on Globally Speaking, we have our first return guest. Previously, she talked about her role and importance of the Unconference in providing a place for localization professionals to share ideas, skills, and improve the general IQ of the industry. Today, in a conversation with Michael, they discuss her actual job—her day job—and the challenges in running a localization group in an enterprise software product. And what she thinks we should be looking for in a strategic partnership. Let’s get our guest to introduce herself.
TI’m Teresa Marshall. I’m the senior director of localization and globalization at Salesforce, which means I own and am responsible for all of globalization and localization efforts within the R&D organization of Salesforce.
MSo you own all the localization within the R&D. That includes products. That includes…what’s the scope within R&D.
TIt includes all of product localization. So no matter what, like all the clouds that Salesforce has. It includes technical documentation, documentation that our support organization uses, especially in direct communication to the admins of Salesforce. It also includes our training product called Trailhead, which is a completely new animal for us. It includes any sort of products that are built on our platform that belong to Salesforce but not necessarily into a particular business unit, as well as all of the products that are mobile.
MOkay.So your background is not just…we’ve had you on the podcast before, talking about the Unconference and that area, but you’ve also worked for some other large companies in The Valley. Talk about the size of company and things you’ve learned in that time, where you’ve been.
TSo I actually started out as a linguist. And I started out as linguist on the vendor side, and then moved into program management and management all within localization. And I guess the biggest company was Google, which has been a while back by now.
MWere they big when you were there?
TWell, they were just…let’s say they were starting out. There were about three people in localization when I started and 45 when I left.
MYea. So even Google starting out can be bigger than some people’s.
TYes, totally.
MAnd if you could talk at a high level. What is localization at these big enterprise companies…what would you say is the biggest difference than what other companies may come up against?
TThat’s a really interesting question. I think it really depends on what space you are in. So the first sort of difference I think for me, in my experience but also just something that is consistently reiterated to me, is like it really depends on, are you on the business side of things or are you providing business software—B2B or B2C—or are you a consumer company.
So with Google, I came from a consumer company, right. So we were doing email, Gmail, and all of these other things, and calendar.
MSo individuals have the chance to choose whether they use the product or not.
TRight, and most of them, if you disregard the whole advertising part of it, most of them are pretty much free. So you’re providing a service or a product for free. Salesforce doesn’t. It’s not a free product. It’s a very highly sophisticated…it’s a business software, a business product. It means to be, and is, a lot of things to a lot of different people. So our customer is very different. So the role, the persona of our admin, of our end user, and how they are, as a population, using our software is very different than in some of the other big enterprises. So then, that probably makes a big enterprise not very much different than a smaller enterprise business software company.
MSo there’s sort of similarities within the vertical?
TRight. Exactly.Well the most obvious thing is if you’re a big enterprise is the scope that you just highlighted is huge. So we have not only all the clouds and all this sort of volume that we deal with, but we have a large number of languages that are driven not only by corporate marketing and where our corporate marketing sees the next target for us as a company, or where any corporate marketing would see that, but it’s also where our user is. Where are our customers, and where do they want to be.
MHow many languages do you guys support at the moment?
TRight now, 34 that are actually localized in two tiers. And then we have about 65 where we provide the ability for the customer to build on top of our platform.
MOkay, you said 65.
TSixty-five.
MIn addition to the 34?
TIn addition to those, yes.
MAnd that’s sort of like self-localized. The customer wants to do it?
TThose are primarily provided so that our customers can build on top of our platform. Primarily in terms of custom apps. It’s basically the grammatical structure that you would need for those languages to be grammatically correct in the display, in the UI.
MOkay. I remember years ago, the first time you and I even talked, you had lunch with me to basically tell me I don’t even know enough to understand what you guys are doing at Salesforce. And it’s taken me about 10 years, and I think I may be starting to understand. And it has to do with that grammatical structure around your UI.
You all were early on into this area of having custom fields and being allowed to have this dynamic content that users can change, and generate their own terminology for, essentially. And that created unique, very customizable challenges in your localization team.
TYea, I think the easiest way to describe it is like if you have your regular interface. Let’s use an email program as an example, and you said “I don’t want to call ‘Inbox’, ‘Inbox’, I want that to be ‘My Letters’ or I want that to be something else.
MThe “Great Folder of All That’s Important” or something.
TExactly, so in our software, you can do that. You can go in and you can rename a particular object or that particular item to fit your business jargon, to fit your sales process, to fit your personal preferences. And that’s reasonably easy to do, something that we all struggle with. Concatenations; you can do that. Dynamic substitutes in the UI, but it becomes really difficult when you talk about other languages that are case-sensitive and have gender, and all these kinds of things. So we actually developed a grammar engine that helps with that, and we have those grammar engines in those 34 languages that we localize, plus the 65 that we support. And here’s the really cool thing, we just open-sourced that, actually.
MOh, that’s great.
TSo, that is available for anybody to use, to contribute to, to take a look at and say “this is all good”, or not, or propose improvements.
MWhich would be hugely valuable for smaller companies, for startups, for people who are just now entering into it. They may have aspirations of being 34-plus languages. To be able to get a grammar engine that allows them to understand the rules and the structures out of the gate with you all. That’s great. Where can people find that?
TIt’s in Salesforce public open source gate hub, so you can find that, but we can certainly find the URL. It’s been published. We are actually going to talk about it at Unicode as well. So there’s going to be a number of presentations and a blog that is coming out about that.
MSo, we talked about some of the sort of intricacies of what was happening at Salesforce. I think some people in your position would say, because we have such unique challenges—at least however many years ago when you started at Salesforce and when it was unique at that time, it may be less now—we are going to find the premiere company in the industry to support us as a partner for language, and here are the top 5-10 companies, and we’re only going to consider them. And it seems like a lot of companies start thinking that way. We’re an enterprise company and we want to work with enterprise-style companies. You actually took a very different approach to this. Can you talk about that?
TYes, I think there’s two things to remember too. We weren’t quite the big enterprise that we are today when all of that started, but I think it’s still applicable.
MRoughly how many languages were you supporting then?
TSo, I want to say we were at 10.
MOkay
TAnd the interesting part, how all of this came about is really that one day or so the story goes, our CEO woke up and said “I want my customers to be able to rename everything. We shouldn’t dictate what the sales process looks like for them or how we call it, so you need to make this rename-able.”
MLet’s double the number of developers and start our whole process over again.
TSure. And the person who owned localization was smart enough and went in and said, “That’s impossible. You’re going to ruin anything that is localized; anything that is translated and pretends to be localized.” And so they said, “Here are two of the smartest engineers. Go figure it out.” And it was a massive undertaking, even when it was six languages or 12 languages, whatever it was back then. Because it required a complete rewrite of how message strings are written, leaving out all of the grammatical details. Just having to rewrite your entire UI is a massive undertaking, even if, at that point, it was a much smaller company; a much smaller product.
So within that effort, it was also clear that you can’t just hire six linguists that do that. You have to scale that. So with some background in localization project management, the owner went out and said ok, we’re going to find somebody who I can trust, where I can have a direct conversation with a linguist, because I don’t know what the grammar structure is in Russian. There’s only so many books I can read in a week to figure that out. Specifically, we have about a day and a half to write the grammar for a particular new language. And so, that was really the start of a vendor relationship, going in and almost pretending to be working directly with individual linguists, rather than with a big sort of powerhouse of localization services.
MSo the partner was able to step aside and let the linguists come up to the front and do that?
TRight.
MAnd that’s what you all were looking for, was that type of relationship.
TRight. So it was less on the brand and the style and the tone, and it was really having conversations about “how does possessive work in Finnish” and of the thousands of cases that you have, which ones do we need. Because the grammar engine takes a look at nouns and articles and adjectives. We don’t deal with verbs. There’s a lot of within the conventional understanding of a grammar of a language that we completely disregard. But we sort of focus it on what do we know, or what do we need to know in order to make the UI work?
MBecause those three factors, as soon as you add verbs to it, it becomes too complex.
TWe don’t allow the renaming of verbs. So you can’t say “open this” and say “I don’t want to call it ‘open’, I want to call it…I don’t know, make it up here or whatever. I can’t come up with a good example. There’s just some standard fields that are always the same and they have to be always the same. And they’re typically by now standardized across different products as well. When you apply a change, you say “apply” and when you send something, it’s “send”. It’s not “post” unless it’s actually posted in the sense of a social media post or something. So there’s a standardization of the UI language that happened that has nothing to do with individual companies. And so we saw that we don’t need to worry about those, because the renamed noun that’s part of an overall sentence. The sentence itself still gets translated just how it would be if we didn’t do renaming.
MWas that a decision you all were making from a business perspective and would benefit you all, or was it also what the customer was asking for?
TSo it was primarily…like what we determined as renamable is always sort of top-level entities, if you want to call it that. The standard objects that we have within our business software, and we’ve been trying to be as open as possible so that it has a big benefit to the customer, but restricted where either the complexity of a language would be too difficult to deal with, and too, almost like distracting. If you look at our various CRM-focused part of the software, the big objects are “Accounts” and “Leads” and “Opportunities” and “Contacts”. And those may change, and they change very quickly in the sense of, like if you’re a business. If you’re healthcare, maybe you don’t think about “Contacts”, maybe you think about “Patients”. And then, why do you need to teach your end-user? The person that you have…your salesperson, or whoever you have working with Salesforce or with that program that you have to remember that Contacts is actually our Patients. Why not be able to go in and say “I want to call this ‘Patients’”? And that’s how the idea was born.
MActually, in that space, that’s very much a strategic advantage because you have entire sales processes, customer-service processes centered around how that industry talks about itself, how they do business. All the jargon. It was a little bit of both. It was a business decision for you all and also what the customer was asking for. So you found thispartner, who was able to serve these needs. Get you to step out of the way. And they happen to not be one of the larger companies in the industry. Do you see that as being a unique advantage? Because in general, I hear a lot of conversation—we’re actually having a panel on this coming up—that it’s how do small companies not get treated like second-class citizens by the larger providers in the industry. How do these startups get the attention? Whereas, you’ve kind of done the opposite.
TRight. It was maybe quite not so much the opposite, but I think what happened on the one hand organically, and on the other hand just because of need, basically, is we were looking for a partner who would be interested enough in this kind of work when we were not the big enterprise. We weren’t the thousand-pound gorilla in the roomwho could demand anything. We were a reasonably sized company with something really complicated that we knew was going to take extra work that is hard to teach and you have to re-teach and re-instruct and check and re-test and everything like that. That is beyond regular translation. Software translation is never that easy, but we were upping the ante on that a little bit. When we actually talk about what our translators have to do on the UI, we sometimes describe it as linguistic engineering, because you have to add attributes to the strings that would never be there and are very specific to a particular language. What we found was a partner who wasn’t the same size as us, but was interested in a medium-sized business. I don’t know whether we would technically qualify for a description of a medium-sized business back then but this was about 10 years ago. We definitely weren’t as known as we are now. We’re not one of the big consumer product companies out there, where everybody is just clamoring to work with them. It’s helped us in two ways, because pretty quickly most vendors knew we had a solid partner, and we’re complex and we didn’t want to…it didn’t open us up to this constant barrage of “hey, you should be working with us”.
MSome of what I’m hearing from you is less about company size and…good business practice, good customer-focused practice. The two things I would simplify what you said down to are: get out of the way and let the translators speak—have that connection—and the second is don’t be afraid of complex problems. If you’re willing to enter into complex problems, regardless of what size your company is, you may be able to engage a more sophisticated, a more mature program, or a program that is growing—that could grow alongside your company.
TYes. Because of the complexity of what we deal with, what was always really important to us is to make sure that this is a partnership. The success of my vendor is ultimately my success. You know that I had very few people internally who worked on localization or our infrastructure. And there was no way that we could have scaled to over 30 languages with three people internally. I think what differentiates us from a lot of the other big enterprise localization teams is that we are a handful of people. So we can sustain and grow our localization practice and our localization efforts because we have a partner that is truly a partner and not seen as a supplier.
MAnd your partner has probably grown at least to the extent that you all have as a business, if not more, so you’re able to keep your internal employee number lower, and they’re able to scale.