Insights Content
Interface strings belong in the database too
The line between code and data gets drawn from the engineer point of view. Judged by who actually needs to change it, that line sits in the wrong place.
The line was in the wrong place
This site used to work that way itself: content — services, case studies, FAQs — lived in the database, while navigation labels, the hero headline, form labels and error messages were hardcoded in the frontend. The line looks natural. This is code, that is data. But it had been drawn from the engineer point of view.
Judged by who needs to change it
The person who wants to reword the hero headline is the same person who wants to reword a service description — and they want to change the headline more often, because it is the sentence most visitors read. Leaving it in code is a rule that says changing one line of copy requires a deployment, and that rule is enforced not by the product manager but by an engineer calendar.
The cost is a very flat table
There is no second mechanism: an interface string is a row keyed by locale and key, edited in the same back office, served through the same cache. The only differences are that it is flat and that we choose the keys. Deliberately not nested — nesting means the back office cannot answer "where does that sentence live" with a single search box, which is the one feature an editor actually needs.
A missing key renders as the key
A small detail that decides whether the whole arrangement decays: a key with no value renders as the key string, not as an empty string. A blank space on a page looks like a design decision and can survive for months. The text nav.pricing sitting in the middle of the navigation bar gets fixed the same afternoon.
A benefit we did not anticipate
The three locales can now diverge on their own schedule. If the Japanese copy should be shorter, it does not have to wait for anyone to settle the Chinese and English versions, because they are three rows rather than three columns of one row. An architecture built around a translations table cannot do this — and content does diverge.
What should stay in code
Not every string should move. Error codes, log messages and anything written for machines belong in the source, because the people who change them are engineers and the changes should be reviewed alongside the code. The test never changes: who will want to edit this, and what do they expect to happen when they do.