What does localization mean? Localization is a process that helps a company meet the needs of a country, language, culture or desired population’s “look-and-feel.” Ultimately, the goal of localization is to adapt an experience for customers in other parts of the world.
When you localize something, you’re adapting a piece of content, a product, or a service in order to make it work for a customer from a different market, or who might speak another language. As your company localizes, you might need to adapt multiple elements of a customer experience in order to meet the needs of a target market, including:
- Modifying visuals, graphics, and color schemes to meet local needs
- Changing, adding, or removing content to make it more relevant to local audiences
- Adapting meaning and messaging with translation
- Showing respect for local culture and understanding of local customs
- Converting amounts and numbers to local currencies and units of measurement
- Using locally appropriate formatting for elements like dates, addresses and phone numbers
- Addressing legal requirements and local regulations
- Modifying user interfaces and displays to accommodate local dialect
Localization is vital for most companies when they undertake international expansion. Here’s a list of 27 examples of things to consider during a localization process, so that you can easily understand how to define localization yourself and in the work you do at your company. Following these basic guidelines will help you more easily understand what localization means, and how to localize, so that you can provide an equitable experience to your users, regardless of their country or language.
Key Points for Understanding Localization and Related Terms
There are many different terms used alongside the term localization. Here are some key things you should know about the topic:
- The term localization actually comes from the term locale, which refers to the combination of the language a user speaks and the place they are from. So, localization is really just a fancy way of saying “making something appropriate for a given locale.”
- Locale is the combination of a country and a language. For example, en-US means English for the United States, while fr-FR means French for France.
- The term is spelled localisation with an “s” in British English, and localization with a “z” in US English.
- Localization and translation are not the same thing, but are often confused with each other. Translation entails adapting a message (not just words) from one language into another.
- Internationalization is also different from localization. It’s a step that helps enable something to be localized. Internationalization refers to making adaptations at the coding layer, so that localization can happen in the first place, especially for software, web-based, and mobile app experiences.
- A related, bigger-picture process is globalization. Globalization is the process of taking an entire business global, by adapting an organization’s underlying frameworks and mindset.
- There are some common abbreviations used in the everyday work of localization professionals. Here they are so you’ll know what they mean if you see them: Localization = L10N, Internationalization = I18N, Globalization = G11N, Translation = T9N. These abberviations simply include the first and last letter of the word with the number of letters in between them, and are known as “numeronyms” (acronyms that include numbers).
Here is a simple table that make it easy to define localization, and understand how it differs from related processes.
| Process | What Gets Adapted |
| Translation | Message |
| Localization | Experience |
| Internationalization | Code |
| Globalization | Framework |
Just localizing something, unfortunately, is not sufficient. If you’re working at a company that wants to undertake localization, it’s also important that you know what success with localization looks like.
| Process | What Success Looks Like |
| Translation | The message resonates with other markets. |
| Localization | The experience delights customers in other markets. |
| Internationalization | The code works in other markets. |
| Globalization | The framework is inclusive of other markets. |
Now that we’ve covered the basics of how to define localization and related terms, let’s take a look at some examples to make it even clearer.
1. Assume text will grow or shrink.
Some languages, like Spanish and German, might require about more space for your text, in terms of the number of allowable characters.
Languages like Japanese and Chinese might require fewer characters. I generally suggest that your layouts in English allow for up to 100% more text in other languages as well as 50% less than English.
The amount of text expansion or text condensation you need to consider depends greatly on what type of content it is too. If it’s a label or menu item that might be only one word in English, just know that it might take 4 or 5 words to say the same thing in another language. Or, it might take the same number of words but they might simply be longer. Generally, the smaller the number of words in English, the more you’ll need to allow for text expansion.
Otherwise, the text will most likely be truncated. See the example below, which shows the remaining text that won’t fit onto the button, meaning that the user can’t see it.
This phrase takes only 7 characters in English, but 12 in German and 18 in French. And there are examples in which German takes more space than French and so on. This is why it’s important to build with flexibility in mind.
Why does this matter so much? One of the problems I’ve noticed over the years is that when translators face this challenge at the translation phase, and they don’t have enough space to fit a good translation in, they are forced to either keep the term in English, or use a word that doesn’t really make sense. Either way, it’s a bad experience for your users.
In fact, if you don’t design in a way that accommodates this, you might be actually be contributing to language decay in some languages by forcing them to adopt terms in English that are less accessible to the majority of people. Basically, when we do that, we’re often imposing our English-centric norms onto them, and not allowing their own culture and language to shine. Worse yet, you might be really limiting your potential user base to just those who can understand English terminology.
2. Allow for larger font sizes.
While some languages might require fewer characters, some languages actually need larger font sizes. In other words, if you’re designing a button on a page in English, you might find that when it goes into German, it needs to grow wider, but for some languages like Japanese and Chinese, the same box might need to grow taller.
I’m sorry, I know it might be harder to design this way, but if you can allow your text boxes, buttons, and so on — basically anywhere that text might appear — to be flexible to accommodate the reality that languages are different — you’ll thank me later when users all over the world are raving about how well designed your experience is, no matter what the language!
3. Separate text from images.
This means absolutely no images with text embedded in them whenever possible. If you can create a “translatable” layer of text that can be overlaid onto the image, using CSS or some other method, this will make everything so much more localization-friendly.
This is actually super important. When you go to localize your content into another language, if the images have text in English in them, it basically tells the user that you designed this experience for someone else who lives in another country and speaks a different language. It can make them feel like a second-class user, one who gets a lower-quality experience.
4. Make image files easy to swap or hide.
While it would be great to separate text from images in every single instance, that isn’t always realistic. There are times when you need to show product screenshots or charts and you simply won’t be able to have every single bit of text on the image extracted from the images.
What can you do in these cases? Ideally, when you take screenshots, you take the same ones in every language your UI is available in at the same time. Or, you write two versions of the same content, one which references the image, and one that doesn’t. Basically, you’ll have to have a plan for how to swap those images out — or hide them — depending on which language and country you are targeting with the content.
5. Make image source files easy to access.
One more note on image files. If you’re creating them in some sort of design software, make sure you not only give your localization partners access to the “final” file in the image format, but the source files too in your design software (like InDesign for example). Or, if you are using an online design tool (such as Canva), you might need to provide access to enable the images to be recreated in other languages.
As for the decision on when to swap and when to hide, you don’t need to make that decision at the design or coding stage. You’ll just want to keep in mind that if you’re putting in images where the text can’t be extracted, that you might later need to swap or hide, and design accordingly to enable that level of flexibility.
6. Resource your strings.
Ideally, string externalization, which is moving the strings from the code into resource files, becomes part of your company’s ongoing development processes. If not, it can be so time-consuming and difficult to do later on that your development teams simply will not agree to do it. It will become a cost-benefit discussion, and it will be hard to make the case later on that you should refactor your code in order to make it localizable later.
To prevent all that unwanted re-work, don’t put development teams in this negative position. Make it easy for developers to externalize their strings and get them into resource files from the start. The more you can operationalize it as part of something that just needs to happen before code gets deployed, the better able you are to build a truly global-friendly development process.
There are plenty of options for appropriate resource file formats, such as JSON, XML, YAML, or gettext. There is usually a de facto standard format that depends on the framework or programming language you’re using.
What happens if you avoid this critical step? If strings don’t get externalized, they just can’t be localized without writing additional code. This means that any hard-coded strings will show up in their original language, no matter what language the user speaks.
You don’t want to send a negative message to the user. Yet, the lack of localization-friendly development is a big reason why elsewhere in the world, lots of US software companies have a reputation for creating US-centric software that falls short in other markets. You don’t want your company or your developers to have that kind of reputation. But more importantly, you don’t want users to have a bad experience.
6. Consider implementing a pseudo-localization step.
One of the most popular techniques for automatically checking for string externalization is something called pseudo-localization. In this process, you convert all characters in your application to another language, ideally using a different character set, even if it’s just machine translation, to ensure the entire process can work from end to end.
The point of this is basically to test out your code, build, and CI/CD process, to make sure they can support localization — before you actually invest in doing it for a release in other languages. This is quite simply a method you can use to identify challenges you’ll encounter with user-facing strings later when you decide to localize, to prevent you from committing code that might later be hard to refactor.
With a pseudo-localization process, you essentially transform the resource files written by your developers and display what will happen to the strings when you pass a specific locale (a fake one) is passed to the application. Pseudo-localization will help you in many ways. It can help you flag concatenation issues.
Also, I find that many developers love the idea of pseudo-localization because they get to see what their product will look like from the perspective of another language while they are building it. It opens up their eyes to the possibilities of what their product will someday look like in Japanese or Finnish or Arabic. And, yes, you can even choose invented languages, like Dothraki or Klingon. I am all for whatever will get people to actually look at it on an ongoing basis! No matter what language you pick, I do recommend you throw in a few Japanese kanji characters into the mix while you’re at it just to ensure you’re testing to ensure the encoding works as well as the character sets.
There are also some commercially available tools that will automatically pseudo-localize all of your resource files every time you make changes to them, or on a certain frequency that you can specify (daily, twice-daily, weekly, etc) depending on your needs.
7. Check for garbled characters.
Another great thing about pseudo-localization is that you can use it to check for garbled characters, which are also known as mojibake (文字化け). This word is often used in English by localization professionals, but it comes from Japanese, because as you can probably imagine, Japanese users are the ones who happen to see garbled characters like this pretty frequently. So of course they created a word for it! Mojibake is the end result of when symbols are replaced with unrelated ones systematically, usually because the target character set is not supported.
If you have garbled characters, chances are that your text is being decoded using a character encoding that was unintentional. If you see a generic replacement character, like (“�”) show up in various places, it’s probably because the binary representation is considered invalid. This typically results from differences in encoding.
8. Train developers to consider multiple locales.
What you’ll start to realize as you gain experience with internationalization is that you’ll need to get developers to avoid creating programmatic functions and patterns that are built around just one locale. Building something this way is something you might call a “locale-limiting architecture” or “locale-limiting design.”
Some might even call this way of building a product “ethnocentric,” which implies that a developer believes their own country and language are the center of the universe. Most developers don’t actually think that way — and in fact, a huge number of them have international backgrounds themselves! But, when they are building a product, it makes total sense that they think about the user and the use case with English (often American English) as the default. That’s user-centric design. And that is where they usually take the first steps away from creating “global-ready” code.
This type of “anti-global” development could be considered “locale-centric.” It basically means that the development team isn’t considering use cases from other countries and languages while they are building it. And for product teams where localization is an afterthought, that makes it soooo much harder to take a product to the world!
The barrier I always hear from developers’ point of view on this is that building a global-ready product is a form of “premature optimization.” In reality, it’s smart economics. You take small steps today to avoid blowing your chances of giving your product the ability to succeed globally later. It’s a small up-front investment, for huge dividends later on.
It’s like maintaining fast, reliable, automated tests and writing highly maintainable code from the start. Developers already optimize for the future by adopting clean coding practices and maintaining their work according to programming language standards. Internationalization should be no different.
9. Make sure your database schema supports international variants.
Often, even if the code itself – and even the database technology itself – can support an international use case and the strings can be localized, the underlying database schema might not. This can be very tricky, and is a good reason why it’s helpful to consult with localization professionals at the earliest stage, ideally, when you’re conducting UX research, and before the first line of code gets written. Or, if you don’t have access to any, talk to international customers — early on during the design phase.
If you’re building many features and functionality that will leverage a database, you need to ensure that the database itself will accommodate use cases from more than one country. Sometimes, there might not be any need to change your database structure. In other cases, simply adding a few fields to it can prevent you from doing a huge amount of re-engineering work later on.
A typical example is a database that will display a field to users in one language, but the field itself was built in a way that it’s not possible to display multi-language variants. When this happens, localization simply isn’t possible. It’s blocked by the database itself! So, it’s helpful to think about the international use case, including how your database will be used, while you’re designing the experience. Remember, pseudo-localization will help you catch these issues.
10. Use standard and consistent file structures.
You can make localization much faster and easier if you use standard file formats (Java properties, XML, .NET resx, and so on). If you work in a custom development scenario, you can at least use a consistent, standards-based file format such as XLIFF.
Localization teams love standard file formats like the ones listed above. Their translation management systems can easily ingest them and process them, so that the localized output also works. If you do this, you’ll be saving yourselves tons of re-engineering, and you can bypass much of the QA work you’d otherwise require. Bottom line, if you want expensive, time-consuming, and human-centric localization with tons of human testing requirements, go ahead and use any old file format. 😉 But if you want to speed things up, standard and consistent structures are the way to go.
11. Avoid “outgrowing” your third-party dependencies.
It’s increasingly common to use data or functionality provided by a third party that displays within a web page or product. Unfortunately, unless you think to ask about which languages and countries are supported by third-party services, you might be wedded to them for a long time, leaving your international users behind in the process.
Then, if your international user base expands faster than theirs does, you’ll be limited in which markets and users your product or website can actually support. Make sure to ask all third-party solutions that are part of your product or web experience which locales they support. Make it part of your technology investment decision and procurement process.This way, you can design things in a way that enables you to swap out the provider where needed for a local option.
Or, perhaps you flag to users that certain functionality won’t be available to them, or avoid exposing it to them if it simply doesn’t work for their market. While that’s not a great or equitable UX, being honest and transparent about what you can support is better than surprising them or disappointing them. Either way, you’ll want to track this information early, so that there are no surprises later.
12. Make it easy to find strings.
Imagine a conversation with your localization team that goes like this:
Localization: “There’s a $ symbol sitting outside a string that’s hard-coded, and we can’t replace it with the British pound.”
Engineering: “OK, where is it?”
Localization: “In the Product UI.”
Engineering: “What line of code?”
Localization: “It’s on the Payments page.”
Engineering: “Which string?”
Localization: “Umm… and how exactly could we find that out?”
…
Now, imagine that the conversation went like this instead:
Localization: “There’s a $ symbol sitting outside a string that’s hard-coded, and we can’t replace it with the British pound. The string ID# is SH472922.”
Engineering: “Pull request submitted with the change. Thanks!”
With older development processes, new strings had identifiers on them, or someone would manually add them prior to localization taking place. This way, strings could be easily found within resource files in repositories. This made it possible to move files back and forth for translation while ensuring the translations were applied in just the right place.
Unfortunately, for any team doing continuous development, this process can be a nightmare. Ideally, you’ll need to find ways to add unique identifiers to the strings as you localize them. The best way to do this is to automate the process, but this isn’t very common, unfortunately. It also might require an integration with a translation management system.
13. Don’t lump too many strings together.
Separate strings out and avoid batching them together (known as concatenation). Otherwise, localization bugs almost inevitably will follow, and can be time-consuming to fix.
You’ll especially want to be on the look-out for strings that have modifiers. In English, the noun usually comes after the modifier (“red house”) but in many languages, the noun goes before the modifier (“casa roja”).
Don’t break strings apart into pieces that are too small, because this can make it very hard for a translator to have the necessary flexibility later on. Instead, where possible, use placeholders that the translator can ideally work around.
14. Put all punctuation inside strings.
Even if you’d like to re-use a string later with different punctuation, avoid putting the punctuation outside of the string. Why? Different languages have very different rules about punctuation and spacing. When the string gets resourced, you’ll be forcing the translator to use punctuation that might not actually be correct in their language.
This is yet another example of concatenation issues that will cause localization bugs later on. More often than not, the translator won’t even see that this issue exists, because your string won’t show up to them with the surrounding punctuation. So, if you don’t put the punctuation marks inside of the string, you might not even realize there is an issue until users start complaining later.
The golden rule: consider punctuation part of the string, and put it in your resource file, always.
15. Avoid hard-coding currency, time, and date formats.
The world is a wildly inconsistent and complicated place when it comes to time and date formats. Consider that there are 11 different time zones in Russia alone. Not all time zones map squarely to the hour, either. Newfoundland is GMT-2:30, and Nepal is GMT+5:45. Daylight Saving Time begins on completely different dates in Europe compared to North America (see this great article on Daylight Saving Time and time zone best practices.)
Time and date formats are complicated too. Some people put the month first and others the day first. Some use a 24-hour format that Americans consider military in nature, while some use 12-hour splits. Some use AM and PM and others do not. In some countries, they even number the weeks (1-52) to refer to them this way in their calendar apps.
And, let’s not forget that the concept of a “weekday” varies, since some countries take Friday and Saturday off while others take Saturday and Sunday off. Also, the week starts on Sunday in the US, but on Monday in the UK.
Currency is tricky too. There are 20 different “dollars,” around the world, such as the ones used in Australia, Canada, Hong Kong, Singapore, Taiwan, and many others (not just the United States).
Here are some standard formats and libraries you can consider using:
- Standard formats: ISO time, epoch time, or UTC to store them
- Libraries: Date.js or Moment.js will format them for you for each locale and convert to the right time formats
16. Take into account diverse ways of ordering names.
When you consider every country in the world, the number of possibilities with personal name ordering is pretty astounding. In reality, even the notion of a “First Name / Given Name” and a “Last Name / Surname” is pretty anglo-centric in nature. For that reason, it can be confusing when translated, and might not refer to the same thing depending on which country you’re referring to. This can lead you to ending up with a database full of “first names” that are actually “last names” in some countries, and vice versa. Below are just a few examples.
| Place | Typical Name Format |
| English-speaking countries | Given Name + Family Name |
| Spanish-speaking countries | Given Name + Paternal Family Name + Maternal Family Name |
| Portuguese-speaking countries | Given Name + Maternal Family Name + Paternal Family Name |
| Hungary, Japan, Korea, and many more | Family Name + Given Name |
For a really detailed look at name formats and the implication on designing form fields, see this article from Richard Ishida. His conclusion is that often, it’s simpler to just have a single field for “full name” instead of bothering to create so many different variants.
Of course, marketers like the ability to use people’s different names depending on the communication in question, so it’s definitely a topic that all form-builders and CRM users care about. To see various ways this is addressed for Spanish-speaking countries within a CRM, check out this (older) article on the topic.
Shopify also provides some helpful guidance on designing forms for international use.
There is a lot that goes into this topic! Who knew that deciding on form fields for names could be a controversial topic? Are you in the “full name field” camp, or the “locale-specific variants” camp? You’ll have to decide what’s best for the needs of your users.
17. Default to UTF-8 for character encoding.
Opinions definitely vary on this, but UTF-8 is usually a good choice for most situations. The exception is if you work extensively with Asian languages, for which UTF-16 will prove more efficient. For web applications, if the browser and server don’t share a character encoding, users will see character corruption in the form of annoying little question marks and squares. Using UTF-8 will standardize the encodings across server and browser. If you’re using the JSON specification, it already requires you to use Unicode with a default of UTF-8.
18. Use locale, not just language.
Often, people think about language first, but country also matters a great deal. The more international your user base becomes, the more it will matter. It can be hard to untangle country from language later on. If you solve for both, earlier, it helps prevent problems later on.
When you use a locale, you’re considering both the language and the region, which is usually a country code. There are many libraries designed to support the standard locales, so why not use them? If you specify locale, you have way more flexibility than if you use a language alone.
For example, let’s say you just specify “en” for English as your language code but you don’t take into account any regional differences. What if you want to display a price in GBP to British users, in EUR to Irish users, and AUD to Australians? You can only easily do this if you design for locale, so that you can leverage the locale settings to display the right currency without any need to change the language.
19. Put trust in the user, not the browser.
Browser language is not always accurate. While it can be helpful to enable a decent guess at someone’s preferred language, some browsers will allow you to select more than one language, in order of your preference. This way, users can see their top language first, followed by other languages they happen to speak if their top choice isn’t offered.
If you can, it’s best to let your user indicate their preferred language and country. That way, you don’t have to guess. You can store their preferences and default to those, versus constantly querying their browser language (or worse yet, their IP country, which can be even less accurate).
John Yunker does a great job of explaining the various options for language navigation in The Art of the Global Gateway, and CSA Research has some good reports on the broader topic of global online experience too.
20. Make it easy to change languages.
It’s extremely annoying, especially on a web page, but also within a web app, if a user can’t easily switch languages. Most of the world speaks more than one language fluently, after all. You can put your language picker (often a globe icon) on the top of your website or the bottom, but it really can’t hurt to put it in both places, so that it’s beyond easy for users to quickly switch languages whenever they wish.
Whatever you do, don’t use flags to indicate languages. If you do, which of India’s 22 official languages will its flag represent? And will Canadian users have to click on the US flag just to get English?
21. Avoid forcing users to switch languages.
Please, don’t force users into another language flow without their permission. It’s just not nice. Ideally, if they searched for you in one language, keep them in that language if you can, so long as you don’t block them from achieving their goal. It’s extremely annoying for users to click on something only to be taken to a page in another language.
If you can, let them know with a pop-up that the page they are heading to is not available in their language, and ask if they want to continue in the default language (such as English), for example. Don’t block them from reaching that page if it’s the only option. But also, don’t force them into a language they didn’t agree to see.
22. Take plurals into account.
Oh, English. You’re complicated in some ways, but we really take for granted how easy you make it to pluralize a noun! Because English makes it so deceptively simple, developers often build things in a way that overlooks how complex it can be to make nouns plural in other languages.
How to Make Nouns Plural
| English | German |
| Add -s or -es to the end. | Add -e to form a plural to most nouns that have one syllable, except in the dative case in which -en is used. Some nouns might also require umlaut changes. Add -er to create a plural for masculine or neuter nouns, except for dative case in which you add -ern. Also might require umlaut changes. Add -n or -en to form the plural no matter the case, for feminine nouns. Add -s in plural form, usually for terms of a foreign origin. Don’t change the ending to pluralize it, except in dative case where you add -n, may or may not require an umlaut change. Most of the time these nouns are masculine and end in -chen, -lein, -el, -en or -er. |
Let’s also not forget that in many languages, you’ll also have to pluralize not only the noun, but also the article that appears before it. In Spanish, “the” can be “la,” or “el,” (singular), but also “las,” or “los” (plural).
What’s a developer to do? Create the fixed part of the message and include a variable element (placeholder). Then, you can populate the placeholder using a plurals library.
There are many options, but you can do consider the following:
- Write the message in a way that is less dependent on plurals. For example, instead of saying: “we have 4 results that match your search,” change it to “results that match your search: 4”
- Format your string to cater for a range of values to cover different plural forms. This is more complex, because the number of ranges you’ll need to accommodate will be different depending on the target language. The Unicode Consortium’s CLDR, or Common Locale Data Repository project, may be helpful to you in this scenario.
23. Sort on the server.
If you’re using a sort function to arrange different string lists in alpha order, the browser might only be able to reference the sort order for the current locale it’s displaying. Make sure you handle the sorting on the server instead. Otherwise, you’ll end up using English alphabetical order to sort lists of words in Japanese, for example, which won’t make sense. And, the sort order won’t work for languages that have multiple versions of the same character with differentiation based on diacritical marks like ằ versus ã.
You’ll need to verify that the server supports all of your users’ locales properly with the relevant code mappings, so that when you send lists to the browser they are pre-sorted. This way, when you need to change the sorting, you’ll also easily be able to make updates.
24. Consider directionality.
There are 10 different scripts (used by 32 different languages) that go from right-to-left instead of left-to-right. Often, products are designed in a way that they can only support left-to-right languages, making it very difficult to ever support right-to-left languages, such as Arabic, Hebrew, Persian, and Urdu. Consider whether you’ll someday be offering your product in Israel or many of the Middle Eastern economies that speak these languages. The way you design your product and build it will be different if you plan to accommodate scripts that go in both directions.
25. Make colors easy to switch.
Colors have different meanings depending on the culture, and the connotations can be positive or negative depending on where you are in the world. Be mindful when you’re designing your user experience of which colors you use, and consider whether it might be appropriate to display different colors, or reduce your dependency on them, depending on which markets you are targeting. Obviously, you have to stay true to your brand, but you also want to make sure you’re not reminding people of something that’s negative in their culture, such as a specific political party that always uses that color in a given way.
For example, if you create a UX design that is red-white-and-blue, Americans, Brits, Australians and French might feel it’s a nod to their flag. Have you considered what flags your core colors look like, as one simple example of how color can create associations for people? It’s often not just the colors, but how they are used in combination with other symbols and messaging. Still, it’s good to make it possible to easily switch out colors so that you can do so if you need to.
26. Give context to your translators.
The worst thing you can do is hand off your strings with zero documentation about what they refer to, no screenshots, and a total lack of context. The translators who work on your strings are human beings, just like your UX writers are. Even if you do use automated translation somewhere in your process, it’s pretty likely that a human will review it at some point before it reaches your users.
While it can be tempting to “move fast and break things,” remember that what you’ll be breaking is the user experience if you don’t give your translators the ability to truly understand what you’re referring to. Screenshots are best where possible, access to the UI or draft web page is great, and if those aren’t possible, your notes would be just fine. When there’s nothing there, the likelihood of bugs is going to be much higher. And no development team wants to be associated with buggy code!
Remember too, “garbage in, garbage out.” The more time you take to enhance your notes to help translators understand what your strings are meant to accomplish, the more likely the translator can help you make this clear in other languages.
27. Consider getting some expert advice.
Does this all sound like a bit too much to handle right now? I’ll admit, internationalization is a niche, and can take many years to really get right. If you don’t want to learn about all of this the hard way, there is an entire profession full of people, often with degrees in localization, who can help you out. Localization professionals often sit on Product and Engineering teams, because this is where they can make a huge impact by ensuring that software and web experiences are built in global-friendly ways from the very beginning.
If you’re lucky enough to have a Localization team at your company, use them! Ask them early for their input. Trust me, they really want to ensure that you make the right choices now to ensure a global-ready design from the earliest point in the process possible. And if you don’t have someone like this on your team, you can always find people with localization expertise who can help you.
Many localization vendors (translation agencies) offer these types of services too, but you’ll have to make sure they actually specialize in software localization. If you’re building web apps, my advice would be to focus your outreach on companies that specialize in that area of localization. It’s a big industry, and companies can specialize in anything from gaming localization to medical device localization. Ask around and find out what peers in other companies suggest.
There are also a handful of companies out there who provide consultative services focused specifically on internationalization that can save you a ton of time. They’ll be able to take you into the weeds specific to your unique use case, and far beyond the realm of just the guidelines listed here. They can take you and your team into the details of Unicode, string externalization, concatenation issues, locale selection within your programming languages, fallback locale selection, third-party libraries you can use, forms that need to be optimized for international data entry, and so on. Don’t be afraid to lean on them, especially if you have a budget for it. They can save you a lot of time and pain by helping you set things up properly.
Localization Best Practices Checklist
If you’ve managed to make it this far, here is a checklist you can use and share with your team members as reminders of things to consider:
- Does our design allow for text expansion wherever text appears?
- Does our design allow for larger font sizes for other languages?
- Have we separated all text from images?
- Have we made image files easy to swap or hide?
- Are the image source files easy to access?
- Are all the strings in resource files?
- Have we run a pseudo-localization step?
- Have we checked for garbled characters?
- Are we considering multiple locales in our use case?
- Does our database support multiple locales?
- Are we using standard and consistent file structures?
- Do third-party dependencies support international use cases?
- Can strings be easily identified?
- Have we fixed all concatenated strings?
- Have we placed all punctuation inside strings?
- Did we avoid hard-coding currency, time, and date formats?
- Do we accommodate different ways of ordering personal names?
- Are we using UTF-8 encoding?
- Are we using locale, and not just language?
- Are we allowing the user to indicate their preferred language?
- Are we making it easy for the user to change languages?
- Are we taking plurals into account?
- Are we sorting items on the server side vs. browser side?
- Are we addressing directionality?
- Is it easy to switch colors?
- Are we giving the translators enough translators?
- Do we need any localization advice?
As a side note, I actually created this checklist as an image so that people could find it in Google Images, but then I remembered one of my own rules — no embedded text in images! Even though I don’t intend to translate this article, you just never know if someone else might want to someday. So, here you have it in a format you can copy and paste directly into an email, a slide, or whatever format you wish (with a link to www.borntobeglobal.com, preferably). 😉
Finally, while this list includes 27 guidelines for localization to help you understand what localization means in general, it’s by no means comprehensive. There are tons of variations on these guidelines specific to any given scenario. However, this list covers the items I think are the most important for someone who is rather new to this topic, or is looking to help others who are.
With that, best of luck on your localization journey. I’d love to hear how it goes!
