Localisation

A direct translation is not localisation, and vice versa. Content can be localised even if it isn't translated. For example in India, our product is in English, yet parts of the content are localised to fit the needs of that specific market.

Localisation means that you understand the intent and local culture, and adapt the content to fit.

“Internationalisation is a set of best practices (mostly in engineering, design, and operations) that make it easier, faster, and cheaper to localise a product or service at scale. By removing all locale-specific elements from a product’s design and code, it becomes world-ready.” —Airbnb design

For example, design and build have to be adaptable to different currencies, date and time formats, right to left text direction, and variable text length, depending on the language.

In order to effectively localise (i.e. choose the style, formatting and language to fit the local market), we must first make sure our build is internationalised.

👍 Rule of thumb: in countries where we use the same brand positioning (e.g. Live more, Bank less), we should use the same brand voice.

In markets where our product positioning differs, the voice is also localised to fit with the different product proposition. For example digibank India follows the WITTY tone of voice, which fits with its challenger positioning.

→ Read the WITTY guide

A note of caution: think very carefully before coming up with a new ‘voice and tone playbook’ that differs from the regional DBS Live more, Bank Less voice and tone guidelines. Custom guidelines are cheap to dream up and expensive to actually implement across our apps and other properties.

👍 Rule of thumb: we localise terminology, taking care to be consistent across the same market.

Often, different countries will use different terms to mean the same thing, even when the language is the same—just look at US and UK English. There are also differences in measurement units, currencies, and time formats.

👍 Rule of thumb: If using emoji in a culture that you are not familiar with, check with a local.

Emoji—so small, yet so significant. We use them where they feel appropriate, and this can vary from location to location.

Take the extremely common thumbs up gesture: Always a sign of agreement, right? Not so in the Middle East and in Russia, where it is considered rude.

→ Other gesturing emojis to avoid

For emoji skin tone, stick to the basic yellow. ✌️😄 😜

👍 Rule of thumb: yes, please, localise!

That’s the job of localisation. Not to tell a brand new story but to show your audience you have thought about them. And when appropriate you’ve adapted for them.

👍 Rule of thumb: localise when there's a real need.

Our regional standards are tried and true, and they're made to work for our products. What’s more, customisation always comes with a price tag. Ask yourself: does this change significantly improve the ease of use of the product?

At DBS, we are progressively rolling out a translation management system called Lokalise.

Lokalise is useful when:

• Your project covers more than one country and/or more than one language
• Giving content to tech in Word/Excel is not working out (bugs, version control issues or developers simply tired of copy and pasting stuff)
• Our delivery team is tired of changing JBs every time a label changes
• You need a long-term, scalable translation management solution
• You want real-time (over-the-air) updates without the need for an app release in post-login environments and/pr mobile apps

Updating labels should not be a big deal. We need flexibility to do it in near real-time for all our digital properties.

Simple content updates should not need to go through a development cycle and an app release. That is why we are in the process of rolling out over-the-air updates for our mobile and hybrid apps and post-login environments.

Get in touch with the DLS or Frontend Studio team (we are working on this together) if you want to find out more.

See the high-level process here.