Home

The Lost Message

Welcome to "Continuous Improvement," the podcast where we explore personal growth, life lessons, and finding ways to become the best versions of ourselves. I'm your host, Victor, and today we're diving into a story about relationships, personal sacrifices, and the pursuit of maturity.

Picture this: it all started with a simple WhatsApp message. I received a late-night greeting from someone I never expected to hear from again -- my ex-girlfriend, Joanne, from Hong Kong. Little did I know that this message would bring back memories and trigger a reflection on personal growth and continuous improvement.

Joanne and I had different aspirations and approaches to life. She focused on practicality, aiming for excellent grades, a successful career, and financial security. Meanwhile, my passion for science led me on a quest to unravel the mysteries of the universe.

Our differences often became apparent when it came to making choices on even the simplest things. For example, I suggested going to my favorite hawker center for an affordable and tasty meal, but Joanne longed for more luxurious experiences.

As time went on, I realized that money became a point of contention in our relationship. Joanne believed that ambition and financial success were markers of maturity and responsibility. And as my career advanced, so did the pressure to meet her expectations.

I finally got a pay raise and decided to reward myself with a new car, a shiny blue Mini Cooper. Ironically, Joanne seemed more thrilled about it than I did. I found myself playing the role of a personal chauffeur, giving free rides to not only Joanne but also her family and friends.

But the costs of maintaining the car and meeting Joanne's lavish desires began to weigh heavily on my finances. I had to cut back on my parents' allowance, which left me feeling guilty and conflicted.

Our differences in priorities and perspectives continued to create tension. We argued over trivial matters, with Joanne repeatedly questioning my level of maturity. Our personalities clashed, I was introverted and preferred the company of computers, while she thrived on social interactions and the prestige of her financial career.

After 18 months of dating, Joanne made a life-altering decision. She felt that she had to choose between staying with an "immature guy" or exploring other possibilities. It was a painful breakup, and I found myself questioning my own maturity once again.

Despite the breakup, we tried to remain friends. But as time went on, it became clear that the dynamic had changed. Joanne never reciprocated the gifts I sent on her birthdays, and I had to accept that some relationships are not meant to be salvaged.

Time passed and wounds healed, but sometimes life has a way of throwing unexpected curveballs. Joanne reached out again, inviting me to her wedding. I pondered attending, but ultimately chose to focus on my own growth and development. I had moved on and realized that dwelling on the past would only hinder my progress.

Relationships are like a continuous journey of trial and error. It's through these experiences that we learn about ourselves, our values, and what we truly desire in life. Looking back, I see that Joanne's perception of maturity was just one perspective among many.

If there's one lesson I can offer from my own story, it's this: continuous improvement starts by understanding ourselves and being true to our own values. We should never compromise our growth and happiness for someone else's expectations.

Thank you for joining me on this episode of "Continuous Improvement." Remember, life is a never-ending process of growth, and the pursuit of maturity is a personal journey we must all navigate. Until next time, keep striving for the best version of yourself.

失落的訊息

一個晚上，我的手機螢幕亮起了一條WhatsApp訊息，讓我驚醒。以為是緊急事態，我很意外發現只是一個女孩說嗨。"Victor, 你過得如何？"來自香港的前女友Joanne發來的訊息。"你收到我的訊息了嗎？"她問道，"為什麼你沒有回覆？"

"我在從香港搬到新加坡的時候換了手機號碼，"我解釋道。當我說著的時候，我心中湧現出對她的思念，想知道遺失的訊息是什麼。

我們就讀不同的大學，選擇不同的學位。我對科學有興趣，選擇化學作為主修。我的目標是揭開宇宙的神秘面紗。和我不同，Joanne 是實際的。她進入會計領域，希望取得好成績，建立穩固的職業生涯，並獲得豐厚的薪水——同時找到一個合適且富有的丈夫。

