In a previous post, we discussed LQA testing and the different approaches teams can take to cover it. However, we didn’t touch upon its importance or the categorization of issues. Let’s talk about it!

Importance of LQA

One area that often seems like a black box – or is assumed to be automatic – is the translation phase of a project. Many stakeholders mistakenly view it as an automatic, foolproof step. But nothing could be further from the truth.

I strongly advocate for providing as much context as possible when sending the original content for translation. This ensures higher quality for the localized content that comes back from LSPs (or freelancers). However, localization is not an exact science. Due to the complexity of different languages, you often won’t know if the content is fully correct until you see it displayed within its proper context.

Here are some examples of perfectly translated English content to Spanish that still doesn’t make sense when viewed in context:

Here, “{{amount}} saved” was translated in the context of “saving data” rather than “saving money.” 

Here you can see how the verb (which is quite simple in English) wasn’t properly conjugated in other languages (the Engineering team is using the same string for “You sent a document as an attachment” and “{{first_name}} sent a document as an attachment”.

For these reasons, LQA is an essential step, especially if you want to maintain high product quality in international markets – and to avoid potential legal issues.

Issue categorization

Categorizing issues during LQA is one of the most important aspects of the process. This is critical for multiple reasons:

1. It helps the localization team understand how well the company’s development teams follow internationalization best practices.
2. It allows the localization team to monitor whether translation-related issues are present in the UI that could have been caught earlier.

Most companies classify issues into two main categories: Functional and Linguistic. However, some companies prefer to add a third category: Internationalization – especially when there is a thin line between linguistic and functional issues, making it tricky to classify them.

Functional issues

Functional issues are typically the responsibility of developers and are related to problems in the system’s performance. Examples include:

• Broken functionality: The feature works in English but not in other locales.
• Incorrect locale: The wrong language is displayed in the UI.
• Source issue: Errors in the original English content.
• Corrupted character: The character set that’s being used is not UTF-8 and one or more characters in one language (like ñ or œ) are not properly displayed in the UI.
• Visible key: Code strings are displayed in the UI instead of actual content.

These issues tend to be quite severe and must be addressed sooner rather than later.

Linguistic issues

Linguistic issues can usually be fixed by the localization team and often relate to the quality of the translation. Examples include:

• Mistranslation: The content was translated with a different meaning than intended.
• Incorrect grammar: The content contains grammatical errors in the target language.
• Typo: The string contains incorrect wording (e.g. “singer” instead of “signer”).
• Punctuation: The translated content does not follow the punctuation rules of the target language.

Internationalization issues

Internationalization issues are more complex. Some can be fixed by the localization team, while others should be addressed by the development team. Examples include:

• Fragmentation/Concatenation: Dynamic placeholders are used incorrectly. Although it’s the dev team’s responsibility, they often need guidance from the localization team to fix it.
• Truncation/Layout issue: The content isn’t displayed correctly, or it overlaps with other UI elements. While the dev team should fix this, the localization team can sometimes shorten the content without affecting its quality.
• Format: Incorrect formats are used for currency, dates, or other localized content.  
• Design: The design didn’t account for global market needs (for example displaying first + last name for certain asian locales).
• Legal: Some regions have specific legal requirements that must be followed, and non-compliance can lead to significant legal consequences.

As you can see, there are many different types of issues that can arise during LQA, and the severity of these issues will vary by company and team. Each organization has its own priorities and risk tolerance, so there isn’t a “one-size-fits-all” approach to issue categorization. However, I always recommend applying the same standards to international issues as you would to English-language content. For example, would you accept an English page with errors like the ones found in the Japanese version? It took you some time to craft the English content, and you should also be proud of the localized versions!

Thank you for taking the time to read this! I hope you found it informative. See you in our next post!