How To Fix i18n Bugs: Your Ultimate Guide to Software Localization Success

Table of Contents

An ounce of prevention is worth a pound of cure.

This life hack, over 800 years old, remains just as vital in our digital era, especially for software localization. Catching bugs early in the development process saves time, money, and customer frustration.

In the world of software internationalization (i18n), even a tiny bug affecting language or cultural settings can be expensive, harming both your product’s effectiveness and your company’s reputation.

And the worst part is, the longer you turn a blind eye to a problem, the more it will cost you on a later stage.

Why i18n Matters?

i18n – A Simple Definition

Internationalization, or i18n, prepares your software for a global stage, ensuring it supports various local languages and respects cultural nuances across different markets. 

Think of i18n as the behind-the-scenes work on your product, setting the stage for l10n, which is where we translate and tweak content to fit right in with local cultures. To put  the difference in simple words – i18n adapts the code, l10n adapts the experience. 

I18n is the biggest contributor to the failure of software in the local markets, and a difficult issue to solve. Why? Developers and localization managers usually come from completely different backgrounds, first ones are unlikely to understand localization and second ones rarely understand code. 

As a result, i18n issues often stay unnoticed, lying hidden in your software’s code.  But just because they can’t be seen doesn’t mean they aren’t creating costly problems for your business.

Why i18n Matters – The Impact Of Hidden Bugs

Addressing the impact of i18n bugs is both a strategic and practical issue. In this article, we’ll outline common i18n pain points, and provide practical solutions and real-world examples to bring these concepts to life.

But first, let’s focus on the strategic importance of i18n to help you convince your C-Suite of the crucial impact of something they can’t see and may not appreciate using terms they care about.

Decreased revenue




A poor user experience leads to lower conversion and retention rates. Any issue that makes your software harder to understand or culturally confusing costs your business money. I18n bugs increase the cognitive load on your users, forcing them to think about how the UI works, which inevitably drives down acquisition and retention, hurting your bottom line. In its worst case, i18n issues can make the UI unreadable with character corruptions and truncations, which will block users from wanting to use your software from the get-go. 

Reputational damage






Nothing turns customers off more than sloppy l10n. If your business fails to deliver a functional and effective product optimized for every locale, your brand will suffer.
Functional errors that creep into a live product or sloppy adaptation to cultural norms can lead to a perception of poor quality (reflected in damaging negative reviews), lack of attention to detail or cutting corners. Any or all of those will damage your brand’s reputation, and as the saying goes, “Trust in a brand arrives on a snail but leaves on a horse”.

The cost of being slow to market






Delays in shipping new software cost money. If your software company has global aspirations, being fastest to new markets is just as important as being best, but unaddressed i18n bugs within a poorly managed l10n process slow down the launch of new software.
Delays to product launches are expensive, especially when there are so many moving parts, such as events, PR and partners, to consider. Equally damaging is getting a product out the door without proper i18n Quality Assurance (QA), to then start receiving damaging negative customer feedback, derailing your development pipeline to retrospectively fix i18n bugs.

The risks of failing legal compliance





i18n bugs may fail compliance resulting in legal issues and fines. While some aspects of poor i18n can be hard to quantify, legal compliance, which can vary by country and administrative block, is black and white. The EU is a good example, with laws around l10n of web accessibility, privacy and medical devices, which include software and hefty penalties for those who don’t follow the rules. At the extreme, there is one medical products company that took on our i18n analysis software because an i18n issue had previously resulted in a patient’s death.  A dosage hadn’t been properly presented because a locale setting for a measurement unit wasn’t working correctly.

In 2009, HSBC Bank faced a significant challenge due to a poorly localized marketing campaign. Their tagline “Assume Nothing” was mistakenly translated in various countries as “Do Nothing.” This mistranslation fundamentally altered the message’s intent, suggesting inactivity and indecision rather than the intended message of not taking things for granted. The bank had to spend $10 million for a rebranding campaign to correct this mistake, changing their global tagline to “The world’s private bank,” which carried a clearer and more universal appeal. This case underscores the importance of linguistic and contextual accuracy in l10n, especially in marketing and advertising.

2014 LinkedIn faced serious problems due to imperfect i18n and l10n processes. Europe has strict data protection laws, such as the General Data Protection Regulation (GDPR), which came into force later in 2018, but strict regulations were in place before then. LinkedIn has been forced to make some changes to its data processes and privacy policies to comply with local laws. While LinkedIn did not face major fines for this incident before the introduction of GDPR, the company did incur significant costs to change its systems and processes and improve its data protection measures.