在我們的一次午餐約會中，我建議道，"讓我帶你去我最喜歡的小販中心吃5美元的蛋炒飯。"她不滿意，回答說，"不，我想去日本餐廳吃美味的壽司，即使只是幾顆米。"我嘗試改變話題，談論我們的度假計劃。"我們去新加坡的圣淘沙島旅遊如何？"我提議。"不，我想去歐洲，去看瑞士的雪山，"她堅持。

金錢是個絆腳石。"這不僅僅是關於金錢，"Joanne詳述道。"這關乎你的抱負，去努力工作，賺更多錢，提升你的社會地位。這就是一個負責任的成年人該做的。"即使我長時間工作，但量子力學、薛丁格方程式和黑洞理論的專業知識並沒有讓我得到高薪工作。"Victor，你能不能成熟點？"她問。

最終，我換了工作，並得到了加薪。隨著收入的增加，我覺得需要提升自己的生活水平。當我告訴Joanne我正在考慮買車的時候，她立刻驚喜地叫道，"好呀！"我買了一輛藍色的Mini Cooper，她對此比我更興奮。

我開始每天用我的新車接送Joanne。我就像她的私人司機，經常免費接送她的家人和朋友。雖然維護車輛的費用很高，但維護和Joanne的關係更是昂貴。

Joanne非常喜愛名牌手袋。即使我無法正確地說出她最愛的牌子的名字，我也必須送她奢侈的禮物。不管是Gucci還是Chanel，其中任何一個手袋都會花掉我好幾個月的薪水。為了償還我的信用卡欠款，我不得不削減我給父母的零花錢，這讓我感到內疚。

在一頓浪漫的日本餐廳晚餐中，Joanne問，"Victor，你是不是比愛你的車還愛我？"我試圖以幽默來緩解這個緊張的時刻，答道，"當然，我愛我的車，"但她並不覺得好笑。我們繼續為些小事吵架。"Victor，你能不能更成熟一點？"她又問了。

我們是一對性格迥異的情侶。我是一個宅男軟體開發者，我更喜歡與機器交談而不是人。另一方面，Joanne是一家銀行的外向型關係經理，以軟性但堅定的口吻銷售金融產品。那意味著什麼？這意味著她賺的錢比我多。

經過18個月的交往，Joanne決定是時候做一個重要的選擇：繼續與這個"不成熟的傢伙"交往還是尋找替代品。在我們的一次通常的外出中，我感覺到有些不對勁。她變得冷淡，拒絕握住我的手。最後，在一個難熬的沉默之後，她說道，"Victor，我們分手吧。"我的心像是被撕裂般疼痛，我努力地忍住不流淚。"Victor，能你不能更成熟一點？"她再次這麼說。

我們在分手後仍然是朋友。雖然我依然在她生日時送她禮物，但她從未回贈。時間總能愈合一切，有一天，她的一條出乎意料的訊息突然出現。內容是，"嘿 Victor，我要結婚了。你想來參加嗎？"我有些惱怒，開始打"恭喜"，但我從未按下送出。反倒是刪除了這則訊息。"我為什麼要去呢？"我對自己這麼想。

我後來在Facebook上看到了她的婚禮照片。她看起來很漂亮，她的丈夫看起來很富有，受過良好的教育。"真是浪費錢，"我這麼想，但很快就把那個念頭拋到腦後。我已經走出來了。人際關係建立在試錯上，大多是錯誤。如果你不想重蹈覆轍，就繼續看下去。我有很多關於如何應對生活挑戰的建議。

Fortune

When I was a kid, my mom always told me, "Study hard! Otherwise, you could end up like that garbageman." The message was clear: I didn't want to collect trash for a living. Motivated by this fear, I worked hard in school and eventually went to university.

About a decade ago, I graduated with a bachelor's degree in chemistry. However, as Hong Kong is an international finance center, job opportunities for science graduates were scarce.

My first job had nothing to do with my degree. I worked at Uniqlo, a Japanese clothing store, as an entry-level sales associate with long hours. This job felt like a punishment. Like Sisyphus in Greek mythology, who endlessly pushes a rock up a hill only for it to roll back down, I would fold clothes neatly just for customers to come in and mess them up. This cycle led me to question the value of my education.

