What makes a digital product world ready? My list of ideas to influence developers to think about localization from day one

I can't remember how I survived a few years ago without as many series/movies platforms as I have now (#First-world problems).

The truth is that nowadays, between Netflix, HBO, Disney +, Prime video, Apple TV, and Movistar, I have more offers than time to watch their content. Still, I like to relax when I have some free time watching a good series or movie.

Last night I made myself some butter-flavored popcorn, grabbed my blanket, and curled up on my couch to watch a movie.

The Infiltrator. 

As the name makes clear, this movie is about how in the 1980s, Robert Musella became the backbone of money laundering for drug kingpins. He was in charge of setting up businesses with the mafia to gain the trust of the international underground universe of bankers who backed him.

However, Robert Musella was, in fact, an infiltrator.

The character masquerading as Special Agent Robert Mazur (played by Bryan Cranston, the unforgettable Walter White from Breaking Bad, one of my all-time favorite series) infiltrated the world's largest cartel and discovered how far the organization's influence had permeated society. 

Infiltration must be a thrilling activity!

The adrenaline of getting caught or not.

The tension of living on a tightrope.

The number of things to learn while undercover!

Plus, a well-executed infiltration offers multiple opportunities to influence and persuade the gang we infiltrate. 

So while I was enjoying the movie, an idea came to my mind that is the central argument of this post.

If I had to infiltrate any gang (aka, team, stakeholders ...) in the software development world ... which gang would I infiltrate? 

And after thinking about it for a while, I thought I would infiltrate the ... developers gang (team)!

Why?

I'll explain it below, but the idea revolves around being able to answer the following question.

What makes a digital product world-ready?

And for that, I would infiltrate among the developers, understand how they work, what is important to them, what motivates them. And after gaining their trust and knowing what motivates them, I would find a way to motivate them so they see how important and necessary their work is to create products ready to succeed globally.

Because to make a feature, app, web page ... world ready, developers and internationalization tasks are key.

But of course, developers are often very busy.

They have a lot of things to do, so the last thing they want is for us to come and ask them to integrate the Japanese font and to please take into account that they must create the auto-expandable buttons to adapt to the length of the different strings that we are translating.

This is where motivating them after infiltrating me takes center stage.

Below is a list of some tips summarizing the areas that I need the developers to understand while infiltrating .... 

I have also created an infographic that summarizes all the tips to motivate developers to create global products from day one!

Designing world-ready products. My list as the Globalization infiltrator



View fullsize

Coding for world-readiness may have an impact upon implementation across the entire product. 

Use unique key names

Regardless of the developer's product and that the localization team is translating. Everything can be summed up as follows; there will be a key with a string to translate 

Make sure to give it a unique and descriptive name, for example, welcome_message, continue_shopping, edit_password

These are good names for your strings.

Add notes to your keys

Nowadays, it is pretty common to have TMS/CMS where we can add notes to the keys we are creating; in many cases, modern TMS allows attaching screenshots and a multitude of reference file formats.

A developer may forget that a translator does not have the exposure to "breathing the product" all day. The notes are the lifeline for a translator to know how to deal with cases such as:

• Part of a key that does not need to be translated.

• There are variables in the key

• Double meaning of the text to be translated, i.e., table, furniture, or grid of data

• Gender considerations

• Max length of the UI that the translations can occupy

Don't hard-code dates, times, measurements, and currencies.

Each country (translator) will have a different way of dealing with keys containing numbers or dates. The grammatical structure of the localized versions will be different from English, and the keys must be flexible enough to allow the localization of each language to follow its own rules.

To create such flexibility, the key must not hard code date formats

 27.05.2021 or 05.27.2021? 

When writing code, developers should always keep in mind that countries use different date and time formats all over the world.

Split sentences

Splitting sentences will rarely work when localizing since the grammatical structure is different. 

For example 

• The requested database is not available.

• The requested database is invalid

• The requested database is up to date

We could approach this coding by something like: The requested database %status and then substitute that variable with the relevant status in real-time.

This approach presents the risk that languages with grammatical structures different from English will not display correctly. Don't use the same string variable or sentence fragment in other contexts. Each term or sentence fragment should have a single meaning.

Use Unicode/UTF-8 encoding for your keys

Unicode is a character set standard used for displaying and processing language data in software applications. The Unicode character set is the entire world's set of characters, including letters, numbers, currencies, and symbols. Text is one of many assets that computers store and process. Text is made up of individual characters, each of which is represented in computers by a string of bits. Unicode is a standard, and the good thing about having standards like this for text processing is that it reduces the time needed to develop software and the associated software costs,

Make sure to store strings in resource files.

Externalizing all translatable content and putting it in a resource file is an excellent habit to get into.

It will avoid code duplication issues and allow translators and developers to work simultaneously.

Don't embed text in graphics

When text is embedded in an image, it means that the image and the text cannot be separated because the text has been saved within the image. And that goes against the previous tip of having a separate file with all the text! 

Ensure you have room for text expansion

It is said that localized text can be about 30% longer than the English version. In some languages that we localize, that percentage may be less or more for a specific word. For example, notice how different the spacing of a key that appears in a "View" button is from its Italian localized equivalent "visualizzazione". If you don't consider language expansion when you're designing your app, you may find that you have truncated text all over the place once your content is localized. 

Word order

Don't concatenate strings to form sentences. Each language has different grammar rules and word order will vary.

 Shortcuts and international keyboards

Evernote is one of my favorite applications. I use its shortcuts a lot to run certain features faster.

And one of the things I like the most is that it lets you customize your shortcuts. It is essential to avoid using keys and symbols for shortcut combinations that won't work for international keyboards. In my Spanish keyboard, I have the Ñ key, which is a source of countless localization bugs. 

Pay attention to the sequence of images for languages that read right-to-left.

Arabic is one of the most popular right-to-left languages that we localize. Why would you not want the UI elements to reflect this?

 Just as we change the orientation when localizing the words, it is also necessary to change the sequence of graphics.

Do not hard-code line breaks

A problem frequently arises when developers aim to achieve the necessary text layout via a hard line break. Where one sentence ends and another begins will not match in different languages. 

Allow space for larger font sizes

The fonts we see on our screens vary in size and height. Languages like Japanese and Chinese might need to grow taller specific elements of the UI. 

Summarizing

That approach that we often see in software development is that first I make the English version, and then, if anything, I localize it is an inefficient and much more expensive method. 

Preparing the code from day one, thinking that it will be localized later, is the best strategy to grow both in your domestic and international markets. 

And this elevator pitch is the one I would repeatedly repeat to developers in my work as an insider.

@yolocalizo