Taking on the World By Going Local, Part 2: Localization Myths

In Part 1, we discussed why we are tackling localization of Cognito Forms now, and why we initially chose to wait. In Part 2 of this series we will dispel three myths of localization, highlighting the great diversity of our world and the importance of embracing it.

Localization Myth 1: Localization = Language

You might think that simply changing the text on our forms from English to French would be enough to make our forms palatable to a user from France. This is the tact used by a lot of web software developed by US companies not interested or not aware that cultural and communication differences between countries are much more than just language.

Dates Are Different!

Dates in the United States are formatted as MM/DD/YYYY, but in most other parts of the world they are DD/MM/YYYY or DD-MM-YYYY or DD.MM.YYYY or even YYYY-MM-DD. To someone in another country filling out a form designed for the US, they may inadvertently enter 10/12/2014 thinking this would be December 10, 2014, only to discover that in the US this would be October 12, 2014.

What Time Is It?

Times are tricky too, with some countries using the 24 hour clock, some using AM/PM designations, some in the front, some in the back, translated by language, etc. 3:42 PM in the United States is 03:42 Maitseboa in Botswana, 15:42 in Japan, and 3:42 in Singapore. Also, everyone knows that time is a relative thing around the world, so 5:00 PM on the US East Coast is 2:00 PM on the US West Coast, and let’s not forget about daylight savings time with varying rules around the world. People like to see times in their time zone and a format they understand, and inconsistencies here can cause big headaches.

1.000 + 1.000 = 1,000,000?

To developers like us, numbers are numbers, with floating point numbers getting their name by the period acting as the decimal point for fractional numbers. However, in lots of countries commas are used as the decimal point, spaces often replace commas as the thousands separator, percent signs are sometimes at the beginning of numbers, and the list goes on and on. What would someone in Greenland make of a payment amount of kr. 12.34? Would they think it was 12 and 34/100 Danish kroner or would they interpret it as 1234 because periods are used as thousand separators in Greenland?

Money Matters

The same variations apply to currency, which is much more than just a selection of a currency symbol. Different currencies have different numbers of decimal places they support, and in some cases currencies that officially and historically had decimal places in practice do not now due to inflation and real usage. Currency symbols sometimes proceed the number and sometimes follow. In Italy, ten thousand euros would be € 10.000, while in France the same amount would be 10 000 €.

Call Me

Phone numbers generally are just that, numbers. But as with dates, time, numbers and currency, they are data and we want them to be correct. However, phone numbers are different in every country and therefore extremely difficult to validate. Google has a solid library for phone number validation that highlights the complexity of validating phone number input in different countries.

Localization Myth 2: Localization Affects Data, Not Structure

Once you accept that localization includes not just translation of words, but translation and formatting of all user input, you then run into the next myth—that localization only affects the data in a system, not the structure and layout of the information. However, this quickly breaks down when attempting to collect structured meaningful data.

What’s Your Name?

Names seem at first glance to be simple enough—first and last usually suffice, with a sprinkle of titles, middle names, and suffixes to round things out when necessary. However, cultural differences abound when it comes to names, and what we assume as universal by growing up in a Western culture must be thrown out when seeing things through a world view. For example, the practice of having the “given” name first and the “surname” or “family” name last is a Western concept, and is inverted in the rest of the world. In some cultures names may have well more than five parts and are not as tightly structured. Sure, names can always be stuffed in boxes in some way, shape or form, but is important to collect information is a way that is comfortable and respectful of local norms.

What’s That Address?

While names are challenging, addresses are brutal. The simple formula of street-city-state-zip in the US is easy enough, but the structure, including the name, number, type and order of fields, is different in every country and in some cases different within the same country. Add to that the fact that users appreciate having lists to choose from for states, regions, countries, territories, etc.—in their native language—and the complexity just keeps growing. Check out this post on UXmatters, for more insight into addresses on forms and different approaches.

Right to Left?

In some countries and cultures, the tried and true left to right and top to bottom reading order for documents is put in front of a mirror and becomes right to left and top to bottom. This affects more than the ordering of words, but means that the most important information for users should be on the right and content should naturally flow to the left. Labels and text align right, fields with natural sequence, like name and address, are positioned right to left, etc. This again is a structural difference that greatly affects the ability of users to understand and effectively interact with online forms.

Localization Myth 3: Localization = Internationalization

Unfortunately, the last myth is in some ways the hardest to overcome—internationalization and localization are not the same thing. The distinction is elegantly described by Christian Arno in his post Internationalization vs. Localization, What’s the Difference? on CMS Wire. The key difference is that while we can internationalize Cognito Forms to support many countries, cultures and languages, each form must be localized for a specific country, language and culture.

No matter how much we do to internationalize Cognito Forms to support all of the countries and languages of the world, our customers will still be responsible for localizing their forms to support their customers. As long as only one country and language is required, then no problem—just enter labels, helptext, email messages, etc. in the appropriate language and the form will work perfectly, like they do today. But creating a single form that supports multiple localities and different languages is dramatically more complex, because almost every setting involves entering text that the end user will see at some point in the process.

Conclusion

Now that we have dispelled these three myths of localization, you can see that these myths are all based on underestimating the complexity of the problem. Internationalization and localization is really hard when properly addressed!

In Part 3 of this series, we will describe in detail what we have done to support localization in Cognito Forms, including some of the great technical approaches we employed to solve this complex problem.