Eventually, I quit and went to Australia on a working holiday. I took up various jobs to survive, one of which was, ironically, a garbageman during a New Year's Eve event. The stench of alcohol and vomit was unbearable. It was a wake-up call: had I listened to my mom, maybe I wouldn't have found myself in such a role.

After a year in Australia, I returned to Hong Kong. Still unable to secure a job in my field, I transitioned careers by learning programming and becoming a software engineer. Yet, working at a reputable consulting firm, I was plagued by imposter syndrome. My solution was further education. I pursued a part-time master's degree in computer science and later, an MBA, hoping for a better career and to avoid ending up like the garbageman I once was.

During my MBA, I met Jonathan, a senior sales director at a software company. He helped me transition into a role as a technical sales consultant. This job required me to entertain clients, often through excessive drinking—something I had vowed never to do again.

One unforgettable night, during a business dinner with a major client, the volume of alcohol consumed pushed me to the edge. I excused myself to vomit in the restroom, a low moment that made me question my choices. I found myself recalling my days as a garbageman in Australia, the very position I'd tried so hard to avoid.

My new job also involved traveling across China and entertaining clients at KTV lounges, which often led to morally ambiguous situations. Despite my seemingly fortunate circumstances, I couldn't help but feel sympathy for the women working there. They didn't have the luxury to prioritize education and likely faced hardships I couldn't imagine.

Reflecting on my journey, I realize my mom was right—education is invaluable. Yet, here I was, entertaining clients with drinks just like the women at KTV. Their struggle and mine were not so different. So, before passing judgment on others, remember: every job is the result of a story you may not know. Treat everyone with the respect they deserve, regardless of their job title. Thank you.

Fortune

Hello and welcome to Continuous Improvement, the podcast dedicated to personal growth and professional development. I'm your host, Victor, and today we have an inspiring story of resilience, career transitions, and the importance of not judging others based on their job titles.

When we are young, we often receive advice from our parents about the importance of education and the fear of ending up in certain professions. But sometimes life has different plans for us. Today, I want to share with you an incredible journey of self-discovery and continuous improvement, based on a blog post titled "Every Job Has a Story" by an anonymous author.

Our story begins with the author's mom warning them to study hard or else they might end up as a garbageman. Fueled by this fear, the author worked hard and obtained a chemistry degree. However, job opportunities in their field were limited, forcing them to take a job at a clothing store.

Folding clothes in the store felt like a punishment, similar to Sisyphus endlessly pushing a rock up a hill. The author began questioning the value of their education and their chosen career path. Their journey took an unexpected turn when they worked as a garbageman during a New Year's Eve event in Australia.

The experience of being a garbageman, surrounded by the stench of alcohol and vomit, became a wake-up call for the author. It made them realize the importance of listening to their mom's advice and avoiding ending up in a job they had initially looked down upon.

Returning to Hong Kong, the author struggled to find employment in their field. Determined to change careers, they taught themselves programming and became a software engineer. Yet, imposter syndrome plagued their confidence. To overcome this, the author pursued further education—a part-time master's degree in computer science and later, an MBA.

But even after transitioning into a technical sales consultant role, the author found themselves repeating past mistakes. This job involved entertaining clients through excessive drinking, similar to the days when they were a garbageman.

A low point came during a business dinner with a major client when the author excused themselves to vomit in the restroom. This humbling experience reminded them of their earlier struggles in Australia and the job they had desperately tried to avoid.

The author's professional life also included encounters with KTV lounge culture, where they saw the challenges faced by women working in such environments. They realized that the struggle of these women and their own struggles were not so different.

Reflecting on their journey, the author gained a profound understanding of the value of education and the importance of never judging others based on their job titles. They share this message with us: every job has a story, and it's crucial to treat everyone with the respect they deserve.

