Localization at Cookpad

Cookpad is the largest recipe sharing service in Japan, where more than 60 million monthly users have posted over 2.5 million recipes as of Q4 2016.

Our mission is “make everyday cooking fun”. We are trying to solve everyday problems through cooking and technology.

Over the last 3 years, we have been expanding our service globally, and it’s now available in 16 languages and 60 countries. In this blog post, I’d like to share my experience of our Globalization.

Global product

Do we really need to localize our service?

We change feature graphics in Google Play by region even if in Spanish speaking countries.

A recipe cooked in Spain may not be as relevant in South American countries. If we use the same feature graphics in such countries, people may think “This is not a service for us”.

Many cultures and religions have different beliefs around food, so for example while we don’t show pork recipes in Arabic countries, we do show them in Indonesia but only when a user expressly searches for the term.

As we saw, each region has different ingredients, recipes, communities and cultures. We have to make our service appropriate in different regions.

How to understand local culture

The picture below shows the structure of local culture.

Local culture consists of 3 layers: climate (geographical features), folk culture (languages, traditions, religions, …) and lifestyle. Upper layers are based on lower layers and upper layers can be changed faster than lower layers.

Lifestyle can be changed fast. However, we could know the reason behind when we look at the lower layer. If you enter a new market, you should learn these things in order of climate, folk culture and lifestyle. And history tells us the sequence of changes.

How much should we localise?

If we have unlimited resources and time, we should localize our service as much as we can. But it isn’t practical.

There are 2 kinds of quality in Kano model: must-be quality and attractive quality.

If must-be quality is low, user satisfaction drops. But once must-be quality becomes higher than a certain value, user satisfaction does not change so much anymore. On the other hand, even if attractive quality is low, user satisfaction is not so changed. But the more we pay costs for that, the more user satisfaction is improved.

We should make sure what our attractive quality is (it can be a core concept of the service which is the reason why users use the service). And we should keep improving it while fulfilling minimal must-be quality.

Note that must-be quality and attractive quality vary by region.

Global development

What is Globalization in the first place.

Globalization consists of Internationalization and Localization.

In terms of web development, Internationalization is a process of designing a service so that it can potentially be adapted to various languages and regions without engineering changes. Localization is a process of adapting internationalized service for a specific language or region by adding locale specific components or text. Translation is a part of Localization.

Let’s say, there is a phrase “こんにちは” (Hello in Japanese). Replacing it with id: hello instead of hardcoding "こんにちは" is Internationalization. Adding "Xin chào" (Hello in Vietnamese) for Vietnamese is Localization.

Globalization is the whole cycle of Internationalization and Localization.

Locale

Locale a set of language (ISO 639) and region (ISO 3166). It’s important to identify the user’s environment.

As you know, language doesn’t represent country.

Even in English there are variations like British English (en-GB), American English (en-US), Indian English (en-IN), …

Besides, some countries have several languages in the same country. Spanish and Català in Spain for instance.

Search

Search is one of the most difficult things in global development. It requires understanding of each language and culture + steady exception handling.

In some languages, words are inflected by the gender. We need to deal with the issue to make input query searchable.

Sometimes we should ignore accents, but other times we shouldn’t.

Unicode can be changed depending on how a user enters it. We need to normalize such characters.

We need to check matching partially in languages which have compound words.

Spanish is spoken broadly. Spanish people and South American people expect different search results.

Japanese people use Chinese characters. Chinese contents can be matched when a Japanese user inputs Chinese character only query. When we serve Chinese contents for Japanese users, people can’t read it and don’t use the service again.

What we should do in search is think about what users really want to see.

Language and layout

Language affects UI. The common example is LTR and RTL layout.

We don’t only flip the layout. We also make font size slightly larger for Arabic.

Besides, in our service, we previously displayed rice image as a placeholder. But we changed it to more common ingredients like chicken (pork or beef can offend in some cultures).

Of course, each language has different formats.

Translation

Actually, translating phrases “correctly” is difficult.

For instance, “OR” can be “Oregon State” and “A or B”. Both are correct until the context is given.

There is a good example. Kindle used to display “Move to library (Oregon State) Continue shopping” instead of “Move to library (or) Continue shopping” in Japanese. In this context, “or” is correct.

Good translation needs context and communication.

Choosing appropriate word is also difficult. Amazon changes the name of paid service (Amazon Prime) depending on the region. In Spain, the name is “Amazon Premium” because “Premium” can be interpreted as “Expensive” in English speaking countries.

After translation, we should check how it works before release. Sometimes it could cause problems.

Translation is a process of making the feature work in different regions. We need a system which can improve translation continuously.

Global team

Members are in different timezones and have different backgrounds.

Hangout meeting

Each region has different problems. Even so, we have to prioritize tasks and go in the same direction.

For everyone to get on the same page, we have adopted OKR for setting and communicating goals and results.

By sharing OKR between members, we can get tasks done even if members are in different timezones because your task can be my task.

We also have adopted lean development.

Cycle of Build => Measure => Learn

Building services for people who live in countries where I have never been can be difficult. I always feel “I haven’t understood users properly”

For that reason, how fast we can deliver/fail is a key to success.

Developing fast doesn’t mean delivering broken features. Quality of features should be enough quality to validate. Delivering validatable features fast while keeping quality requires high development skill.

Anyway, product, market, team, development, … everything could be changed at any time. We have to keep reviewing the current workflow and keep improving it as necessary.

Conclusion

This blog post is the translated version of this talk (Japanese) in Cookpad Techconf 2017.

Actually, this is not all. There are many other challenges in this project. It’s difficult but definitely exciting!

We’re looking for people who are interested in solving problems through cooking and technology 😉 (Open Positions | Cookpad Inc.)