--- title: "Multilingual Support and Localisation in a Business Application" description: "Adding a second language to a finished application usually costs more than building it for two from the start. What gets underestimated, and why translating the interface is only the beginning." canonical: "https://interfase.sk/en/news/multilingual-support-and-localisation-in-a-business-application" lang: "en" last_updated: "2026-10-23" --- # Multilingual Support and Localisation in a Business Application > Adding a second language to a finished application usually costs more than building it for two from the start. What gets underestimated, and why translating the interface is only the beginning. Published: 2026-10-23 - Translating the interface is the smallest part of the work; dates, currencies, text length and content stored in the database cost more. - Strings have to live outside the code from the start — extracting them from a finished application costs several times as much. - Assembling sentences from fragments falls apart in another language because of inflection and word order; translate whole sentences. - Translations are living content, not a one-off task — without a process, new features appear in one language only. The application has run in Slovak for a year, the company opens a branch in Austria, and the request lands: "let's add German". It sounds like a week of work — surely you just translate the strings. In reality the strings are the cheap part. Everything else is not. ## Strings belong outside the code This is the one decision worth making at the start, even when no second language is planned. If text is written directly in the code, extracting it later means walking the whole application screen by screen. The second half of the rule: **assembling sentences from fragments falls apart in another language.** A construction like "Order" + number + "was" + status looks economical, but in a language with inflection or different word order it produces nonsense. Translate whole sentences, even at the cost of repetition. Plurals need the same thought. Slovak has three forms (1 item, 2 items, 5 items), English two, other languages differ again. A condition of "if count is 1" is not enough. ## Dates, numbers, currencies This is where errors appear that are hard to find, because the application works — it just displays something other than what the user thinks. - **The date** 3/4/2026 is April in Europe and March in the US. The format should follow the language rather than being hard-coded. - **The decimal separator** is a comma or a full stop depending on country; the same goes for thousands. - **Currency is not language.** An Austrian customer may want a German interface with prices in euros, a Swiss one a German interface with francs. - **Time zones** — if the application runs in several countries, store time in UTC and display it in the user's zone. ## Text length changes the layout A German translation tends to be a third longer than Slovak; English is shorter. A button that fitted exactly suddenly does not. So the interface gets designed to survive longer text — no fixed button widths, no sentences squeezed into narrow columns. A practical test: try the interface with strings padded by 40 percent before the real translation arrives. ## Data in the database is the harder half This is the most commonly forgotten part. The interface gets translated, but product names, categories, statuses and lookup lists sit in the database in one language. There are two options and the choice should be deliberate: **translatable fields** (each record carries several language versions) or **separate records** per market. The first suits content that is the same and differs only in language; the second, where the range or the rules differ too. Search is connected to this: the index has to know which language the text is in, or neither inflection nor accents will work. We go into it in the piece on [search in a business application](/blog/vyhladavanie-vo-firemnej-aplikacii-full-text-filtre-a-relevancia). ## Do not forget what the application sends out Emails, PDF invoices, delivery notes, SMS. Those get localised too — and the language has to follow the recipient, not whoever triggered the action. If a German customer receives a confirmation in Slovak, the interface hardly matters. This connects to what we describe about [notifications in a business application](/blog/notifikacie-v-podnikovej-aplikacii-email-sms-a-push). ## Translations are living content The application changes and so does its text. Without a process you end up with a new feature available in the original language only, while the others show a key or a blank. What works: **one source of translations**, outside the code and editable by a non-programmer; **a list of missing translations** as part of the pre-release check; and **a sensible fallback language** — better to show English text than a technical key. ## What it means for timelines On a new application, preparing for multiple languages adds a few percent of work. On a finished one it is considerably more, because the whole existing codebase is walked and data structures change. So it is worth deciding early — even when the answer is "we do not want a second language yet". The difference is between preparing and rebuilding. ## Where to start If you are weighing this up, start with an inventory: everywhere in the application where a user sees text — interface, emails, documents, error messages, lookup lists. That list tends to be surprisingly long, and it shows immediately how much work is really involved. If you are facing this and want an estimate before deciding, [get in touch](/kontakt). We handle it as part of [custom development](/riesenia/vyvoj) — examples in our [case studies](/referencie). --- Web version: https://interfase.sk/en/news/multilingual-support-and-localisation-in-a-business-application llms.txt: https://interfase.sk/llms.txt