And that concludes our story today. Remember, continuous improvement isn't just about personal growth; it's also about understanding and respecting the journeys of others. Thank you for joining me on this episode of Continuous Improvement. I'm Victor, your host, and I look forward to sharing more inspiring stories with you in the future.

財富

當我還是個孩子時，我的媽媽總是告訴我，“要努力讀書！否則，你可能會像那個垃圾工人一樣。”這訊息十分清楚：我並不想靠收集垃圾來謀生。由這種恐懼所驅動，我在學校努力學習，最終進入了大學。

大約十年前，我以化學學士學位畢業。然而，由於香港是國際金融中心，理科畢業生的就業機會非常有限。

我的第一份工作與我所學的專業無關。我在日本的服裝店Uniqlo做了一份初級銷售員的工作，每天工作時間很長。這份工作讓我感覺像是在受罪。就像希臘神話中的西西弗斯，不停地將石頭推上山坡，只是為了讓它滾下來，我會整齊地摺好衣服，然後客人進來就把它們弄亂。這種情況讓我質疑我受的教育的價值。

最終，我辭職去澳洲做了一年的打工度假。我做了各種工作來生活，其中一份工作，諷刺的是，在新年夜晚會做了一名垃圾工人。醉酒和嘔吐的惡臭令人難以忍受。這是一個警醒：如果我聽了我媽媽的話，也許我就不會找到自己在這樣的角色中。

在澳洲呆了一年後，我回到了香港。仍然無法在我專業領域找到工作，我轉變了職業，學習编程並成為一名軟件工程師。然而，在一家有聲譽的顧問公司工作，我卻困擾於冒牌者症候群。我找的解決辦法是繼續學習。我攻讀了一個兼職的計算機科學碩士學位，然後是工商管理碩士學位，希望能有更好的職業生涯，並避免變成我曾經做過的垃圾工人。

在我攻讀MBA期間，我遇到了Jonathan，他在一家軟件公司擔任高級銷售總監。他幫助我轉行，成為一名技術銷售顧問。這份工作需要我娛樂客戶，通常是通过過度飲酒——這是我發誓再也不會做的事情。

一個難以忘懷的夜晚，在與一個大客戶的業務晚宴上，我因為飲酒過度而感到極度不適。我藉口到洗手間去嘔吐，這一刻讓我反思我的選擇。我回憶起我在澳洲當垃圾工人的日子，那正是我努力避免的境地。

我的新工作還涉及到在中國各地出差，並在KTV中娛樂客戶，這經常帶給我道德上的困境。儘管我看似有了好運，但我卻無法不對那裡工作的女性過度同情。她們沒有優先考慮教育的奢侈，在我無法想象的困境中掙扎。

在反思我的經歷時，我體認到我媽媽是對的——教育是無價的。然而，我一方面在如KTV這樣的地方用酒精娛樂客戶，與那些KTV裡工作的女性一樣。我們的掙扎並無太大區別。所以，在對他人妄下評論之前，記得：每一份工作背後都有一個你可能不知道的故事。不論他們的職位如何，把每個人都當作應得的尊重對待。謝謝你。

Jobs to Be Done

I'm sure you've experienced this while shopping online. You find a product at an attractive price and decide to purchase it, using internet banking for the payment. However, an error message appears that says, "Sorry, something went wrong; the transaction failed. Please try again later." It's quite annoying, right? Maybe you've had enough and decide to let it go. But before you do, consider the "task at hand" when you're using a service or a product. This issue is crucial not only for the vendor but also for you.

In the past, I worked as a technical lead in a bank and realized that the financial industry is full of acronyms. HSBC, the bank where I used to work, has a rather cynical acronym of its own: "How Simple Becomes Complicated." If you think that pressing a button on an internet banking site is simple, you're mistaken. The process is incredibly complex. The business team gathers requirements, the design team creates the layout, and the development team writes, tests, and deploys the software. On average, it takes two weeks just to alter a single character on a webpage.

