Translation is the last step, not the first
Ask most software teams whether their product supports Marathi or Hindi and they will point to a translation file. The labels have been swapped, so the job is done. Then the first invoice prints with boxes where the letters should be, a customer's name sorts in the wrong place, a price shows up as 1,00,000 on one screen and 100,000 on the next, and the WhatsApp reminder arrives in English anyway.
A product that genuinely works in an Indian language is designed that way from the beginning. We learned this building MurtiTrack, a Marathi-first app for Kolhapur's Ganapati idol workshops, together with our sister company Unitary Tech. Owners who had never used business software were taking orders on it within a day. That didn't happen because of good translation. It happened because the whole product was planned around the language its users think in.
Here is the checklist we now use on every multilingual project.
1. Fonts that render every conjunct
Devanagari is not a simple left-to-right row of letters. Consonants combine into conjuncts, vowel signs attach above, below and before the consonant they follow, and a font that lacks the right shaping data produces broken or dotted forms. System fonts on older Android phones vary a lot.
- Choose a well-supported open font family with full Devanagari coverage, and load it in the app rather than relying on the phone.
- Test with real words, especially names, which use rarer conjuncts than everyday vocabulary.
- Check line height: vowel signs above and below the line need more vertical room than Latin text.
2. Numbers, money and dates
Indian number grouping (1,00,000 rather than 100,000) is what most people expect, and some prefer Devanagari digits. Decide deliberately and be consistent:
- Format numbers with locale-aware functions rather than hand-written code, so grouping is always correct.
- Store numbers and dates in one neutral format and only localize them on display.
- Write dates the way your users do. In a business with a seasonal calendar, the festival date may matter more than the month.
3. Text that grows and wraps
The same message is often longer in Marathi or Hindi than in English, and longer words wrap differently. Buttons overflow, table columns break and headings run to three lines.
Design every screen with the longest language, not the shortest. Give buttons room to grow, avoid fixed-width labels and test on the smallest phone your users carry.
4. Sorting and search
Alphabetical order in Devanagari follows its own sequence, and people search the way they type. Many type Marathi phonetically with Latin letters and let the keyboard convert it, while others type a name in English even when it's stored in Marathi.
- Use locale-aware sorting so lists come out in the order people expect.
- Make search forgiving: match on both scripts where you can, and ignore small spelling variations.
5. Documents that leave the app
Invoices, statements and reports are often the part of the product customers see most. They need to work outside the app too:
- Embed the font in every PDF, or the letters may break on the customer's phone.
- Keep the language of the document independent of the language of the person generating it. An owner may use the app in English but send invoices in Marathi.
- Approve message templates for WhatsApp and SMS in each language, not just in English.
6. Words people actually use
Literal translation produces formal, bookish language nobody speaks at work. The trade has its own vocabulary, and sometimes the English loanword is the natural choice.
Write the interface with people from the trade, not a translation agency. Short, everyday words beat correct but stiff ones every time.
7. Test with native speakers, on real devices
Automated tests catch broken layouts, but only a native speaker notices when a sentence sounds wrong, a number reads oddly or a term means something else in this trade. Put the product in front of real users on their own phones before launch, and keep a simple way for them to report a word that doesn't fit.
The payoff
Building in your users' language costs a little more at the start and far less than retrofitting it later. More importantly, it changes who can use your product. Software in a person's own language doesn't need a training session. It just needs to be opened.
Planning a product in Marathi, Hindi or another Indian language? Talk to us about how we'd approach it.
