Software your staff can actually read
The storekeeper, the guard and the munshi have to use it too. What Hindi support usually turns out to mean, and how to find out before you buy.
The people who will use a construction system every day are not the people sitting in the demo. The storekeeper who books material in, the guard at the gate, the site supervisor logging a pour, the labour contractor's munshi marking a muster — these are the users. The head office team who chose the software will touch it far less often than any of them.
So the question is not whether the application is usable. It is whether it is usable by the specific people in your organisation, on the phones they own, in the language they read. It is the easiest question to skip when choosing construction software, because everybody in the room can read English.
What "Hindi support" usually means#
Every vendor selling in India will say yes to Hindi. The word covers a wide range, and the range is worth naming.
- The menus only. Navigation and button labels translated; every screen behind them still in English. This is the most common version by a distance.
- Menus and labels, but not messages. The form is in Hindi until something goes wrong, at which point the failure appears in English. The user meets the translation on the easy path and loses it on the hard one.
- Static text, but not data. Everything the developer typed is translated; nothing anybody typed into the system is. Material names, unit names and status names stay as they were entered.
- The whole application, in a register nobody speaks. Complete, formal, and translated by somebody who has never stood in a site store. The words are Hindi and the sentences are not.
Ask which of these it is, then check, because nobody answers it precisely without being pressed.
How to test the language claim#
Switch the language yourself, then go looking for the seams.
Break something on purpose. Save a form with a required field empty. Enter a quantity larger than the stock. Try to approve something you are not allowed to approve. The error message is where translations end, and an error message in English is the one message that most needed to be understood.
Look at the dates and the numbers. A date shown in a form the reader does not use gets read wrongly at least sometimes. Check whether large figures are grouped the way your office writes them, and whether units appear as words your storekeeper uses or as codes from a table.
Read the register, not just the words. This is the part almost nobody checks and the part staff notice immediately. Hindi has a respectful form and a familiar one. Software written in bare imperatives — the form you would use with a child — reads as an order barked at somebody, and people resent an application that talks down to them in a way they would never accept from a colleague. The respectful form costs nothing and changes how the thing feels to use.
Check the vocabulary against the site. A translation can be correct and still useless, because the official word for a thing and the word the store shouts across the yard are different words. Somebody looking for a bilty will not find a screen labelled with the formal term for it. That is a deeper problem than translation, and the words the site already uses shows where it decides behaviour.
Find out who can switch. If changing language needs an administrator, nobody changes it. A user who cannot set their own language is using whatever the person who created their account happened to pick.
Reading is not only about language#
A large part of "can they read it" has nothing to do with which language it is in.
Sunlight. Take the phone outside at noon and look at the screen. Thin grey text on white, which looks elegant in an office, disappears entirely on a roof slab. So does a low-contrast placeholder that turns out to be the only label on a field. Contrast is not decoration.
Capital letters. A screen set in capitals reads as deliberate for a week and as shouting after that, and it is slower going for anybody who is not a confident reader — the argument in capitals are a contrast.
Tap targets. The hand using this has been working. It is dusty, it may be gloved, the phone may be wet. Small controls placed close together are a source of wrong entries, not merely of irritation.
Taps per action. Count them for the commonest task in the building — the one done all day, not the one demonstrated. Every extra tap is multiplied by however many times that job happens, and the gap between a short sequence and a long one decides whether the system gets used or worked around.
Number entry. Watch somebody enter a quantity. If the keyboard opens on letters, if the decimal point is buried, if the field rejects a comma the way the user writes it, that field will be filled in wrongly and the errors will look like carelessness rather than design.
Explanations. When the app refuses something, does it say why. A refusal with no reason teaches the user that the software is arbitrary, and arbitrary things get routed around; the app should tell you why adds that the reason must reach the reader in their own language too.
The person who cannot read comfortably#
Some of the people who will use this are not confident readers in any language. This is ordinary and it is planned for badly.
Ask what a task looks like without reading. Whether the material can be chosen by photograph as well as by name. Whether a status is carried by shape and colour and not only by a word. Whether a note can be spoken instead of typed, and what happens to that recording afterwards. Whether the flow of the screen matches the order of the physical job, so that a person can follow the shape of it from memory.
Where none of that exists the work does not stop, it moves. It goes to a call, or to somebody at the head office typing on behalf of a man at the gate, or to a group chat — which is why WhatsApp is the interface whether anybody designed for it or not.
Three things we changed in ours#
Language is a setting on a person, not a policy for a company. Automated messages go out in each person's own language rather than in one chosen for everybody. Two people on the same site can receive the same fact differently and both understand it.
The words people reply with are not translated. A short reply the system matches on stays identical in both languages, because it is a command rather than prose. Translating it would break the one thing the person had memorised.
The screen at a gate should not need a language at all. It uses pictograms and large plain numerals beside Devanagari, so somebody who reads neither language can still work it.
The test that settles it#
Hand the phone to the person who will actually use it. Say nothing.
Do not explain the screen, do not point, do not fill the silence. Give them the real task — book in this load, mark this man present — and watch where they stop. Where they stop is the answer, and it is usually not where anyone in the room expected.
The short version#
Ask exactly how much of the application is translated, then break something and see what language the error is in. Check the register: respectful forms, and the words the site already uses.
Take the phone into the sun, count the taps for the commonest task, and watch somebody type a number. Then hand it to the storekeeper and stay quiet.