I was part of the ASD-ASP team, which stands for Accelerated Scaled Delivery in the Asia Pacific, and my responsibility was to create regional features. If you're from Malaysia, you've undoubtedly used PayNet's FPX (Financial Process Exchange) service. In Singapore, a similar service is known as PayNow.

After months of hard work, I built the feature and released it into production. I thought, "Finally, my job is done!" Now, you can choose FPX as a payment option when purchasing earphones on Shopee. You complete the purchase after clicking the "pay" button, and I felt pleased with my work.

However, imagine being visually impaired and relying on an accessibility tool to navigate the website. You'd be unaware that you have only 10 minutes to complete the transaction. The accessibility tool would read aloud every second, counting down and leaving you no time to complete your task. This was a real pain point that I hadn't considered. I didn't receive feedback from actual users until much later.

I tried to address this issue, but it was nearly impossible in such a large company. When I spoke to business analysts, they said their job was done, as they were mainly concerned with profits. The designers claimed their job was done, preferring to create flashy animations rather than focus on accessibility. The engineers also insisted their job was done; they wanted to move on to machine learning and blockchain technologies.

I couldn't persuade my colleagues, partly because I wasn't aware of Aristotle's three modes of persuasion: Ethos, Logos, and Pathos. But now, I'd like to hear your thoughts. Before you use a product or service, consider what job it is meant to accomplish.

Clayton Christensen, a Harvard Business School professor, has articulated this approach. His thesis poses the question, "What task does a person hire a product to do?" Understanding this job makes it easier to identify ways to improve the product.

So when I use online banking, my job is to complete the transaction. I don't care about fancy animations or whether the system uses AI or cryptocurrencies. The product team had been asking the wrong questions and trying to solve the wrong problems. We must outperform our competitors and ensure successful transactions for everyone, including those who are visually impaired. The Malaysian government even has a regulatory requirement that FPX transactions must be successful 70% of the time, with penalties for non-compliance.

The job isn't done, and there's an elephant in the room. The next time you encounter a problem with online banking, ask yourself: What is the "job to be done?" Empathize with others who face the same issue, especially those with visual impairments. As a customer, communicate your needs to the bank. Help bring about change by voicing your concerns. This matter is not to be taken lightly. Be the change you wish to see in the world.

Jobs to Be Done

Host (Victor): Welcome to another episode of Continuous Improvement, the podcast all about personal and professional growth. I'm your host, Victor, and today we're going to dive into a thought-provoking topic: the importance of understanding the job to be done when using a product or service.

Have you ever encountered an error message during an online transaction that left you frustrated? Join the club! Today, I want to share a personal experience that made me realize how crucial it is for both vendors and customers to consider the task at hand before using a service or product.

In my previous role as a technical lead in a bank, I discovered something quite fascinating. The financial industry is filled with acronyms, and even the banks have their own cynical ones. For instance, the bank I worked for, HSBC, had an acronym that stood for "How Simple Becomes Complicated." It perfectly captures the complexity behind seemingly simple tasks, like pressing a button on an internet banking site.

The process of delivering these services involves multiple teams working together. The business team collects requirements, the design team creates the layout, and the development team writes, tests, and deploys the software. Believe it or not, it often takes up to two weeks just to make a tiny alteration to a webpage.

During my time as part of the ASD-ASP team, responsible for creating regional features, I had the opportunity to develop services like PayNet's FPX in Malaysia and PayNow in Singapore. I was proud of my work, making online transactions smoother for customers.

However, I soon realized that there was an important aspect I hadn't fully considered — accessibility. Imagine being visually impaired and relying on assistive tools to navigate a website. It never occurred to me that the tools would unknowingly interrupt the transaction process by constantly announcing the countdown of remaining time.

I wanted to address this issue, but it proved to be quite challenging in such a large organization. The business analysts were mainly concerned with profits and considered their job done. The designers focused more on flashy animations rather than considering accessibility, and the engineers were already looking ahead to explore emerging technologies like machine learning and blockchain.