Convincing Stakeholders: Software L10n Depends On i18n

i18n is the prerequisite step to the broader L10n process, which aims to produce an end product with an optimal UI that makes sense to the local audience. 

Unfortunately, many software companies struggle to align these competing stakeholders effectively, paying the price of i18n technical debt.

Impact of i18n bugs

What Are The Biggest i18n Pain Points?

So, we’ve just reviewed the broader context of i18n issues to help you build a compelling case for your stakeholders. Now, let’s dive into the details. We’ll explore the most common i18n challenges you may face during the software localization process and discuss the best practices for effectively addressing them.

UI Text Strings

Every software interface (mobile apps, desktop applications) is a complex mix of code, text, and images designed to deliver the best user experience. 

Unlike long-form text found in paragraphs or headers, software text usually appears as labels, tooltips, or product descriptions embedded within UI code as text strings. 

For the UI to offer an optimal experience in local markets, those text strings must be localized along with the rest of the source content such as documents, help and images, but their mishandling is one of the most common i18n pain points. 

Here are some advices on how to handle them:

Embedded strings:

To facilitate the management and translation of text strings, follow these steps:

  • Avoid embedding text strings directly in the code. Instead, export them as discrete strings with unique identifiers within a resource file.
  • Utilize the resource file to dynamically load UI elements during runtime, according to the user’s language selection.
  • Adopt best practices by storing UI strings in resource files as key-value pairs. Create a unique resource file for each locale, ensuring the software selects the appropriate file based on the user’s chosen locale.

Example: Here are two simple text strings

String titleLabel =”Order history”;
String  nbItemLabel =”Number of items”;

Generate a Key/Value pair in a resource file and refer to that key in the code to retrieve the value. The value is the string itself.  You can retrieve the string from a locale-dependent resource file.

ResourceBundle MyStrings= ResourceBundle.getBundle("i18n.MyResourceBundle", locale);
String titleLabel = MyStrings.getString("order.history.title");
String nbItemLabel  = MyStrings.getString("item.number.label");

The key/value pair in the resource file looks like this:

order.history.title=Order history
item.number.label=Number of items

Concatenated strings

Concatenated strings link words together in chains or series. Different languages have different word orders and different grammatical rules that affect the words that follow.

About one-third of languages, including English, use SVO (Subject-Verb-Object), but more than half of all languages use SOV (Subject-Object-Verb), while a much smaller proportion are VSO languages.

Impact: Concatenation of the string fragments or string variables produces grammatically incorrect translations, often with unclear or nonsensical meanings.

Example: Translating an application message confirming a project is ready.

Solution: Where possible, avoid the dangers of concatenating strings by using full sentences and discussing the base text with your l10n team before it is signed off. If you must insert variables, use a notation such as curly brackets {} marking the insertion point instead of concatenation. 

Here’s the English: 

LOCALYZER_READY_PROJECT_NAME= Your Localyzer Project ${LzProjectName} is ready

And the corresponding one in Turkish: 

LOCALYZER_READY_PROJECT_NAME=${LzProjectName} adlı Localyzer projeniz hazırdır
The variable ${LzProjectName} gets replaced with the appropriate value during runtime.

Context and UI Strings

Accurate translation of UI text strings requires understanding their context. This includes knowing where in the UI the string will appear, its meaning, the function it serves, and any space limitations. Without this context, translations may not align well with the product’s UI, leading to potential confusion 

Impact: Without proper context, translations can confuse users, complicating navigation and affecting their overall experience. Moreover, cultural inaccuracies can disengage users, while translation errors may obstruct smooth transactions, reducing overall satisfaction.

Example: Distinguishing nouns from verbs without contextual clues, or,  the meaning of “Home” on a screen of a GPS application.  Does it mean the home screen or the driver’s home address?

Solution: Provide contextual information in the form of visual context to preempt the common questions from translators about UI text strings. Being able to see the string in the UI provides translators with contextual information on the meaning as well as the preferred length of the translation. Look for software localization tools with an in-context translation feature that connects UI  strings with screenshots or rendered UI screens.

Text Expansion

Many languages will expand the length of text strings when translated.

Different languages need different length of text strings when translated

Impact: Text expansion can make menus and buttons unreadable and potentially make the UI unusable in certain languages. 

