What Changes When a Hong Kong Product Has to Work in Two Languages
The brief that arrives too late
A founder in Sham Shui Po shows us a prototype on a Thursday afternoon. The screens are in English, the spacing is tight, and the buttons read "Continue", "Confirm", "Done". Then, near the end of the meeting, they add one line: it also has to work in Chinese, because half the customers will never open the English version.
That line used to be a task for the last week of a project. It is no longer. On the products we ship now — a booking site, a study app, a shop — the second language is part of the product from the first screen, and leaving it until the end is how a layout breaks the week before launch.
Two readers, not one reader twice
Hong Kong does not split neatly into "English users" and "Chinese users". The same person books a court in Chinese at lunch and reads the receipt in English that evening because the card statement is in English. A parent searching for a secondary school reads the school name in Chinese and the notes in English, in the same session, on the same phone.
So the job is not to produce a second copy of the product. It is to let one person move between the two without losing their place. A language toggle buried in settings fails that test. The person has already decided the screen is not for them and closed it.
Where the layout breaks
Chinese copy is shorter than the English it replaces, and that is the part people plan for. The part they miss is the opposite case.
A button sized for "Pay" becomes a wrapped two-line button once it reads "Pay with FPS". A table column wide enough for "Status" clips "Pending review" and shows fine for "待確認". Navigation that fits four English words overflows once one of those words is a compound the translator refuses to shorten, because shortening it changes the meaning.
We stopped trusting a layout that has only been seen in one language. A screen is not finished until both versions have been opened on a phone, not on a desktop preview where everything fits. If a label truncates, the fix is a shorter label or a wider row, decided per screen — not a smaller font across the whole product, which makes the Chinese version harder to read on the MTR.
Labels are the product
Most of the words in a product are not sentences. They are buttons, statuses, empty states, and error lines. Those are exactly the words a translator working from a spreadsheet gets wrong, because they have no screen in front of them.
"Book" can mean reserve a court or reserve a copy of something. In a venue product it must mean the first, every time, or a player hesitates at the one button that takes their money. "Session" in a community product means a game with a time and a place, not a login session. Translate it as the second and the screen stops making sense.
The fix is a short glossary, written before translation starts, owned by someone who has used the product. Ten words is enough: the verbs on the main buttons, the status names, and the one noun the whole product is about. Hand that over with the screenshots, not instead of them.
Which language is the default
This is the decision that gets made by accident. Whatever language the prototype was designed in becomes the default, and everyone else clicks through a switch.
Ask where the user is when they first open it. A learner driver revising on a bus will start in whichever language the app store listing used. A parent comparing schools late at night starts in the language of the link a friend sent on WhatsApp. The store listing, the shared link, and the first screen should agree. If the listing is in Chinese and the app opens in English, the first impression is that something loaded wrong.
Remember the choice after that. Reopening the app into the opposite language feels like the product forgot them. So does sending the confirmation email in the other language — the email is the record they forward to a spouse, and it should match the screen they booked on.
What we ask for now, before drawing anything
Three things, and none of them is a translation budget.
Which screens does a first-time user see in each language, and which language do they arrive from. Which ten words carry the product, so they can be agreed once and reused. And who reads both versions before launch — not a translator alone, someone who would actually use it.
The last one is the one that gets skipped. A fluent reader catches a button that says the right thing in a slightly wrong tone. A user catches the button that says the wrong thing confidently. We have watched a correct translation of "confirm" read, in context, as "the booking is already confirmed", which is a different fact and a good way to collect angry messages.
The week it saves
Treating the second language as a late task does not only risk a clipped button. It hides the screens that were never designed for both readers: a chart with no room for a bilingual legend, a form that asks for a name in one order, a notification that assumes one script.
Find those in week two and they are a layout change. Find them the week before launch and they are a delay. The products that feel finished in both languages are the ones where both languages were on the table from the first review, not the ones that were translated the most carefully at the end.