We need to be careful while discussing localization of services in the cloud because the term localization is used with various forms and meanings here. In the cloud, it is being used for hardware and data localization, as seen in the phrases “localization requirement” and “localization rules.”
For example, in the Journal of International Commerce and Economics article “Policy Challenges of Cross-Border Cloud Computing,” Renee Berry and Matthew Reisman note that “Cloud providers have expressed concerns about ‘localization requirements’ that compel firms storing and processing data for clients from a given country to locate the data in that country. Governments typically create such requirements for the ostensible purpose of keeping data private and secure. Localization requirements are problematic for cloud providers, as ‘location independence’ is a core aspect of the cloud delivery model.”
These are complex rules; think about Gmail, Hotmail and other e-mail services. Think about online banking and other financial services. Think about cloud services used by the governments. Berry and Reisman have a good point: we (the providers) need to think about where we process and store data.
On a broad scale, this localization definition becomes part of our own localization definition. Localization is the process of adapting a product and accompanying materials to suit a target-market locale. We already know that this can include translation of a user interface and other similar content.
But all this leaves us with another question: how can we select the right languages we need to localize our cloud services?
Let us think about the cloud. There’s no need for shipping or even a download. All you need is to set up your browser or a specific client, connect and you get the service. Location? Region? No need to worry yourself. It is a global service. Well, this is the dream, anyway — one globe, where we can access services everywhere, no matter the region, the languages or the culture. But we are not there yet.
We can also think about the cloud as a paradise for startups. You develop a new service, and your market is unlimited. But here is the caveat: if we are trying a new service, why expose it to all the markets? Why not choose one market, check the service, check the concept, change it where needed, develop it, and once you feel it is ready, add more markets depending on a clear marketing model? It is tempting to try to sell or market the service to the entire world, but as it is written in my e-mail signature, it’s better to “Think big. Start small. Move fast.” Think about the dream, and about how your service can be used all around the world. Start small, in one market. Move fast, to new markets, once the service is ready. That includes ensuring that your service is well internationalized and is ready for localization, so the localization process will not take a significant engineering effort. Be sure to have the right integration with other services.
Assume I convinced you, and you are developing a service starting with one market. Should you let everyone access the service, even from other markets? What will the user experience be if the service is not localized (and worse than that, not internationalized) to the user’s market? What will the marketing effect be on your service?
In many cases, you should consider blocking users by region (IP blocking). Give access only to users in the market where the product is localized. Question: how many of you have a subscription to Netflix and tried to get Netflix services while traveling in another country? Due to content distribution agreements, Netflix is blocked in certain regions. We have other cases where a service is localized to many markets, but not all features have support in all markets — such as search, for example.
Once your service is successful in one market, what are the next markets? What are the next languages? Good questions. Tough answers. It is all about marketing and partnerships, as well as your user base. The good news is, unlike box products, there is no real need to have simship of the product to all new markets. Start small, move fast! Once your service is localized to a market, please remember: new releases of updates and features should happen frequently. Not every 18 months — quarterly, monthly, weekly and maybe daily. Clearly, you might decide not to release all languages in the same release. Get used to that!
