Internationalizing software usually comes with significant costs that can be difficult to explain to management. However, with the right process in place, these costs drop significantly, and the entire i18n process becomes smoother. In this article, we will examine two different approaches to i18n, consider cost of i18n in each of them, and explore experiences of a real client. Since this company wishes to remain anonymous, we will refer to them as Company X (not the “X” you are thinking of 😉).
Two Approaches to i18n
Approach #1 – Downstream: Identifying and fixing i18n bugs during testing, translation, or when customers report them.
Approach #2 – Upstream: Catching i18n issues before they become bugs and fixing them during development.
In the first part, we will share a detailed monthly snapshot of the i18n bug-fixing process (Approach #1), documented by the localization team at Company X. You might see that the process is not perfect, and you probably handle it differently. Your reaction might be, “No way, it can’t take that much time.” However, we are simply presenting the real data we received from the client, with the actual costs they incurred. In some cases, we will reduce the time reported by Company X to make the final results appear more typical for general scenarios.
In the second part, we will see how the process and cost of i18n can change if you choose Approach #2.
We hope that this data will help you clearly explain how i18n is performed to management. It will also help justify the cost of i18n and understand the difference between these two approaches.
Before we look at the i18n bug-fixing steps and calculations, let’s quickly run through the list of i18n issues. These are the problems that the Company X localization team encounters on a monthly basis. This will give a better picture and explanation of the time the team spends on fixing each type of issue.
Types of Issues Identified During the i18n Bug Fix
Concatenations – 55 issues per month
This is the most common issue in software localization and in our case. Concatenations lead to grammatically incorrect translations and unclear or ambiguous messages. This issue occurs when developers join separate strings together to form a sentence or phrase in code, like this:
This produces “White dog” in English but can cause problems when translating to other languages:
- The word order may need to change, for example, “Chien blanc” in French.
- The translator may not know the words should go together.
- Adjectives may need to agree with nouns in gender, number, etc., which can’t be handled by concatenation.
Concatenations, unlike other issues, can be hard to cluster and solve as one issue, as the solutions for different cases and languages can vary. Some resolve quickly, while others require lengthy discussions, making it hard to cluster and address them as a single issue. We will see this later in the calculations.
Translators cannot solve concatenations. Developers must fix the issue in the code. Translators often notice the issue in many languages when developers don’t catch it up front. This situation results in many bug tickets for the same issue, which developers should fix during development.
Embedded strings – 3 issues per month
Embedded strings, also known as hard-coded strings, refer to text directly inserted into the code of an application, rather than being stored separately in a resource file. You can see this in the example below:
Embedded strings will not be seen by the translator and will display in the source language (typically English) for users.
LSM or Locale-sensitive methods – 10 issues per month
These issues arise from differences in displaying:
- Date and time
- Numbers and currency
- Character encoding
- String functions like upper/lower casing, and more
UI layout – 20 issues per month
- Text expansion and overlapping
- Text truncation
- Bi-directional language support (i.e., Arabic, Hebrew)
These are typical i18n issues that Company X discover on a monthly base while doing i18n testing. Let’s now examine and calculate the approximate cost of fixing this number of issues for a product requiring localization in 20 languages.
Approach #1: Fixing i18n bugs (Downstream)
Step 1. Issue Discovery and Documentation
The process starts with discovering an issue, which takes about 5 minutes (per issue/per language) to identify, plus an additional 5 minutes (per issue/per language) to document, such as taking screenshots.
Next, the localization team creates a bug tracking ticket, which involves logging into a system like JIRA and navigating through it to submit the issue. This stage requires a detailed understanding of where to log the issue and attach the necessary documentation. The team measured this stage as taking 10 minutes per issue, per language. However, if you consolidate the issues by type and language, it can be faster. For the sake of examining more generic cases, we will assign less time: 3 minutes (instead of 10 minutes) per issue per language.
Step 2. Triage
The next step involves identifying and documenting the issue, then quickly assessing and prioritizing them based on urgency and severity (triage). Here is exactly what this stage includes:
- Assessment: Evaluating the severity and impact of a bug or issue reported in software or systems.
- Prioritization: Ranking the issues based on their criticality, potential impact on users or systems, and resource availability.
- Allocation: Assigning the issues to the appropriate teams or individuals for resolution based on their expertise and current workload.
Organize this step as a weekly meeting with people from different teams to sort out all the steps above. Company X did it exactly this way.
To make an estimation for this step, a lot depends on how the bugs are entered and how they’re tracked. If they’re all in the system in a way that can be seen correctly, then you can say, “these 20 issues are all the same issue,” and you can consolidate them at this point. However, this does not always happen.
For the average estimation, Company X assigns 5 minutes (per issue) spent on this stage. Without consolidation, this number, as you can imagine, grows significantly.
Step 3. Fixing the Bug
So, now that the triage is complete and the development team has received the issues, we move on to the planning and fixing phase. The planning happens before any sprint. This includes determining the bug’s location in the code, identifying the difficulty (easy, medium, hard), deciding on a fix, and assessing any potential impacts on related functionalities.
As you can see from the table, fixing different issues requires different amounts of time. It’s not always easy to figure out where an issue occurs in the code, so you may need some deeper dive. The UI layouts can be quite time-consuming as they involve not only the development team but also designers. Concatenations can be quite hard, requiring different coding solutions for each of the programming languages they are found in, but with guidance from i18n experts this can be made more efficient.
Step 4. Pull Request/Review
Typically, companies have not just one, but two people who review pull requests (this was the case for Company X as well). This means that both individuals discuss the issue, ensuring the work follows standard procedures and comparing it to previous work. The review can range from a quick one-minute check for simple issues to longer discussions of up to 60 minutes for more complex changes. We assign 2 minutes (per issue, per language).
Step 5. Regression Testing
Regression testing involves retesting previously tested code to ensure that recent changes or bug fixes haven’t negatively affected other parts of the application. This involves retesting in various scenarios and possibly across multiple languages if the software is multilingual. For example, if you find and fix a bug in one screen of an administrative function, you must not only verify that the fix works as intended but also check all related screens to ensure no new issues appeared. This stage also included taking screenshots (to prove the bug fixed or not, if that’s the case), updating, and closing tickets in the bug tracking system.
Let’s summarize all the steps and time spent on discovering and fixing issues, and calculate the potential cost of i18n.
- In total, it takes 880 hours of work.
- A fully loaded/blended rate for a person who will perform the work on the documenting and regression testing stages is $75/hour.
- A fully loaded/blended rate for the fixing stage, performed by developers, is $125/hour.
- The total monthly cost to fix the given 88 internationalization bugs is $73,031.
You can see the full process and calculations that we’ve just described in the table below:
Now let’s see how the cost of i18n can change if Company X switches to the Upstream approach.
Approach #2. Finding i18n issues before they become bugs (Upstream)
Key Highlight: Globalyzer helps to detect i18n issues during development, preventing them from becoming actual bugs. This significantly reduces the number of steps compared to previous methods. Additionally, it finds i18n bugs when they are expedient to fix, rather than later after localization or reports from field offices.
This approach aims to catch all of the i18n issues as developers write the code, eliminating unnecessary and costly bug tracking, code review, refactoring, retesting, and release.
Step 1. Issue Discovery and Documentation
Previously, this step involved several actions, but with Globalyzer, only issue discovery remains. Globalyzer scans the code during development and identifies potential i18n issues, displaying them in the integrated developer environment (IDE), commit and pull request reports, and in the Command Center dashboard, categorized by the total number of issues and their types. Since the issues are caught early, they are resolved before the release, eliminating the need for extensive documentation such as taking screenshots or creating bug tracking tickets.
Step 2. Fixing the Issue
Globalyzer eliminates the need for assessment and bug prioritization because it catches issues before they become bugs. The only remaining step is to fix the issue within the code.
It also solves the problem of locating the issue within the code, as it provides the exact location directly to the developer, saving developers valuable time.
Comparison Cost of i18n for 2 Approaches
Let’s compare the final calculations for these two approaches to i18n.
| Number of issues | Number of steps | Number of hours | Costs | |
| Approach #1. Downstream | 88 | 11 | 352 | $73,031 |
| Approach #2. Upstream | 88 | 2 | 45 | $5,596 |
Using the Upstream approach, Company X can catch issues before they become bugs, saving almost 90% of the effort (45 hours compared to 352). This reduces the cost of i18n by 92.5% (from $73K to $5.5K)!
Do you want to learn how Globalyzer and i18n Guidelines services can reduce your i18n costs and help you set up a fast, efficient i18n process?
