Working with Localization on Websites and Mobile Apps in APAC


Welcome back to another episode of Continuous Improvement, the podcast where we explore strategies, best practices, and insights to help you enhance your professional skills. I’m your host, Victor, and today we’re diving into the world of frontend localization.

But before we get started, let me share a bit about myself. I used to work as a technical lead in a bank, where acronyms seemed to rule the day. From HSBC, which hilariously stood for “How Simple Becomes Complicated,” to ASD-ASP, the team I was part of—Accelerated Scaled Delivery in the Asia-Pacific—I learned firsthand how complex frontend development can be.

In today’s episode, we’ll be addressing a question from a colleague in the UK who reached out to me about localization, tools, and best practices in the Asia-Pacific region. With my company expanding to locations like Singapore, the Philippines, and Vietnam, it’s a topic close to my heart.

So, let’s start by demystifying the term “i18n” often used in frontend development. Did you ever wonder what the number “18” represents? Well, it’s not actually about 18 different languages, but the number of letters between the first ‘i’ and the last ‘n’ in the word “internationalization.”

Now, let’s dive into some real-life experiences. During my time at HSBC, we faced numerous challenges when it came to making even the smallest changes on a website. It often took weeks to change just one word on a production webpage due to the involvement of multiple teams, from business requirements to code review, quality assurance, and deployment.

One example I encountered was a timer that posed serious accessibility issues. Imagine relying on an accessibility tool as a visually impaired user, and you have no way of knowing the remaining time to complete a transaction. It’s a frustrating experience that could’ve been easily avoided through better frontend development practices.

Speaking of practices, we used Adobe Experience Manager (AEM) to build web pages. While it allowed non-technical team members to make updates, it frequently required frontend engineers to make text changes or create dialogues using XML—a process that added unnecessary complexity.

Mobile localization had its own set of challenges. We relied on Python scripts to read copy in various languages from a Confluence page and generate localized JSON files, which were then included in the app. However, this approach often created more problems than it solved, as we discovered.

One common issue was inconsistencies in frontend designs labeled using Confluence pages. Outdated screenshots and inconsistent keys caused unexpected side effects when values were updated. It’s crucial to have a robust system in place to ensure accurate and up-to-date translations.

Let’s now turn our attention to potential localization issues on-screen. Imagine a scenario where the term “country” is used to list Taiwan or Hong Kong as separate countries, which can be illegal due to national security laws. These are the kind of pitfalls that must be avoided in a robust localization strategy.

Another challenge is failing to localize the search bar. Search behavior and sorting algorithms vary across languages and regions, making it essential to adapt the functionality accordingly. Error messages also need proper localization and not just direct translation. Mapping error codes to localized messages proves more effective than translating entire strings.

Moreover, the lack of versioning for translations can be disastrous, particularly when business requirements change frequently. And let’s not forget the importance of accessibility translations. Ignoring them can significantly harm the user experience, especially for visually impaired individuals.

While machine translations like Google Translate might seem tempting, they often fall short in accurately conveying the intended meaning. That’s why collaborating with local teams who understand the cultural nuances and potential issues is crucial for successful localization.

I hope this discussion has shed light on the challenges and best practices involved in frontend localization. If you have any questions or want to share your experiences, feel free to reach out. Thanks for tuning in today, and remember, there’s always room for continuous improvement.