Sigh I wish I had known about Aristotle's three modes of persuasion back then - Ethos, Logos, and Pathos. These powerful tools could have helped me advocate for change and show the importance of considering the needs of all users.

Now, I'd love to hear your thoughts on this matter. Before using a product or service, have you ever considered the job it is meant to accomplish? What improvements would you like to see in the services you use?

Clayton Christensen, a renowned professor from Harvard Business School, introduced the concept of understanding the job that a person hires a product to do. This understanding allows us to identify areas for improvement and create a better experience.

When I use online banking, my job is simply to complete the transaction. I don't care about flashy animations or the latest technologies. I want a smooth process that ensures successful transactions for everyone, including those with visual impairments. Did you know that in Malaysia, the government has regulations requiring a 70% success rate for FPX transactions, with penalties for non-compliance?

So, next time you encounter an issue with online banking or any other service, ask yourself: What is the job to be done? Think about others who may face similar challenges, especially those with different abilities. Don't forget, as a customer, you have a voice. Communicate your needs to the service providers and help drive positive change.

Remember, this is not a matter to be taken lightly. We each have the power to be the change we wish to see in the world.

That's all for today's episode of Continuous Improvement. I hope you found this discussion thought-provoking and that it inspires you to consider the job to be done when using products or services.

If you enjoyed this episode, don't forget to subscribe to our podcast and leave us a review. We always appreciate your feedback.

Until next time, keep striving for improvement in every aspect of your life. This is Victor, signing off.

[End of the podcast]

需要完成的工作

我確定你在網上購物時經歷過這種情況。你找到一個價格吸引的商品並決定購買它，使用網上銀行進行付款。然而，出現了一條錯誤信息說："對不起，出了點問題；交易失敗。請稍後再試。"這很煩人，對吧？也許你受夠了，決定放棄。但在你這樣做之前，考慮一下當你使用服務或產品時的"手頭任務"。這個問題對供應商和你都至關重要。

在過去，我曾在一家銀行擔任技術主管，我發現金融業充滿了縮寫。我以前工作的銀行匯豐，有一個相當諷刺的自稱："How Simple Becomes Complicated." 如果你認為在網上銀行網站上按一個鍵就很簡單，那你就錯了。這個過程非常復雜。商業團隊收集需求，設計團隊創建佈局，開發團隊撰寫，測試並部署軟件。平均而言，僅更改網頁上的一個字符就需要兩周的時間。

我是ASD-ASP團隊的一員，這意味著我在亞太地區負責加速規模交付，我負責的是創建區域功能。如果你來自馬來西亞，你無疑已經使用過PayNet的FPX（Financial Process Exchange）服務。在新加坡，一個相似的服務被稱為PayNow。

經過幾個月的辛勤工作，我創建了該功能並將其投入生產。我想："終於，我的工作完成了！"現在，當你在Shopee上購買耳機時，你可以選擇FPX作為付款方式。你在點擊"支付"按鈕後完成了購買，我對我的工作感到滿意。

然而，想像一下如果你是視障人士，依賴輔助工具來導航網站。你不會知道你只有10分鐘的時間可以完成交易。輔助工具會大聲讀出每一秒，倒數時間，讓你沒有時間完成你的任務。這是一個真正的痛點，我當時沒有考慮到。直到很久以後我才收到實際用戶的反饋。

我試圖解決這個問題，但在這樣一家大公司中幾乎不可能。我與商業分析師交談，他們說他們的工作已經完成了，因為他們主要關心的是利潤。設計師宣稱他們的工作已經完成，他們更喜歡創建華麗的動畫，而不是關注輔助功能。工程師們也堅持他們的工作已完成；他們想轉向機器學習和區塊鏈技術。

我無法說服我的同事，部分原因是我不瞭解亞里士多德的三種說服方式：Ethos、Logos和Pathos。但現在，我想聽聽你的想法。在你使用產品或服務之前，考慮一下它應完成的工作是什麼。

