When you’re a global company that keeps expanding into new countries, how do you keep all of your consumer sites updated in the local language-without spending a ton of time and money?
PayPal realized five years ago that it had to solve this problem or that it would hinder the e-commerce payment company’s ability to grow, says Matthew Mengerink, the company’s vice president of core technologies whose IT responsibilities include PayPal’s architecture and payment system infrastructure.
Today, PayPal has re-architected the software code for its site to allow simultaneous refreshes for 15 locales ranging from France to Poland. In the development community, they call this unusual achievement “polylingual simultaneous shipping” or “SimShip.”
“This is a big problem that’s been around a long time,” says Ron Rogowski, a principal analyst for Forrester Research who specializes in globalization issues. “For the most part, companies really do a poor job localizing content,” he says, noting that technology solutions in this area aren’t plentiful, and companies also must conquer organizational battles over who controls what content.
“Companies would like to manage their translations better,” Rogowski says, “to realize internal and external cost savings. But the real benefit is the potential for revenue growth, the ability to roll into markets quickly.”
That ability today translates into a large portion of PayPal’s bottom line: For PayPal, international business now represents 44 percent of revenues, which were US$563 million for the fourth quarter of 2007. The company’s re-architected code plays a key role in PayPal handling about $1,806 in payment volume every second of the day, as of late 2007.
Speaking French Isn’t Enough
PayPal, now part of online auction giant eBay, quite simply had to go global to support customer desire, Mengerink says. People outside of the United States were demanding that eBay let them use PayPal (the primary purchase mechanism on eBay) and demanding that PayPal be presented to them as seamlessly as it had been presented in English, he says. The company had to do more than present a stilted translation of English into, say, French or German, he adds.
“Imagine you’re going into a bank and you want to speak French,” Mengerink says. “The teller can speak French. But that’s not enough. You want to feel you’re in France. You want to see the French flag on the wall. Especially in the banking industry, it was very important to express something that people trust, in such a way that it is natural and native for them,” he says.
Traditionally, companies solve the localization issue by working with third-party translation companies, whose staffers convert an English-based site into multiple languages, says Mengerink.
The problem: “If you can’t send them the smallest amount of text, it gets fantastically expensive,” Mengerink says. “Here [at PayPal] you have a full site experience, you have to translate it, and we’re an Internet company, we update the site every six weeks. How do you not slow the company down with the process of translation?”
PayPal’s decision to custom-develop a solution is unusual and interesting, Forrester’s Rogowski says. Few software vendors compete in the translation tools arena; translation management system vendor SDL recently purchased its rival, Idiom, Rogowski notes. Also, many companies can’t even overcome the organizational hurdles related to translation, he says.
“There’s a whole organizational issue that has to be looked at, who’s in charge of what,” Rogowski says. For example, he notes, a consumer electronics company may not even have similar-looking content, never mind identical content, on websites in multiple countries, he says. “A lot of times Web content springs up without any plan for centralization,” he says. “Before your company can translate all of its sites efficiently, you may get embroiled in organizational messes, Rogowski warns, which is why some companies are tackling the problem silo by silo.
Not Paypal. Five years ago, Mengerink and a team of localization experts inside of IT began their project to fix the problem in a very centralized way.
Often, Mengerink says, companies facing this problem try to cut and paste code then translate it into different languages. But this can lead to trouble because it’s not simple to keep compressing and unifying the code, he says. “It’s far easier to manipulate text than code,” he says.
PayPal decided that it had to re-architect its code to accommodate the language localization issue-purely for reasons of business speed, he says: “If you get the architecture right, you can get into new countries faster.”
No commercial tools existed that fit the bill, Mengerink says, so all the development was done in house with a small IT team; PayPal declines to share the exact size of the team, or cost metrics.
“There’s this notion of a country code and a language code,” Mengerink says. “Your software has to understand two things: What country am I in and what language is being read? This is extremely important because there are countries outside the U.S. where customers can’t imagine not having multiple languages, Canada for example.”
“The first thing we said is put both codes everywhere,” Mengerink says. Then his developers had to create a code base with much more flexibility than the original, to convince the software for instance, that strings of information such as e-mail addresses, customer support phone numbers and time of day would change depending on the country code.
The code base was littered with static strings of information, which had to be changed to pointers to reference data that would get looked up, he notes. “Our first process was to create tools to extract those strings,” he says. “The first week there was much rejoicing. The second week, there was gnashing of teeth. The third week, we discovered the tools wouldn’t work. We had a massive blitz company wide to remove those strings from the code and text files,” he says.
The second key to the project’s success for PayPal: Ghassan Haddad, PayPal’s director of localization, and the development team created a tool that color codes text in the software code base to note newly added strings of text that will need translating.
“People just program as if it’s in English,” Mengerink says. “At the same time, the software extracts the new pieces.”
Then PayPal can send the new pieces to the translation house, instead of whole paragraphs. “This can take 5, 10 days depending on the size of the release,” Mengerink says. “Then off we go to the races, releasing simultaneously in all locales.”
Currently, locales outside the United States include the United Kingdom, Canada, Australia, Austria, Belgium, France, Germany, Italy, Spain, Ireland, the Netherlands, Switzerland, Poland and China.
Five Tips for Localizing Global Websites
What can other IT leaders learn from PayPal’s development approach for localizing websites? Here are five tips from Mengerink:
1. You’re Going to Build, Not Buy Don’t count on finding a tool that will be a great help, he says. “We built custom tools and they literally change every six months. This is a nascent industry. When you start looking at the publishing tools and content tools, most are appropriate for preview and publish,” he says. That’s a simpler model than what PayPal does, for example, frequently linking new content with new features, he notes. “There was a lot of fear, a lot of people saying “Why aren’t we being industry standard?’ Leverage what you can, but you have to be good at creating your own tools.”
2. Prepare to Be Heckled “In the beginning, there was a lot of healthy skepticism, even internally,” Mengerink says. Some of your execs and developers will note that their last company tried to do simultaneous shipping and failed, he says. “Some people in the developer community still don’t think it’s possible,” he adds. “Once it was done, we saw that it’s not just manageable, it’s a core advantage.”
3. The Earlier the Better The sooner your company can start working on a SimShip project, the better: “Once you get too big, you can’t afford the interrupt to the cycle,” he notes. “Very early on, you have to create the generic structures for the code,” he says. “Build every next thing correct.”
4. Hire the Right People The community of software developers skilled in dealing with language translation is tiny, Mengerink says. You will have to choose your developers extremely carefully. “If they don’t know who to call, they can’t bring the right team,” he notes.
5. Find a Business-side Champion (Ideally in Product Development) “Having someone who’s a VP or higher advocating the international mentality is key,” he says. “You have to have someone who advocates SimShip. We had people here who said ‘this is a mistake’. You need one person carrying that story, explaining it, preventing things from being chaotic.”
So what’s the next challenge for Mengerink and his developer team at PayPal? “We got very good at managing content with engineering,” he says. “Now the question is, how we put that content management in the hands of business. They want to change it themselves without an intermediary. The business folks are saying ‘we respect you but pretty please can we do it ourselves.’ ” That’s a challenge, he says, given that the development toolset will continue to grow.
By the way, PayPal isn’t looking to license the technology it developed. “Our tools are built for PayPal,” Mengerink says. “We’re encouraging others to build it for themselves.” While his team worked primarily in HTML, the programming language is not the important choice, he says. “Think about the methodology. That’s a really critical part.”
What’s the bottom line for PayPal from Mengerink’s team’s work? “Today, we have 15 languages, 17 currencies, 190 markets,” he says. “Our code base has grown a lot. All of the new code is being built using the right structure. You have to build internationalized.”
PayPal’s re-architected code base now keeps ecommerce humming as the company continues to expand: PayPal’s net total payment volume for 2007, the total value of transactions, was $47 billion, a gain of 33 percent year over year.
To put that in context, PayPal’s net total payment volume for fourth quarter 2007, $14 billion, represented nearly 12 percent of U.S. e-commerce, and nearly 8 percent of global e-commerce.