Skip to content

Insights ·

Four languages from the first commit

Foodpoint ships in four languages. The interesting part is not the translation work — it is everything that has to be true before translation is even possible.

Malaysia is not a single-language market

An app about Malaysian food that only speaks one of the languages its users eat in is describing a different country. That is not a diversity statement, it is a product accuracy statement: the names of dishes, the names of stalls and the words people use to search for both are distributed across several languages at once, often inside the same sentence.

So multilingual support was never a later phase. It was a property of the first screen.

Translating later is a rewrite wearing a costume

The received wisdom is to ship in one language and internationalise once there is traction. On a content-light app that is defensible. On anything with real interface surface it is a trap, because the expensive parts of localisation are not the strings.

What actually costs money later is every place the single-language assumption leaked into something structural:

  • Layouts sized to the length of one language's words, which break the moment a label is 40% longer.
  • Sort and search behaviour built around one collation, which quietly returns wrong results for another.
  • Dates, numbers and currency formatted by string concatenation because it looked fine in the original locale.
  • Copy written as sentence fragments stitched together in code — the single hardest thing to translate, because the translator never sees the whole sentence.
  • Assets with text baked into them, which is a design problem discovered at translation time.

What it costs to do up front

Less than the reputation suggests, provided it is a constraint from the start rather than a migration. Strings live outside the components, layouts are built to flex, and nothing formats a date by hand. Those are all things worth doing in a single-language app anyway; the second language just removes the option of skipping them.

The visible cost is that every feature carries a translation step before it can ship, which is a real tax on cadence and has to be planned for. The invisible saving is that no release is ever blocked on a localisation project, because there is never a localisation project.

The test that catches it early

Add a second language on day one, even a deliberately bad one. A pseudo-locale that lengthens every string by half and wraps it in brackets will surface almost every layout assumption in an afternoon, long before a translator is involved.

If the interface survives that, adding the real languages is the easy part.

More from Mavis Digital

  • Enforcing local ownership in code, not community guidelines

    Foodpoint lists local-owned food businesses only. That rule lives in the product rather than in a policy document, and the difference is the whole design.

  • The stage everyone skips

    Every product we run goes through four stages, and keeps going back through them. Under deadline pressure, teams reliably skip one of them, and it is almost never the one they would admit to.