The language of notifications - the text arrives in the recipient's language

The administrator works in Russian, the specialist in Ukrainian, and the task reminder is created by a cron job that has no language at all. Whose language should end up in the notification? There is one answer, and it is not about convenience: the reader's.

Why this is a question at all

A notification is born at the moment of the event. It is created by somebody else - the person who moved the booking or assigned the task - or by a scheduled service. A third person reads it. Assemble the text right away and it arrives in the author's language: a specialist whose whole workspace is Ukrainian used to get a Russian sentence in the middle of it.

So what goes into a notification is not a finished string but what is about to become one: a key and its substitutions. The translation happens at the last moment, when it is already known who will read it.

The order in which the language is chosen

The recipient's language is resolved as a ladder, in descending order of reliability:

1. The person's own choice in their profile. If it is there, there is nothing to argue with.
2. The language the person actually works in. The interface remembers it by itself: the app reports its language on every request, and that observation is stored. Hardly anyone reaches the profile settings, while this language is known about everybody.
3. The company language. For a cron job that is a far better default than one shared by the whole installation: a salon's notification is reasonably written in the salon's language.
4. The application language. The last rung - and the one a Russian sentence in a Ukrainian workspace used to come from.

A notification with no personal recipient - one addressed to the whole company - is translated into the company language. That is the second case the third rung exists for.

Two fields instead of one

The person's choice and the observation of the language they work in are stored separately, and that is not duplication.

An empty value in the choice is an answer too: "same as default". The person did not ask for a particular language, they are content to let the system decide. Write the observation into that same field and the answer loses its meaning: there would be no way to tell "I chose Russian" from "I happened to open the app from a Russian browser last Tuesday" - and the first has to outrank the second for good.

So the observation is written to its own field, and only when it has changed: the language arrives with every request, and storing "the same again" would mean updating the profile on every call to the app.

What this looks like in practice

Switch the language in the app header and notifications start arriving in it. Nothing has to be configured separately: the language you work in is the answer to the question of which language to write to you in.

An explicit choice of notification language is supported on the server side and is not yet exposed in the profile as its own switch. When it is, it will behave exactly as described above: the chosen language outranks the observation, and an empty value means "same as default" and hands the decision back to the interface language.

The languages the product speaks are Ukrainian, Russian and English. A value outside that list is ignored, so the ladder simply moves one rung down instead of handing out text in an unknown language.

What to check if the language is still wrong

• Look at the language of your own interface. The notification follows it, not the language of whoever created the event.
• Check the company language in its settings: it decides for notifications without a personal recipient, and for the cases where nothing is known about the person.
• Strings already stored in the database are not translated retroactively. Service names created by the starter set, or text typed by hand, appear exactly as they were written. What gets translated is the shell of the notification, not the contents of your salon.