For example: French and Spanish,  increase length by 15-30%, while German and Dutch are notorious for bloating text by up to 35%.

Though script languages may result in shorter translation strings, characters are often taller, requiring more vertical spacing. 

Solution: It’s generally good practice to not create very crowded screens in English.  Provide expansion guidelines to your UI designer to keep in mind when designing screens. UI designs can be tested with pseudo-localization or machine translation to view the expansion and adjust early on.  If you are using FIGMA, request for the string expansion testing to be done right during the design stage instead of waiting for the development phase.

Here is the example of how you review translation without leaving Figma.

Pluralization

Understanding pluralization is crucial because the rules for forming plurals differ widely among languages. In English, adding “s” or “es” to a noun often creates the plural form. However, other languages feature more complex systems, including singular, dual, and multiple plural forms, depending on the quantity of items being discussed.

Impact: Overlooking pluralization in UI strings can lead to confusion and frustration due to grammatical errors, making content hard to understand. This oversight may also come across as culturally insensitive to users from languages with complex pluralization rules, damaging their trust in the software and potentially reducing user engagement and satisfaction.

Example: English has singular for ‘one’ item and plural for all ‘other’ items, including zero. In contrast, Arabic employs ‘zero,’ ‘one,’ ‘few,’ ‘many,’ and ‘other’ rules, while Ukrainian uses ‘one,’ ‘few,’ ‘many,’ and ‘other.’ 

Solution: Use the ICU Message Format, where the count is a variable in the application, e.g. display “1 result” if the count is one. If the count is 17, the application will display “17 results.

This ICU Message Format approach enables the application to display the correct plural form while allowing translators to provide translated messages that may include additional selectors, such as ‘few’ and ‘many.’ This way, the correct pluralization ensures both accurate communication and cultural sensitivity.

Region Specific Formatting, Settings & Numbers

Globalization may have made the world more connected, but it retains a mish-mash of currencies, standards and numerical formats that can be problematic for i18n and your software UI.

Date and Time Formats

Not only do date formats differ by region, but dates come in short date (numbers) and long date forms (words and numbers), where the latter need to be in the language of the user. The date is also often combined with time, giving a further headache as to whether the 12/24hr clock applies and the challenge of applying the correct timezone. 

Impact: Just because a short date appears to have the correct format, it is not guaranteed that is correct, as it may still express the wrong information.

Example: 05/06/07 can refer to three different dates depending on the region of the user

  • May 6, 2007 – for an American
  • June 5, 2007 – for a Frenchman 
  • 2005, June 7 – for a Japanese

Solution: The application needs to format the date based on the user’s locale. This is true both for short-date formatting, as well as long-date formatting. For instance, “June 16, 2023” needs to use the French word for the month with correct capitalization and punctuation conventions so that the date now is shown as “le 16 juin 2023”. Similarly, “2:25 pm” must be changed to “14:25” for France. Use an i18n library and pass the locale variable to the correct method to format dates and times before displaying them to the user.

Number Formatting

The formatting of numbers and currency varies from region to region, with differing meanings and application of symbols.

Decimal SeparatorsPeriods and commas are the most common decimal separators.  English vs. non-English speaking countries such as the US, UK, and India utilize a period for a decimal separator, and most European non-English speaking countries will utilize a comma instead.0.1
0,1
Thousand SeparatorsWhile in the US, commas are used for a thousand separators, not every country uses the same. Other variation examples include periods for Germany, spaces for France, and apostrophes for Switzerland. 1 000
1,000
1.000
Grouping DigitsThe grouping of digits varies between two and four. This means that not every country uses a thousand separators. Japan uses ten thousand separators, and India groups digits by twos and threes. 1.000.000
10 000
1,000,000
10’000
10_000
Percentage SymbolCan appear before or after the number depending on the region% ٪ ﹪ %
Currency SymbolsPlacement varies depending on the location, either before (most English speaking) or after (non-English speaking)$1 / 1$
€ £ ₪ ₳
Negative NumbersHyphens and Minus signs might look the same but are unique characters and shouldn’t be interchangeable. Other forms of noting negative numbers are with parenthesis or colour coding in red −1
(‐)
Scientific NotationExponent and power function display can vary by region. Ordinal Numbers: 1st, 2nd, 3rd (in English) will have different regional/local application10 ✕ 1010

Impact: If your application displays the same number notation regardless of locale/region, your customers may be unable to interact with your software UI.

Example: Currency Format 

