When I evaluate a tool that promises to help me build software, a framework, a starter, a scaffolding generator, anything that claims to save me from writing the boring parts myself, I run one small test before I read a single page of its documentation: I add a second language and I ask for a date in the local format. Almost everything I have ever tried fails right there. The translations turn out to be files you duplicate by hand and pray over, the date is hardcoded into a shape that makes sense on one side of one ocean, and the answer from the issue tracker, when there is an answer at all, is that internationalization is on the roadmap, which anyone who has waited on a roadmap knows is a polite word for never.
The arithmetic that follows is simple, and it is the same arithmetic that eventually produced the framework we build on: if I have to adapt the tool that was supposed to do the adapting, to teach it the most basic fact about the world, which is that people speak different languages, then I might as well stretch a little further and build the thing myself from scratch.
Bread Before Beauty
I keep returning to how ordinary this requirement is, because outside of software nobody treats it as a requirement at all. You go to the bakery in the morning and you buy your bread in your own language without thinking about it, your coffee is ordered in your own language and in domestic quantities, and nobody anywhere in that transaction is being international. Try ordering three deciliters of Pils in London and watch what happens, because the request is grammatically perfect English and completely useless, since the quantity belongs to a different world. Daily life is localized to its bones, and software, which claims to serve daily life, mostly is not.
People do not buy their bread in a foreign language, and they should not have to use their software in one either.
Postal Codes Do Not Forgive
If this matters for the wide public, it matters double for the specialized applications we build for companies, because those apps exist precisely to handle local things that exist nowhere else. Compare postal codes around the world for five minutes and then try to fit a British address into a form that was designed for Slovenian ones: the validation rejects a perfectly real address, the user cannot complete the task, and the application has failed at its one job, no matter how pleasant it is to look at.
An application that expects nonsense input can be designed by Jony Ive and still be unusable.
Translation Is the Smallest Part
What surprises people who have never done the work is that translation, the part everyone thinks of first, is the smallest portion of the whole experience. There is formatting, because the same day is written 30. 7. 2026 where I live and 7/30/2026 somewhere else, and one of those two strings reads as nonsense depending on which side of the ocean you are standing on, while a quiet decimal comma changes the meaning of every number in a finance app. There is positioning, because the currency symbol does not sit in the same place in every language and the calendar does not start on the same day of the week. Even the addresses of pages want localizing, and we have written separately about why pages and apps need different URL strategies for that.
And then there are plurals, my favorite example, because they shatter the comfortable assumption that every language has a singular and a plural and nothing in between. Slovenian has a dual, so one ticket, two tickets, three tickets and five tickets each take a different form: ena vstopnica, dve vstopnici, tri vstopnice, pet vstopnic. Any system that stores exactly two strings per message, one for one and one for many, simply cannot speak my language correctly, and it cannot speak several of our neighbors' languages either.
Four Languages Is the Floor
I come from Slovenia, and the geography of my market settled this argument for me long before I wrote a line of code, because the former Yugoslavia was and remains our closest market, which means an app that speaks only Slovenian is already too small and an app that speaks only English was never in the running at all. For us, a minimum of four languages in any given application is not an ambition or a differentiator but plain arithmetic about where our users live.
That is why our own framework inverts the usual order of things, supporting many languages out of the box, with translations living in the database and JSON files where the people doing the translating can actually reach them, and with dates and numbers formatted through the proper locale machinery rather than string concatenation. Localization is not a feature we add to an application, it is one of the two things the application is, the other being what it does.
None of this asks you to care about the languages I care about, because the point travels to any market: your users were buying bread in their own language this morning, and the least your software can do is meet them there. And if a tool cannot write the date the way your user expects to read it, then every feature built on top of that tool is standing on a crack.