Creating a web app? It’s important to make sure what you’re building can be quickly and easily localized. Here’s a list of 27 web application localization best practices to help you on your way. Following these guidelines will help make your content easier to localize, so that you can provide an equitable experience to users regardless of country or language. Key Terms for Understanding Web Application Localization Best Practices First, a quick note on terminology. There is a lot of nerdy vocabulary we use in the field of localization (you can read more about localization definitions, and why we need to uncomplicate them, here).  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.” Internationalization on the other hand, is what enables localization to even be possible (or not) in the first place. It takes place at the coding and development stage. To ensure that a product can be localized, it first has to be internationalized. So, internationalization is really just a fancy way of saying “making something localizable.” Here’s a simple way to think about it: first comes internationalization (global-ready code), then comes localization (local experience). 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.