哈佛商學院的教授克雷頓·克里斯蒂森森（Clayton Christensen）闡述了這種方法。他的論文提出了問題："一個人僱用一種產品來完成什麼任務？"理解這個任務會使找出改善產品的方法變得更容易。

所以當我使用網上銀行時，我的工作就是完成交易。我不在乎華麗的動畫或者系統是否使用了AI或加密貨幣。產品團隊一直在問錯誤的問題，並嘗試解決錯誤的問題。我們必須超越競爭對手，確保所有人，包括視覺障礙者，都能成功交易。馬來西亞政府甚至有規定要求，FPX交易必須成功率達到70%，否則將面臨處罰。

工作還沒有完成，還有一頭大象在房間裡。下次你在網上銀行遇到問題時，問問自己：什麼是"需要完成的工作"？對那些面臨同樣問題的人，尤其是視障人士，表示同情。作為顧客，將你的需求告訴銀行。通過表達你的憂慮來推動變革。這個事情不容忽視。你要做你想在世界上看到的變化。

Working with Localization on Websites and Mobile Apps in APAC

First and foremost, why does this blog post exist? What question are we trying to answer? A colleague of mine in the UK specifically asked me about localization, tools, and best practices—or lack thereof—in the Asia-Pacific region.

Since my company has expanded to various locations in the APAC area, including Singapore, the Philippines, and Vietnam, I am here to discuss frontend localization.

You'll likely encounter the term "i18n" in frontend development. Ever wondered what the 18 represents? It’s not 18 different languages; it's the number of letters between the first 'i' and the last 'n' in the word "internationalization."

Before diving in, let me introduce myself. I used to work as a technical lead in a bank and am sharing my previous experiences in the banking sector—a field rife with acronyms. You'll quickly realize that everything in banking involves an acronym, seemingly to sound more professional and obfuscate meaning.

I worked for HSBC, an acronym that humorously stands for "How Simple Becomes Complicated." Changing even a single character on a website is far from straightforward. The complicated process involves multiple teams—from business requirements to code review, quality assurance, and deployment—often taking up to two weeks just to change one word on a production webpage.

I was part of a team called ASD-ASP, which stands for Accelerated Scaled Delivery in the Asia-Pacific. My role involved building regional features for web and mobile platforms, such as FPX in Malaysia and PayMe for businesses in Hong Kong. The examples I mention are drawn from real-life experiences.

For instance, let's consider the page displayed below:

Notice anything wrong? The issue lies with the timer. Imagine being visually impaired and relying on an accessibility tool to navigate the page. You would be clueless about the remaining time to complete the transaction. Worse still, if you try to have the tool read the timer aloud, it will count down every second, leaving you no time to complete the transaction.

We used Adobe Experience Manager (AEM) to build this page. While AEM allows non-technical team members to make updates, the reality often involves frontend engineers making text changes or building dialogues using XML, creating an unnecessary layer of work.

In terms of mobile, our internal tools written in Python scripts read copy in various languages from a Confluence page to generate localized JSON files. The developer then includes this file in the app. This approach often creates more problems than it solves, as I'll explain shortly.

The copy team usually labels frontend designs using a Confluence page. This can easily go awry, as design screenshots often become outdated and engineers might use inconsistent keys to represent the same thing. Reusing keys across different pages leads to unexpected side effects when values are updated.

Next, consider the screen below for potential localization issues:

Here are five major pitfalls:

1. The term "country" can be problematic. For instance, listing Taiwan or Hong Kong as separate countries can be illegal due to national security laws.

2. Failing to localize the search bar is another issue. Search behavior and sorting algorithms vary between languages and regions.

3. Error messages also need localization, not just translation. It's better to map error codes to localized messages instead of translating entire strings.

4. Lack of versioning for translations can be disastrous, especially when business requirements change frequently.

5. Ignoring accessibility translations can be detrimental to the user experience, especially for visually impaired individuals.

Furthermore, machine translations like Google Translate are highly discouraged. For more successful localization, collaborate with local teams who can readily identify potential issues.

Any questions about localization? Feel free to ask. :)

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.