A Canadian French user will expect to see “5.000” and will be annoyed to see formatting that is not adapted to his/her culture. A Canadian English user, seeing a $5,000 price tag and assuming that it is in Canadian dollars, will get a nasty surprise upon finding that the quote is in US Dollars and therefore more expensive.

LocaleCurrencyExample
US EnglishUS Dollar$5,000.00
US EnglishCanadian DollarС$5,000.00
US EnglishChinese YuanCN¥5,000.00
China ChineseChinese Yuan¥5,000.00
France FrenchEuro5 000,00 €

Solution: The application must format the number portion of the currency and display the correct currency symbol placed before or after the numeric part. If your application displays currency without doing currency conversion 3-letter currency symbols such as USD versus CAD resolve the potential confusion.  
However, it is a good practice to represent currencies in the user’s preferred language and region, which may require currency conversion as part of your application logic.

Currency, Time Zone and Units of Measurements

Users need to have information presented to them per their cultural conventions to successfully utilize a localized application. The example above represents how an e-commerce application needs to consider currency conversion. For global applications, you need to consider the time zones and units of measurement as well.

Impact: If an application does not represent the information in the user’s conventions, it will be harder to use, or worse, cause frustrations that can affect your company’s reputation.

Example: Local time and metric system

A US user sees an item he wants to purchase is on discount until midnight. The item’s weight is in kilograms, and the cost is in Euros.  He first needs to convert the kilograms to US pounds and the Euros to US dollars to make a buying decision.  As he purchases at 8 pm he realizes that the discount has not applied and is very upset.

Solution: Your application should represent the time when the discount is over by converting and displaying it in the user’s time zone.  Also, convert product descriptions with measurements in your database to kilograms and select the right unit based on users’ locale preferences before displaying information to the user.  Ideally, currencies should be converted to users’ preferences dynamically as well. 

Static Files

One of the most common i18n bugs is caused by an application serving the same static file, such as a video or a legal HTML file, regardless of the l10n preference of the user. 

Impact:  A resource doesn’t match the UI language or /regional requirements of the user

Example: A product preview video is referenced from a static file regardless of the locale preference:

placemarkAttributes.videoSource = “./img/marker.mp4”;

This results in a Chinese video being shown to a Russian application user. Or, a US legal document served to a UK user. In this case, even though the language is English for both cases, the regional language and legal laws require different versions of the document.

Solution:  Your application framework needs to support the mechanism to serve the correct static file specific to each locale, ensuring that a Russian user sees a Russian video.

How To Address i18n Bugs Before They Become Part Of Technical Debt

You now have a list of the most common i18n bugs and a set of solutions, but if you feel a little overwhelmed at the need to update and adapt your processes to account for all this new information, don’t worry. Here are a few pieces of advice you can use.

Use Specific i18n Tools

i18n bugs can be detected as code is being developed, not after, and the appropriate solutions can be applied quickly and easily within one piece of software – Globalyzer

Here’s how Globalyzer can fix i18n bugs before they have the chance to creep into your software

  • Realtime prompts in the developer’s IDE – A developer can add Globalyzer i18n detection to their development environment and see i18n issues as they work.
  • Feedback during commits or pull requests – As a developer submits a day’s work, a Globalyzer scan can run automatically, pointing to any i18n issues, making it easy to fix them and then quickly move on.
  • Measure i18n readiness – Dashboards for specific repositories, entire development products, or software across your enterprise give a broad view of i18n readiness while enabling issue drill downs, assignments and other management features.

Writing well-internationalized code and employing software like Globalyzer is an effective way to avoid l10n issues but it must be part of a broader set of best practice l10n strategies, which is what we’ll introduce in the next section.

Globalyzer has been at the core of our success!
It helped us not only with i18n refactoring but also provided the visibility we needed to manage the i18n project at the company level.

Apply i18n Best Practices

Use Unicode

Ensure your software supports Unicode, an international encoding standard by which each letter, digit, or symbol is assigned a unique numeric value.

Common Cause: Software created for the US works fine supporting only ASCII which uses less memory

Impact: Solves data exchange problems and ensures consistency.

Translate & Review UI strings Immediately

Once the UI strings have been translated, thoroughly test the software in the target languages from all perspectives. Check the UI for text overflows (horizontally and vertically), incorrect or inappropriate translations, or missing/malformed text strings. Consider pseudo-localization to identify layout issues and prevent them early on.

Common Cause: The UI localization process happens piecemeal and often without full context.

Impact: Reduce the chances that mistakes and issues are missed. Developers aren’t sidelined with retrospective fixes and products launch on time.

Consider Cultural Sensitivity

L10n isn’t simply about translating text but finding the most culturally appropriate and relevant representation of the entire UI in another language. Use i18n to bring the correct colors, images and UI based on the user’s cultural preferences. 

A simple example is using green to indicate a positive incremental change in tables or charts and red for the reverse. This logic isn’t universal, for example, in China, the reverse is true. Red represents success and fortune, whereas green has negative connotations, such as infidelity.

Common Cause:  Reuse of the images, icons, or color choices.

Impact: Software UI is culturally sensitive, improving brand value and reputation.

Automate L10n Processes & Integrate the Right Tools

Employing an integrated Machine Translation solution with human review will dramatically reduce errors, speed up product launches and produce better software in all target markets. You can utilise MT without human review during your design and development processes for an initial view ion the UI screens so that Figma designers and developers can make adjustments quickly and before l10n. Great example of the tool that provide this clarity is Localyzer and Figma Integration.

Common Cause: Short-term thinking; absence of an IT solutions architect; underappreciation of the value of l10n. 

Impact: Automation helps create l10n-ready design and development, making l10n scalable, decreasing time, reducing human error, and cutting costs. 

Do Not Program ICU Format Switch Cases In The Resource Files

The purpose of the ICU is to help with translation, not any other goal, not even other i18n fixes. This means developers should program switch cases in the application, not in resource files.

Common Cause: Many developers like using the ICU format mechanism beyond pluralisation, as the selection looks like a switch case. Examples include:

  • Gender-specific messages 
  • Text replacement 
  • Complex language constructs 
  • Nesting 
  • Format numbers, dates, and times

Impact: Streamlined and efficient processes result in better-quality translations and a smoother user experience. 

Get Consultation From i18n Experts

If your software development processes suffer from many of the common challenges we can help you to solve them. Here are just a few examples of the i18n services that we provide.

I18n Guidelines

Your development team is new to i18n, they don’t have enough expertise or bandwidth to support code i18n.

Guidelines Service will address these challenges:

  • limited expertise in i18n
  • lack of time and resources to find the best way for your code i18n 
  • need recommendations that are specific to your architecture, technologies, and coding practices

Guidelines Services includes:

  • Development of missing frameworks 
  • Refactoring of a selected module of code to support i18n
  • Testing of i18n’ed module 
  • Documentation of pre-i18n and post-i18n code examples as Guidelines
  • i18n Training sessions based on the Guidelines
  • On-going support services as needed to support dev teams

Our i18n issues were complicated and we were stuck. Hiring Lingoport was the best decision for us

Snap Inc. improved l10n process with Lingoport services

I18n Assessment  

You want to implement  i18n or already have it in place. However, you need an expert assessment to be able to support business and meet global launch deadlines. 

Assessment Services will address these challenges:
  • You inherited software that doesn’t support i18n
  • Additional markets/languages were an afterthought in code development
  • Low-quality translations and poor i18n implementation generated customer complaints and lost revenue and reputation
  • Unsustainable time and effort spent finding and fixing i18n code issues
  • You simply don’t know where to start
Assessment Services includes:
  • Architectural discussions
  • Line-by-line source code analysis with Globalyzer
  • Detailed task list
  • internationalization requirements document

I18n Implementation 

You have big global expansion goals and would rather outsource the i18n engineering work as you need your development teams to concentrate on building new products and features. We can take over the i18n enabling function entirely for you.

Implementation Service address these challenges:
  • Pressure to meet global release goals 
  • Absence of expertise in internationalizing software
  • The overstretched dev team has no bandwidth for i18n issues
Implementation Services include:
  • internationalization architectural consulting
  • Testing design
  • Targeted development tasks
  • Ongoing development advisory service
  • Fixing software internationalization technical debt
  • Assume all phases of i18n work including pseudo-localization and other testing (optional)

Author

Kate Vostokova
Kate Vostokova
Kate is a seasoned B2B content marketing manager with a five-year journey in the localization industry. She is passionate about crafting various types of content to educate people about internationalization (i18n), localization, and the latest technological advances, including Large Language Models (LLMs).
Hand with mobile phone

Talk to Our Experts

Get you tailored consultation on i18n & L10n products and services.

Related Posts

Receive Latest News and Webinar Dates

Get the latest internationalization news delivered to your inbox.